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.
Related
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.
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 a setup where a client application is running on a different domain (http://www.example.com) than the server application (http://www.example2.com). I've got the cross domain AJAX requests working except that I cannot figure out a way to send cookies with the request without having to add the Access-Control-Allow-Origin response header for each possible domain. Is there a way to set this up without having to specify a list of domains in that header? I'm aware of the security implications so I guess what I'm really asking is ... is there another framework separate from CORS that I can use which will allow this type of setup and at the same time allow any domain for the client application? I tried JSONP but that did not work out (could not send the cookie with the JSONP request). Is there something else I should try other than CORS and JSONP? Thanks.
EDIT: This is not a duplicate of the question mentioned in the duplicate notification. I'm already aware of the withCredentials flag. The problem is that I don't want to have to specify a list of domains in the CORS response header. I want something equivalent to setting that value to '*', but setting it to '*' is not allowed if sending a cross domain AJAX request that contains cookies.
I want to call REST-services from my Angular-app. However, these REST-services are hosted on WLP and are part of a WAR-file developed by some company a while ago, ie. we have no source code.
I can call GET-methods without any issues from Postman, I just need to set authentication and accept headers. However, calling these GET-methods from Angular via web browsers will trigger preflight request (OPTIONS) without Authentication header prop. Seems to me that OPTIONS requests are triggered by the browsers and Angular cannot set headers for them. I confirmed OPTIONS requests need authentication by running requests via Postman with and without auth header prop.
Similar problems were discussed in other posts on stackoverflow but in such cases people had control over their server side code and could alter it to avoid authentication headers for OPTIONS request. Clearly in my case, I cannot do it.
My question is if there is a possibility to configure WLP to not ask for authentication header prop in case of OPTIONS-requests (seems to be configurable for Apache web servers and Tomcat)?
Kind regards
A.H.
Even without source, you should be able to edit web.xml and modify the security-constraints to punch a hole for OPTIONS.
A CORS POST request (AJAX) made by my client server (running on Apache # port 443) to my REST server (running on Tomcat # port 8443), fails to trigger when tried over HTTPS.
Please note that all the requests function properly without SSL.
I have already set the withCredentials: true options in the request fields. And my Tomcat server also takes care of the appropriate headers :
response.addHeader("Access-Control-Allow-Origin", "https://localhost");
response.addHeader("Access-Control-Allow-Credentials", "true");
response.addHeader("Access-Control-Allow-Headers", "Content-Type");
response.addHeader("Access-Control-Allow-Methods", "OPTIONS, POST");
I also tried using Curl, but the issue persisted over SSL. However, the Tomcat server responds to all my requests when tried directly over Postman/through the browser.
Could someone tell me what I'm missing out here?
I'm assuming this is an issue with the preflight request. There are two types of CORS requests: simple, and not-so-simple.
The simple kind is either a GET or POST with no custom headers whose content type is "text/plain".
The not-so-simple kind is any request using custom headers, utilising request methods other than POST or GET, and using different content body types. These requests will be "preflighted"; that is the browser will make a preflight request on the clients behalf in order to determine whether or not the server will allow this request. The preflight request uses the OPTIONS method. I'm willing to bet if you use something like Firebug to have a look what's going on you'll see something like this in the Net tab: "OPTIONS activity" with a status of "Aborted".
Unfortunately the preflight request doesn't pass the client certificate to the server which is why your request is failing to trigger. You need to disable two way SSL in order to get it working. In Apache you can try changing the SSLVerifyClient to:
SSLVerifyClient optional
I've used this before in order to get my cross domain AJAX calls working over HTTPS.
Good luck.