-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CORS filter doesn't seem to process pre-flight requests in CE 3.0.x #541
Comments
Please also note one thing I mentioned in comment to other report: It seems we still use this "Access-Control-Allow-Origin: *" header in responses both in 3.0.x and 3.1.x packages. It happens because of this part of Apache's configuration:
I.e. this header is simply attached to all responses from If in the end explicit "Access-Control-Allow-Origin" set by CORS filter will be overridden by this wildcard value set by Apache, on-page clients won't be able to access such response due to requirements I mentioned above. |
Seems like we have same line set for "/oxauth" path too:
|
I couldn't verify it's fixed. I used the 17.05.2017 oxauth-server.war(s) snapshots and pre-flight to userinfo still doesn't solicit a correct CORS-aware response. There is also another issue due to the fix done to this issue. Now on-page js client can't access "/oxauth/seam/resource/restv1/oxauth/jwks" which it needs, due to the fact I had to add this element to web.xml to make it work:
It should be there by default from now. |
@qbert2k @aliaksander-samuseu @sahiliamsso @zamilskhan seems like this is a high priority issue that needs to make it into 3.0.2. Can we spend some cycles making sure this is working as expected? |
I am testing again this issue and also #542. |
Was this issue fixed for 3.0.2? I'm using the latest (3.0.2_rs3) .war file from https://ox.gluu.org/maven/org/xdi/oxauth-server/ but it seems like it's still older than the most recent commit. Any chance that the prebuilt .war file can be updated to include this fix? It's a pretty big showstopper for JS client access. |
@qbert2k @aliaksander-samuseu has this fix been tested and confirmed in 3.0.2? |
I ended up building a fresh .WAR from the 3.0.2 branch including the above commits and still got the same issue. Any ideas @qbert2k @aliaksander-samuseu? |
@zamilskhan @sahiliamsso can you guys both test for this as well? |
Can you share your oxauth-config? It's in attribute oxAuthConfDynamic of entry: ou=oxauth,ou=configuration,inum=@!appliance_inum,ou=appliances,o=gluu In setup branch there are few commits with fixes to oxAuth configuration like this: |
@yurem Thanks for the heads up - my existing setup didn't include that fix in the oxauth-config.json on my server. If I modify the config in /install/community-edition-setup/output, does that apply the change to a server that's already been installed? Or are those files used purely during setup only? If it's the former, I'm still getting the following error in Chrome, using the documented OpenID Connect JS Implicit Flow client when attempting to access userinfo after a successful login.
With an unmodified 3.0.1 build, I'd get an error saying that the Authorization header wasn't accepted, so it looks like that part has been resolved, but as noted by aliaksander-samuseu, the Access-Control-Allow-Origin header looks like it's being overridden. I am very new to the platform so it'd be great if someone more experienced could confirm if their results are consistent with mine. |
If this is not a bug, you'll need to move this thread to https://support.gluu.org |
yes, it's better to move this to support.gluu.org @LunarAshes you can try to update existing instance using next steps.
|
Thanks guys, with the config added through oxTrust, it's working on my end. Sorry if this wasn't the right channel to approach this - I was a little unsure due to the limbo of 3.0.2 being almost released but not quite. |
Environment:
CentOS6.7, Gluu CE 3.0.1
Steps to reproduce:
WEB-INF/web.xml
inside ofoxauth.war
in any way which would result in behaviour that differs from defaults. For example, let's add "Authorization" header to the list of allowed headers, which will make it to look like this:# service oxauth restart
userinfo
OIDC endpoint (it's an actual CORS pre-flight request used by some on-page OIDC javascript clients employing implicit flow):Result:
Response to the proposed request looks like this:
This seems to be a plain usual response to OPTIONS request instead of response to CORS pre-flight request (the latter should contain several "Access-Control-Allow-*" headers; "Access-Control-Allow-Origin" which can be seen there actually has nothing to do with the filter as it's set outside of Jetty, by Apache web server). Filter seems to maintain some basic functionality and even reacts to certain changes to its configurations (I was able to modify "SupportCredentials" settings), and even return some CORS headers in response sent to certain urls, but it at least doesn't produce a correct pre-flight response from
userinfo
endpoint what makes it inaccessible for on-page clients.Expected result:
A correct response to such kind of request should look like this (additional CORS headers are possible):
Also please note that in case when "Access-Control-Allow-Credentials" headers is used in response and is set to "true", it's prohibited to use wildcard "*" for "Access-Control-Allow-Origin" and explicitly set origin must be used instead. As in requests to
userinfo
endpoint we must sendaccess token
in "Authorization" header, we must backup response to such request with "Access-Control-Allow-Credentials: true", or on-page javascript client won't be able to receive it.For further details those pages may be useful:
The text was updated successfully, but these errors were encountered: