I use admin-on-rest (version 1.3.1)
My server calls are authenticated (JWT Token); and every call requires to pass in an authorization header.
The OPTIONS .../api/v1/resource fails because it is missing authorization header.
If I open up (grant permission for OPTIONS to by-pass security); the calls complete successfully.
Is there a way to intercept and add authorization header to OPTIONS API calls?
Any thoughts will help.
Solution for this issue: When implementing security, preflight requests must be opened up for all (ex: OPTIONS for /** resources must not be secured). This is required for browsers to complete preflight requests successfully.
Related
I'm getting 403 error on each custom rest api while executing the sharepoint login.
Could you please share with me a solution with an example?
This error comes
{"error":{"code":"-2147024891,
System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access
denied. You do not have permission to perform this action or access
this resource."}}}
Most probably you need to add proper authentication context to each API request and the most common way to protect the API from unauthorized usage is requirement to have valid Authorization header.
Inspect the outgoing requests to your custom API using your browser's developer tool and pay attention to the request headers in the "Network" tab, I believe you should see the aforementioned "Authorization" header or Cookie header or something like this.
In your JMeter script you can add custom headers to your requests using HTTP Header Manager
JMeter should handle Cookies automatically given you add HTTP Cookie Manager to your Test Plan.
Im using Jmeter to write some load tests on an API secured by oAuth.
I want to be able to reuse the header manager once the bearer token has been produced from the access token call.
However when I try to move the header manager out side of the http request the call is no longer authorised. I think its because it can no longer get the bearer token.
For Post Request, when i put the header manager outside it no longer works, it only works when I put it under the request as I have done for User get request, Delete request and Put request.
How do I make the header manager reusable and therefore only manage one header manager?
Thank you.
{"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}
My expectation is that this is due to clash with the HTTP Authorization Manager
Both are Configuration Elements and both obey JMeter Scoping rules
When you move HTTP Header Manager outside the HTTP Request sampler it might be the case that Authorization Header comes from the HTTP Authorization Manager
You can check which exact header value is being sent using Request -> Request Headers tab of the View Results Tree listener
Given you manually create Authorization header for your request I believe if you disable or delete the HTTP Authorization Manager your test should start working as expected as you basically don't need it.
I'm building an MVC web app that uses the openID Connect hybrid flow to authenticate with Identity Server 3. The MVC web app contains jQuery scripts to get async JSON data from een ApiController. That ApiController is part of the same MVC web app.
I don't want that everyone is able to access the data from the API, so I want to secure the API as well. I added an [authorize] attribute to the ApiController. When requesting the API with a JQuery ajax request I get the following error message:
XMLHttpRequest cannot load
https://localhost:44371/identity/connect/authorize?....etc.
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:13079' is therefore not allowed
access. The response had HTTP status code 405.
But, when I do a request to the API method directly in browser, I will be correct redirected to the Login page of Identity Server..
So, what's exactly the problem here? I read something about that requesting the /authorize endpoint is not allowed via 'back-channel', but I don't understand what's the difference between 'front-channel' and 'back-channel'. Is it possible that I mixed up the wrong OAuth flows? Is the Hybrid flow not the correct one maybe?
I also find out that the API is often a seperate app, but is it always neccessary / best-practice to build a seperate API app that for example requires a bearer token?
Please point me in the right direction about this.
The authorize method on your identity server does not allow ajax calls. Even specifying CORS headers is not going to help you in this particular case. Perhaps you could return a forbidden response instead of a redirect and manually redirect the client to the desired location via window.location
You need to allow your IdentityServer to be accessed from other domains, this is done by allowing "Cross Origin Resource Sharing" or CORS for short. In IdentityServer the simplest way to allow this is in your Client configuration for your Javascript Client, see this from the IdentityServer docs on CORS:
One approach to configuing CORS is to use the AllowedCorsOrigins collection on the client configuration. Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins.
The error you're seeing is the browser telling you that when it asked IdentityServer if it allows requests from your Javscript client, it returned a response basically saying no, because the origin (http://localhost:13079) was not specified in the "Access-Control-Allow-Origin" response header. In fact that header wasn't in the response at all meaning CORS is not enabled.
If you follow the quickstart for adding a JavaScript client from the docs here all the necessary code is detailed there that you need for the Client config and to setup IdentityServer to allow CORS.
I have an API protected by basic auth. When I want to make AJAX requests against the API, the browser send an OPTIONS request which doesn't carry the Authorization header so it gets rejected and thus my AJAX call is not allowed by the browser.
I tried to configure Tomcat to not authenticate OPTIONS requests but I don't manage to get it work.
Someone to help me to get it works?
Thanks :)
I found the solution, I had to specify the list of HTTP methods on which the authentication was applied. Default is to apply on all methods.
I have to make CORS with content type JSON. This makes the browser send first an OPTIONS request, specifying origin and so on. Then the server should answer with allowed domains, methods, etc. If this goes well, the browser sends the actual request.
My problem is that the server needs authentication for the actual request but ALSO for the OPTIONS request. But the browser doesn't send the authentication headers with the OPTIONS request.
I'm using JQuery and the ajax() function. I tried adding "withCredentials: true", and add the Authorization header, but this not affect the OPTIONS request, it still doesn't send any credentials.
Any ideas? Thanks in advance.
The preflight request is only meant to verify if the CORS request itself is allowed. Therefore, cookies are never included in the preflight request. You'd have to validate the user during the actual request.
Actually, Chrome will send the cookies w/ the preflight request if withCredentials=true whereas Firefox will not. Sounds like they've implemented the spec differently.