-
-
Notifications
You must be signed in to change notification settings - Fork 304
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
redirect_uri parameter given to authorization endpoint is not identical to the one given to the token endpoint #93
Comments
I'm having a similar issue... I get the initial code & state from the request but can't get a token because the provider throws an "invalid redirect_uri" error. Feels like the redirect_uri is getting mangled but unsure how to inspect it. Also, I wonder if it's related to this older issue: #28 |
I was able to work around this issue by applying the same change some other people have done: Add the following method to your strategy: def callback_url |
Thanks @mulka! That works beautifully! FYI I discovered I could also manually assign the redirect_uri param like this:
but your solution is cleaner. I'm now getting the token response but having an issue where the response isn't getting parsed and throws the error below:
It appears that I'll follow up with the vendor as I don't think this is an issue w/ Omniauth (or the Oauth2 gem) but thought I'd post here in case it helps or sets off any alarm bells for anyone... Thanks for your help! |
Hi, |
To update: @mulka's work-around worked perfectly and I've spoken with the vendor and they've corrected the content-type issue on their end so I believe my issues are now solved. Hope this helps! |
i am using 1.4.0 and i can't get to override the callback url. Here is my strategy:
i have in routes the redirect
How can i specify the callback url? |
@ivanstojkovicapps option :token_params, { redirect_uri: "[insert callback url here]" } or alternatively add the following method to your strategy def callback_url
full_host + script_name + callback_path
end Hope this helps! |
Some providers require the redirect URL sent in the request and callback phases to exactly match, while some apps require application state parameters to be added as query parameters to the redirect URL. To simultaneously handle both of these, the redirect_uri built in the callback phase has to be the received callback_url with just the There is a PR that attempts to do this. However it fails for some providers by removing the entire query string in the callback phase. I've got two working solutions for removing just the
def build_access_token
verifier = request.params["code"]
callback_dangling_question_mark = callback_url[-1] == '?'
redirect_uri = callback_url.gsub(/&?(code|state)=[^&]*/, '')
redirect_uri.chomp!('?') unless callback_dangling_question_mark
client.auth_code.get_token(verifier, {:redirect_uri => redirect_uri}.merge(token_params.to_hash(:symbolize_keys => true)), deep_symbolize(options.auth_token_params))
end
def build_access_token
verifier = request.params['code']
redirect_uri = URI.parse(callback_url).tap { |uri| uri.query = Rack::Utils.parse_query(uri.query).reject { |k,v| %w(code state).include?(k) }.to_query }.to_s
client.auth_code.get_token(verifier, {redirect_uri: redirect_uri}.merge(token_params.to_hash(symbolize_keys: true)), deep_symbolize(options.auth_token_params))
end Which is better? The second is has a nasty dependency for non-Rack apps, while I'm not entirely sure that the first covers all possibilities. |
The second one is clearly more readable, I will change my gem. |
Joel, since this problem/solution is applicable to all oauth2 providers, it would be more efficient for the url change to be part of this omniauth-oauth2 gem rather than in your omniauth-windowslive gem. But yes, remove the recent code that removes the query string. |
@mrj I agree, I will do |
I've now come across a provider that requires redirect URLs to exactly match one in the registered list. This prevents app parameters being sent through the redirect query string. I see two solutions:
|
omniauth/omniauth-oauth2#93 (comment) The URL was being created incorrectly. This strips all the gunk that Nest was complaining about. [Fixes #151421294]
Is there any news on this? I have the same problem that the |
As seen here: omniauth/omniauth-oauth2#93 https://docs.microsoft.com/en-us/graph/tutorials/ruby?tutorial-step=3 This way we can have multiple callback urls setup in Azure AD.
Unlike most providers, the Dropbox Business (and Dropbox consumer) API require the callback_url to exactly match what is configured in their web UI, **including any querystring values**. By default, OmniAuth appends any incoming querystrings to the callback_url being sent the the provider. This means that if your app begins auths with something like: /auth/dropbox_oauth2?auth_version=v2, Your callback_url becomes: /auth/dropbox_oauth2/callback?auth_version=v2 This doesn't exact match Dropbox Business' overly strict requirements for this URL: /auth/dropbox_oauth2/callback The fix is for this provider to override callback_url so that the querystring is not appended automatically. There is a long-going disucssion to see whether this should be fixed in omniauth-oauth2 or within each affected provider strategy: omniauth/omniauth-oauth2#93 It's not super clear, but the consensus seems to be that this behavior should be accounted for in the strategy. Here's the similar issue for Dropbox (consumer): icoretech/omniauth-dropbox2#2 Unmerged PR in the consumer library: icoretech/omniauth-dropbox2#2
This is pretty important, you should never be sending the authorization code back out by sending it as part of the redirect URL, and providers should be requiring an exact match of the redirect URL to avoid creating open redirectors. The fix proposed here works great and I would love to see that merged into the core OAuth2 strategy. |
How is this still a thing over 4 years later! Come on guys! |
@machadolab Feel free to make a PR. |
There are a plenty of PRs, suggested fixes, references to other strategies that have implemented fixes that work fine. I don't think thats the issue. |
Dear maintainers, please revert 85fdbe1 . LinkedIn: https://github.com/decioferreira/omniauth-linkedin-oauth2/blob/master/lib/omniauth/strategies/linkedin.rb#L37 We happened to use an older, little-maintained strategy which broke on us sometime (perhaps the provider stopped accepting the bad redirect_uri that omniauth is giving). |
It seems like the redirect_uri given in the authorization phase is different than the one given when requesting the token. The state and code parameters are added. But, I think according to the oauth spec, this shouldn't be the case.
https://tools.ietf.org/html/rfc6749#section-4.1.3
For context, I'm trying to use this with django-oauth-toolkit which is giving me an access_denied error because the redirect_uri's don't match exactly.
The text was updated successfully, but these errors were encountered: