https://localhost:8443/Service/oauth/token?grant_type=client_credentials and i am passing client credentails in authorization header .
Case 1: when client credentials are correct Json response as it should be.
Case 2: when client credentials are in correct html response why ?
i am throwing throw new ClientRegistrationException(client) in loadclientbyId() if client not found in database.
any suggestion what might be wrong .thanks.
html response:html response
Do not use your browser to test your endpoints.
Use a http client (i use Postman https://www.getpostman.com/ but there are others)
Related
I'm getting http requestor connection problem with POST:request a bad request even though I'm configuring properly. I'm sending json payload in the body and Bearer token in headers parameters with content type, I can evaluate the token and payload properly but still getting as a bad request when I tried to hit the direct URL as well, and I tried the trigger in postman with the same token generated in mule where I'm getting the success response but while using the same service within mule getting as bad request, I'm using http connector plugin version 1.7.1 in pom.xml.. Is there any problem with the dependency? can anyone help me with this?
If you are successful doing the request in postman then the HTTP request in your Mule application has to need some adjustments to make it match the postman request. Compare them carefully to make them match.
I'm using Apache Shiro for my Rest service project and I have troubles getting it to work as intended.
For rest service,I use basic authentication and as first,when I send wrong username,It returns 401 as expected.
Then I send correct user name and password,It returns 200 as expected.
As 3th step,When I send again wrong username,It returns 200,should return 401.
I think after first successful login,It doesnt need any authentication process again.How can I force it to authenticate for every request?
I couldnt find any reason or any parameter I should add in my shiro.ini.
This is my shiro.ini:
What you are seeing may be the result of your client. Before a client will send credentials to a server typically has to ask for them (responding with a 401), the client will the add the auth header. A client can work around this using "preemptive" auth, which will send the Authorization header on the initial request.
Your server is likely also configured to use cookies, which the server will process first and then return a 200 (and the client would never send the new credentials).
If this is just a REST server/client setup, you could disable session creation, using the noSessionCreation filter.
https://shiro.apache.org/web.html#default_filters
If you are still stuck take a look at your HTTP logs and watch for the headers (specifically Authorization and an Cookie headers).
I am new to Web Api 2. I am trying to build a project to explore token authorization. I created a new project in VS 2013 and selected the WebApi2 template and used Fiddler to emulate http requests. I didn't change anything in the template, just ran it as it was and tried to play with it with Fiddler. I successfully created a user by issuing request to /api/account/register but I can't login by issuing a POST request to the /Token endpoint. The request is:
http://localhost:YYYY/token?grant_type=password&password=admin123456&username=admin
(i also tried to pass the parameters as a json object in the request body).
I get back this:
{"error":"unsupported_grant_type"}
From other posts such as ASP.NET WEB API 2 OWIN Authentication unsuported grant_Type I learned that I needed to enable CORS for web api and at the token endpoint, but that hasn't worked for me.
Are you sure that you are sending POST request message and not GET?
If you simply go to the URL with query string (or open connection to this URL from your code) you are sending GET message by default. It's not what WebAPI with "/token" path is listening for.
If you are calling web service from same place, CORS is not needed. The error "unsupported_grant_type" could be in the format of the data you are passing server in post action.
Try sending with Content-Type application/x-www-form-urlencoded
I have a question about REST. I´m creating a service, in which the client sends HTTP request with Basic authorization (Header Authorization: Basic user:password). I want the server to control user credentials, and if they are correct, it would send 200 OK, otherwise 401 Unauthorized. If the credentials are OK, I want to send back also user´s ID. My question is, what would be the best way to send that? My options are: headers, or json in the body of the response. Thanks you in advance.
Personally, I would send it back in the body. I don't think there are any standard headers suitable for that type of information, unless you are setting it in a cookie.
I have a web application that uses RESTful url patterns. Currently if a users tries to access a page where they need to be authenticated it just returns nothing. Is it good practice to return the HTTP status code in this case? Would I use 403 or a different one?
You should send a response with the HTTP status code.
I wouldn't send a 403 Forbidden back though as the spec specifies for this status code :
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated
Return a 401 Unauthorized status code instead. See this for more info on the status codes:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The way I do this with Jersey is to send a response with the status and then include a String entity which contains a human readable message, e.g.
Response response = Response.status(Status.PRECONDITION_FAILED).entity(
new String("Incorrect " + id + " [" + id + "]")).build();
This will be displayed to the client. I throw a Jersey WebApplicationException which wraps this response.
If they don't have permissions return 401 to give them the chance to respond to the authentication challenge or 403 if you don't want them to.
Restlet 1.1 onwards return 403, while earlier versions return 401. 403 seems to be regarded as more correct, if not necessarily more helpful.
It depends. You really ought to return something, of course, just to have a decent client experience. If you'd like to give them opportunity to authenticate at that moment, you can return a 401 and the client will know to pass credentials using standard authentication. If, however, you'd prefer that they authenticate through some other mechanism (some login URL and then set a cookie or somesuch), then returning a 403 is probably the way to go.
lol... in the REST API implementation I just built I returned a 401 status code with a response body that read "goodbye". Was the first thing complained about by guy interacting with API. I still think "goodbye" said it all ; )