I'm using the omniauth-google-oauth2 gem to sign in users with Google.
After the oauth response is handled in controller, the user is redirected to another page: /dashboard. When landing on this page - a octothorpe (aka a hash/number/pound) character is added to the URL:
https://myapp.tld/dashboard#
From what it seems, that pound sign is somehow coming with the oauth response. But I cannot gather how and why it consequently gets passed on to the final page.
Any clues how this happens OR otherwise how to clear a redirect from passing that character?
Make sure your response type is set to code in the URL you are providing the user.
response_type=code
Related
I'm using a Bank E-Payment webservice and set the redirectURL into http://Example.com/EPaymentResultCallback?Param1=0&Param2=1
when the bank finish it's job, browser redirects to preceding url.
But the problem is: Bank webservice has changed my url into http://Example.com/EPaymentResultCallback?Param1=0&Param2=1 (noticing the extra &).
In fact my innocent url encoded and therefore Param2 will be lost.
I cannot change the websercive obviously. but interested to know if there is a way to resolve the second url parameter (Param2) on my website?
For more general explanation: 'mywebsite' calls a webservice and redirected to a whole new website. after 'new website' done, browser redirects to the given URL (in fact 'mywebsite/somesubUrl/param1¶m2') but parameter separator (&) changed into (&) so the second parameter (param2) won't delivered correctly to the action method and an exception raise, pointing that the second input parameter in the action method could not be null.
Actually i`m looking for a built-in solution to read encrypted url. that would be the best. but any other idea is welcomed.
Steps to reproduce
Register a redirect_uri in the client: http://example.com/publisher/auth
Direct a user to the /oauth/authorize endpoint with the redirect_uri including a query parameter:
https://api.instagram.com/oauth/authorize/?client_id=xxx&redirect_uri=http%3A%2F%2Fexample.com%2Fpublisher%2Fauth%3FinviteId%3D00001000-cf33-11e4-9f26-8789dd0b3e01&response_type=code&scope=basic&type=web_server
For reference, those query parameters are:
client_id=xxx
redirect_uri=http%3A%2F%2Fexample.com%2Fpublisher%2Fauth%3FinviteId%3D00001000-cf33-11e4-9f26-8789dd0b3e01
response_type=code
scope=basic
type=web_server
Authenticate an instagram user and allow the app.
The user is redirected back to the correct redirect_uri.
Use the code query parameter from the redirected URI to post to Instagram's /oauth/access_token endpoint.
Expected behavior
The endpoint responds with 200 and an access token.
ACTUAL behavior
The endpoint responds with:
code=400
error_type = 'OAuthException'
error_message = 'Redirect URI doesn't match original redirect URI'
What I've Investigated So Far
To confirm that this is a problem with Instagram, I checked the API docs which very clearly state that adding query parameters to the redirect URI should be possible. I also tried varying only that query parameter. For example, when replaced with this /oauth/authorize URL I get the expected behavior:
https://api.instagram.com/oauth/authorize/?type=web_server&client_id=xxx&redirect_uri=http%3A%2F%2Fexample.com%2Fpublisher%2Fauth&response_type=code&scope=basic
For reference, those query parameters are:
client_id=xxx
redirect_uri=http%3A%2F%2Fexample.com%2Fpublisher%2Fauth
response_type=code
scope=basic
type=web_server
Notes
This question is actually a duplicate of another question which actually didn't really turn out to be a question, and which never got any answers.
I have submitted a bug with Instagram, but I wanted to see if anyone had found this or come up with a workaround.
Had the same issue today. To get the custom data passed between requests you must include it as state param. My authorize request url looked something like this:
https://www.instagram.com/oauth/authorize?client_id=SOME_CLIENT_ID&response_type=code&redirect_uri=http://example.com/auth/InstagramRedirect/&state=855C0114-F860-420A-AEB1-A276644FCCEA
Notice the & and state=...
You have to provide the redirect_uri with your extra search params as the last parameter:
https://www.instagram.com/oauth/authorize/?client_id=be1b911b487f4919b9c2fb7df0c4142c&type=web_server&response_type=code&scope=basic&redirect_uri=https://wpwifidemo.alepo.net/instagram/joinus/?inviteId=00001000-cf33-11e4-9f26-8789dd0b3e01
User will be redirected to:
https://wpwifidemo.alepo.net/instagram/joinus/?inviteId=00001000-cf33-11e4-9f26-8789dd0b3e01&code=CODE
It might be too late reply for this question. But i faced the same issue today & got this question already posted and solution for passing parameters to authentication URL is as follows.
It seems that your extra parameter is type=web_server , taking that into consideration, your URL for getting for code should be as follows
https://www.instagram.com/oauth/authorize/?client_id=be1b911b487f4919b9c2fb7df0c4142c&redirect_uri=https://wpwifidemo.alepo.net/instagram/joinus/?type=web_server&response_type=code&scope=basic
And then while calling the accessToken API append your redirect_uri parameter with your passed parameter (not the same configured in the app).
e.g.
redirect_uri=http%3A%2F%2Fexample.com%2Fpublisher%2Fauth%3FinviteId%3D00001000-cf33-11e4-9f26-8789dd0b3e01?type=web_server
I'm using Nest as an Authentication Provider for Salesforce, with the intention of calling the Nest API from Force.com. The problem I have is that Nest corrupts the state parameter during the OAuth 2.0 flow.
This is the redirect from Salesforce to Nest. I've inserted line breaks for clarity:
https://home.nest.com/login/oauth2?
response_type=code&
client_id=16188153-52f1-4ac9-93ee-83ccab5cbd2f&
redirect_uri=https%3A%2F%2Flogin.salesforce.com%2Fservices%2Fauthcallback%2F00DE0000000cjOBMAY%2FNest&
state=jMG%2F2bzDEPisWyKsH7yVPHCrHdHxRAzYhG3Aq7VBF%2FrBLmW49eGj3DEzCLg0aGIvbOadXUxf1pwiDIPupqOMTZ%2BQbuThvTf58y2zXHwDNcoAvg%3D%3D
Note the 'percent encoding' in the state parameter
This is the redirect back to Salesforce:
https://login.salesforce.com/services/authcallback/00DE0000000cjOBMAY/Nest?
state=jMG/2bzDEPisWyKsH7yVPHCrHdHxRAzYhG3Aq7VBF/rBLmW49eGj3DEzCLg0aGIvbOadXUxf1pwiDIPupqOMTZ+QbuThvTf58y2zXHwDNcoAvg==&
code=UCMG2TEF9S69CQX2
Notice, state is no longer URL encoded. And, in particular, since it contains a + character, when Salesforce decodes it, that + is interpreted as a space, and the state doesn't match what Salesforce sent, so authentication fails.
Nest - please fix this!
I am using tornado framework to use the Twitter API. I am not understanding why I am getting a callback url with the value of next in it
auth/login?next=%2F%3Foauth_token%3D
I understand that /auth/login is setup by me during AuthLoginHandler. But I am not understanding what is setting next token inside the url. This makes my other argument
self.get_argument('oauth_token', None)
return None.
I know that we can still parse the url the get the oauth_token, but any insights into how TwitterMixin or default Oauth class of tornado is doing this. I am a newbie to Tornado
Firstly, You can ignore the 'next' argument until you get your core code working.
'next' is an extra parameter so you can forward the user to to the original page you asked for like this:
self.redirect(self.get_argument('next', '/'))
The 'next' param is added in the request handler here after a call to get_current_user has returned None. [ie user is not logged in]
The Tornado docs describe how to write a handler for Twitter.
our front end guy needs to form a url containing the hash, (i.e, http://blah/#some-link.) when we hit this on the browser and inspect the http traffic using fiddler, we saw that everything after blah/ gets removed, so the request is really just http://blah/. we also confirmed this on our server eclipse debug log.
the request gets redirected to the correct login page by Spring security(because user hasn't logged in), but the url on the browser now shows:
http://blah/some-link (the hash got removed) but the url on the browser should really be http://blah/log-in.
any idea why this is? any fix or workaround? thanks in advance.
URI part after # is called a fragment:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
Scheme and hier-part identify the location of a document, and fragment helps the browser to identify a location inside this document.
Fragment is stripped from URI by client software before it is sent as a part of request.
From RFC3986:
the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme. Although
this separate handling is often perceived to be a loss of
information, particularly for accurate redirection of references as
resources move over time, it also serves to prevent information
providers from denying reference authors the right to refer to
information within a resource selectively.
Content after the # is only used on the client side, per HTTP specification. If you require that information on the server, you can either use a different separator, or you can submit it via ajax after the page has loaded by reading it on the client with javascript.
The part of the URI including and after the hash (#) is never sent to the server as part of the HTTP request.
The reason is that the hash identifier was originally designed to point at references within the given web page and not to new resources on the server.
If you want to get the hash identifier, you'll have to use some client-side JavaScript to grab the value and submit it with the form.
Hashmark is removed from URL when the back button is clicked in IE9, IE10 or IE11
In IE10 , first time on clicking the HREF link leads to the correct below url:
http://www.example.com/yy/zz/ff/paul.html#20007_14
If back button is clicked again the, then it comes to the below url:
http://www.example.com/yy/zz/ff/paul.html
Solution :
Please change the url with https
It works for me
you can do this with javascript
<script>
if(window.location.hash) {
console.log(window.location.hash);
window.location.hash = window.location.hash;
}
</script>