How can I access to saml2:NameID from saml2:Subject response XML node by using Kentor AuthService?
I couldn't find in code anything that deals with that part of XML. Maybe I'm missing something.
I'm not asking about Kentor IdP, I see that there NameID is sent as additional claim, which is translated as attribute, I'm asking in general, IdP does not have to be powered by Kentor, so I can't rely that I will have this value passed as attribute.
So, if it's handled I couldn't find it here:
https://github.com/KentorIT/authservices/tree/master/Kentor.AuthServices
One option can be to parse XML on my own, but if there's already implemented or better solution that will be great.
The Subject NameID is translated to a claim with type ClaimTypes.NameIdentifier (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier).
It should be in the claims collection of the created claims identity.
Related
What should be done if an invalid uri is provided when calling a REST Web API (asp.net mvc)? I'm getting
HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.
When I provide an invalid controller, I get the following:
No HTTP resource was found that matches the request URI
'http://localhost:51929/api/usera'.
No type was found that matches the controller named 'usera'.
I thought 1) was the default and ok, but I've been asked to return a custom html page for both of the above and some others errors but it doesn't feel right to return a web page when dealing with an Web API?
1) Is this common practise?
2) Is there a best practice/standard?
Is there a best practice/standard?
One of the important points in HTTP is that the meta data of the response gives general purpose components the hints to support a coarse understanding of what is going on.
One significant piece of meta data is the response code, which communicates when the response body contains a representation of a resource, and when instead it contains a representation of "an explanation of the error situation".
Does it have to be a "web page"? No, of course not. Instead it could be text/plain, or application/problem+json, or any other representation that you would expect a general purpose client to be able to interpret.
The design of the message should be motivated by its use case, which is to say it is a document intended to be read by a human being trying to figure out what has gone wrong (we don't expect general purpose components to understand how to automatically fix a bad URL; instead, we describe the problem for a person, who will sort it out).
this might be a stupid question but I was unable to find a solution, also no luck with search.
My Node-Red flow gets triggered by a HTTP Input because I want to create a REST Webservice. It works fine so far but I wonder how to verify the content someone send to me.
As I see right now, I can pass any kind of content. There is no verification if the content matches to the content I want as input.
If I set content-type to application/json, it only accepts json data. That's great but I also want to ensure, users can post only a specific json string.
If someone sends data I'm unable to proceed (not the json object I expected), I want to send HTTP 400 as response.
I'm pretty new to Node-Red and also to json. I'm more an old-school programmer using classic webservices and soap. What I'm missing is some kind of WSDL (not sure if it exists when using REST) and some kind of payload validation.
It would be great if someone can point me the way to go.
Best regards
Patrick
There are some nodes available for doing schema validation on JSON objects.
For example, node-red-contrib-json-schema-validator - which uses ajv as the validation engine under the covers. Unfortunately this node doesn't come with much in the way of help. Essentially it lets you provide your schema and if a message fails to validate, it logs an error which can be handled with a Catch node if you want.
I found the issue. It was too bad.
I just forgotten to set HTTP Header content-type to application/json.
node-red-contrib-json-schema-validator works like a charm if content type is set corret
Right now I have a REST service which creates a report via a POST:
POST http://myhost/reports
The report however is not persisted, and cannot later on be retrieved via a GET:
GET http://myhost/reports/{id}
Instead I return the report immediately in the response to the POST. Am I violating any REST principle here, e.g. anything a POST creates should always be accessible via a GET, or is this setup OK?
The POST method isn't a synonym to the create in CRUD. The POST method is used for any operation that isn't standardized, so as long as you document what it does, you're not violating REST, no matter what you do.
There's no such REST principle saying "anything a POST creates should always be accessible via a GET". This is a common misunderstanding due to conflating REST with CRUD. Read this answer for some clarification on that.
In informal language, what a POST says to the server is "take this data and apply it to the resource identified by the given URI, following the rules you documented for the resource media type."
No, you are not violating REST. As long as your interface is uniform it is up to you to determine what actions the urls of your API perform.
As part of your documentation you simply need to state which methods are valid for certain resources and which aren't. I really like to use the Twitter API as a good example of "What to do"
Example: Twitter REST API
POST statuses/update
does not create an object available for access at
GET statuses/update/3
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
So according to the HTTP standard this is okay.
Just wanted to get feedback on how I am planning to architect my API. Dummy methods below. Here's the structure:
GET http://api.domain.com/1/users/ <-- returns a list of users
POST http://api.domain.com/1/users/add.xml <-- adds user
POST http://api.domain.com/1/users/update.xml <-- updates user
DELETE (or POST?) http://api.domain.com/1/users/delete.xml <-- deletes user
Questions:
Is it OK to use just GET and POST?
Is it a good idea that I plan to rely on the filename to indicate what operation to do (e.g. add.xml to add)? Would it be better to do something like this: POST http://api.domain.com/1/users/add/data.xml?
What's a good way to keep these resources versioned? In my example, I use a /1/ after domain name to indicate version 1. Alternatives would be: http://api1.domain.com... or http://api-1.domain.com... or http://apiv1.domain.com... or http://api-v1.domain.com... or http://api.domain.com/v1/... or
What's the best way to authenticate?
Before you dig into REST, here are some terms you really need to grasp:
Resource - The things/data you want to make available in your API (in your case a "User")
URI - A universally unique ID for a resource. Should mention nothing about the method being performed (e.g. shouldn't contain "add" or "delete"). The structure of your URI however doesn't make your app any more or less RESTful - this is a common misconception.
Uniform Interface - A fixed set of operations you can perform on your resources, in most cases this is HTTP. There are clear definitions for the purpose of each of these HTTP methods.
The most unrestful thing about your URIs as they are right now is that they have information about the operation being performed right in them. URIs are IDs and nothing more!
Let's take a real world example. My name is Nathan. "Nathan" could be considered my ID (or in restful terms URI – for the purpose of this example assume I'm the only "Nathan"). My name/ID doesn't changed based on how you would like to interact with me, e.g. My name wouldn't change to "NathanSayHello" when you wanted to greet me.
It's the same for REST. Your user identified by http://api.domain.com/users/1 doesn't change to http://api.domain.com/users/1/update.xml when you want to update that user. The fact that you want to update that user is implied by the method you're using (e.g. PUT).
Here is my suggestion for your URIs
# Retrieve info about a user
GET http://api.domain.com/user/<id>
# Retrieve set all users
GET http://api.domain.com/users
# Update the user IDed by api.domain.com/user/<id>
PUT http://api.domain.com/user/<id>
# Create a new user. The details (even <id>) are based as the body of the request
POST http://api.domain.com/users
# Delete the user ID'd by api.domain.com/user/<id>
DELETE http://api.domain.com/user/<id>
As for your questions:
Use PUT and DELETE when appropriate and avoid overloading POST to handle these functions as it breaks HTTP's definition of POST. HTTP is your uniform interface. It is your contract with the API user about how they can expect to interact with your service. If you break HTTP, you break this contract.
Remove "add" altogether. Use HTTP's Content-Type header for specifying the mime-type of posted data.
Are you referring to the version of your API or the version of the resource? ETag and other response headers can be used to version the resources.
Many options here. Basic HTTP Auth (easy but insecure), Digest Auth, custom auth like AWS. OAuth is also a possibility. If security is of main importance, I use client side SSL certs.
1) On your design probably not. POST is not idempotent! So you should not use for the update or the delete, instead use PUT and DELETE from Rest
2) A better choice is to use the header Content-Type on the WS call, like: application/xml
3) Also on the header Content-Type u can use it: application-v1.0/xml
4) Not sure if it is the best, but probably the easiest way is to use HTTP's built-in authentication mechanisms in RFC 2617. An example: AWS Authentication
In REST, the HTTP "verb" is used to denote the operation type: you won't be able to express all the CRUD operations with only "GET" and "POST"
no: the URL of the resource is usually where the "document identifier" should appear
The version of the "document" can be transmitted in an HTTP response header upon creation/modification of the said resource. It should be the duty of the server to uniquely identify the resources - trying to do this on the client side will prove a daunting challenge i.e. keeping consistency.
Of course, there are many variations on the topic...
I did authentication based on headers. Something like
X-Username:happy-hamster
X-Password:notmyactualpassword
If you're concerned about security - do it through SSL.
Other implementations exist, of course. For instance, Amazon with their S3:
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/index.html?RESTAuthentication.html
If you don't have ability to make PUT and DELETE requests, it's considered a good practice to tunnel them through POST. In this case the action is specified in URL. If I recall correctly, RoR does exactly this:
POST http://example.com/foos/2.xml/delete
or
POST http://example.com/foos/3.xml/put
...
<foo>
<bar>newbar</bar>
</foo>
It's a bit offtop, but in regards to versioning and REST overall you might want to take a look at CouchDB. Here is a good book available on-line
Using post for create and delete functionality is not a good rest api design strategy. Use Put to create, post to update and delete to delete the resources.
For more information on designing rest apis follow the link - best practices to design rest apis
Im trying to get TripIt OAuth authentication working, but I find the documentation to go a bit over my head. TripIt docs
The paragraph below is from the documentation, I have tried putting together a POST request for a SOAP service where the documentation specified what to put into the headers and how to build an xml for the Http body. In this case I have no idea on how to build my request.
I have all the values the service asks for, just no idea of how to set these using only the info given below?
To obtain an authorized access token,
POST the following request parameters
to the URL:
https://api.tripit.com/oauth/access_token
oauth_consumer_key: The Consumer's public key.
oauth_nonce: A nonce no more than 80 characters in length.
oauth_signature: The signature of the reque…
oauth_signature_method: Current supported methods are HMAC-SHA1.
oauth_timestamp: The timestamp in seconds since the epoch.
oauth_token: The request token obtained in Step 1.
oauth_token_secret: The request token secret obtained in Step 1.
oauth_version: OPTIONAL - Assumed to be '1.0'
Could someone help me with how I'll go about building the POST request from the above?
Thank you:)
The way to do it yourself would be to read up on how the body of a POST request is put together (it looks a lot like a URL query string), build the string out of the various parts, and then use the request's -setHTTPBody: method.
Most people recommend using ASIHTTPRequest, which, among many other things, will do that work for you. See, in particular, the ASIFormDataRequest class, and its -setPostValue:forKey: method.
Here's some more detail on the format of the POST body:
From the W3C HTML4 spec, the section on forms.
The Wikipedia entry on "percent escaping".
From the HTML5 spec draft. These rules should be backwards-compatible, while being more precise than the text in the HTML4 spec, but no promises.