According to the Dropbox API documentation, a GET to https://www.dropbox.com/1/oauth2/authorize will render the Dropbox authentication website, and upon authenticating will redirect the client to the specified redirect URI with the access token as a GET parameter. However, the URL redirected to provides its GET parameters with # (and not ?).
For example, if I do https://www.dropbox.com/1/oauth2/authorize?response_type=token&client_id=foo&redirect_uri=https://www.httpsnow.org/, I will get https://www.httpsnow.org/#access_token=foo&token_type=bearer&uid=bar (note the presence of the # symbol and the lack of a ? symbol at the start of the query string).
Any ideas?
You're using the OAuth 2 "token flow" (response_type=token). The token flow is designed mostly for mobile and JavaScript-based apps. As the documentation says:
Token flow
These parameters are passed in the URL fragment (after the # in the
URL):
It sounds like you want to use the "code flow" instead (response_type=code):
Code flow
These parameters are passed in the query string (after the ? in the
URL):
Related
I have configured an OpenID Connection application on OneLogin (not sure the provider matters) with a configured post MFA authentication redirect uri of
http://localhost:4200/LoginResponse.aspx?
The code behind my LoginResponse.aspx page grabs the returned id_token and processes it.
The issue is that after my initial redirect to the MFA login and successful login/MFA validation, the redirect is coming to
http://localhost:4200/LoginResponse.aspx#id_token=12345678987...........
Note the "#" symbol after my .aspx extension. This is corrupting the parameter string that is returned and not allowing me to grab the value of id_token from the Response.
After the redirect comes back, if I simply manually replace the "#" with a "?" and hit enter, my LoginResponse.aspx page loads fine and finds the id_token and processes it with my business logic.
My question is, how can I get the redirect to actually return to "LoginResponse.aspx?" so that I can grab the parameters.
On my OpenID Application I have tried the following options as Redirect URIs
LoginResponse
LoginResponse.aspx
LoginResponse.aspx?
LoginResponse.aspx?action=test
Did that last one to see if I could get around the ? not being there. But that just redirected the page to "LoginResponse.aspx?action=test#id_token=..............." So again, I could not grab the "id_token" variable out of the URL Response/QueryString.
I just cannot figure out how to get rid of this unwanted "#" sign and have a "?" after my .aspx extension.
Any help would be greatly appreciated!
I assume you are using the implicit flow to retrieve the tokens and in this flow you can either get back the tokens in the URL with the #. The # is added to make sure the tokens are not sent back to the server, instead they just stay in the browser. If it was a #, then the secret tokens would be sent back to the server and end up in various logs and creating various security issues.
I don't know how you implemented the client, but in OpenID Connect, if you add this parameter "&response_mode=form_post" to the initial authorization request, then you will get back the token using a POST request instead. just like this picture shows:
PS, I doubt you can get back the tokens using a ? instead of #.
How to Hide query String URL in Spring MVC
We are using third party URL, when we hit the URL it open a PDF, we want to hide some parameters in query string URL. In the URL there pass invoice number and Date both parameter we want to hide, when we hit URL in any ways.
If we cannot hide the using query string while using URL tag? What is the alternative for the above scenario.
URL: http://abcxyz/GetDocument?DocumentClass=INV&invno=098765546&invdt=11/01/2016
You may be able to use a POST request rather than a GET, that way the parameters do not appear in the url, but this will depend on whether the third party will support a POST request.
A GET request will always show the params in the url. If you leave out the parameters, the request probably can't be completed properly.
A user would still be able to see what was sent even if using a POST request or javascript to fetch the document. Their browser's development tools will show the requests and the parameters. This makes sense since it's their browser that is making the request and you can't stop them from checking what data they are sending out or receiving.
One way I can think of is to have your server request the page from the third party and serve that to the user's browser. That way your user will be requesting the data from your server and doesn't need to know about the third party at all, you will have control over the url that serves the pdf.
One caveat I would add is that you might want to check the third party's terms of service to see if this would violate them.
When I send a one-off document to RightSignature via their API, I'm specifying a callback location in the XML document as specified in RightSignature's schema definition. I then get a signer-link value back from their API for the document. I display the HTML response from the signer-link URL in an iFrame on our website. When our user signs the document in this iFrame, which is rendering the responses from their website, I want their website to post to our callback location.
Can I do this with the RightSignature API and does it make sense?
So far, I'm only getting content in the iFrame that indicates that the signing was successful. The callback location does not seem to be getting called.
I got it solved just now. Basically, i was doing two things wrong first you have to go in RightSignature Account and set it there the CallBack url
Account > Settings > Advanced Settings
But the thing which RS is unable to mention to us that this url can not be of localhost, but it should be of https i mean like Live URL of your site like
https://stagingmysite.azurewebsites.net/User/CallBackFunction
And then in your CallBack just write these two lines and you will receive complete XML which would have the GUID and document status as well.
byte[] data = Request.BinaryRead(Request.TotalBytes);
string callBackXML = System.Text.Encoding.UTF8.GetString(data);
I found the answer with some help from the API team at RightSignature. I was using callback_location but what I really wanted is redirect_location. Their online documentation was difficult to follow and did not clearly point out the difference.
I got this working after a lot of trial and error.
I am using 'omniauth-linkedin-oauth2'.
When I am login with linkedin then I am getting this error
Invalid redirect_uri. This value must match a URL registered with the API Key.
This is my settings:
Went back to LinkedIn developer site (https://www.linkedin.com/secure/developer ) to check my setting again. Everything matches API Key, Secret Key and OAuth 2.0 Redirect URLs.
Searched web looking for some clues. Couldn’t find a one. Crazy issue:
Then I saw that in the URL Owin was appending some extra string to the redirect_uri “signin-linkedin”. When I decoded the URL I saw this http://localhost:54307/signin-linkedin . I took this URL and placed it in the OAuth 2.0 Redirect URLs field in the LinkedIn developer site.
This link is helpful for me
https://naveengopisetty.wordpress.com/2014/09/15/linkedin-oauth-2-0-issue-invalid-redirect_uri-this-value-must-match-a-url-registered-with-the-api-key/
You can just look in url that you are getting that error message on.
eg. if you are using python's social auth the url would look like this:
https://www.linkedin.com/uas/oauth2/authorization?scope=r_basicprofile+r_emailaddress&state=XXXXXX&redirect_uri=http://example.com.au/sa/complete/linkedin-oauth2/&response_type=code&client_id=YYYYYYY
so you would use this part of the above url for the redirect url
http://example.com/sa/complete/linkedin-oauth2/
please check your redirect_url. for my case I see like this.
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=77k93y0w31zaey&redirect_uri=http%3A%2F%2Flocalhost%3A1729%2Fsignin-linkedin&scope=r_basicprofile%2Cr_emailaddress&state=nhAC-nR-CgEwO3XS2ezANhuPBMz-IUmLPJYgGHlZvZ8B1pCfsGBU0PR0dZ5XxE4zbyeI0RLcKByqPLKkgQdqMm4s6DjFYqMCEehYA2iWT9MfioEHjPXGCt2USxUTF0wKBpflCUjG5URVlJa3qI7U3ydFOErZ4Hhnr9SVmKdf1bithYfbOqBx345o8LQLexbddQ687vP6y0szrIyCM6FHip1tCpOY3Hgg5FJQEFH1mCJ_yLunD5vDUN4VVfkQbcjk
for this I add the url for OAuth 2.0 Authorized Redirect URLs:
http://localhost:1729/signin-linkedin
where http://localhost:1729 =base url and
signin-linkedin = the string which add after base url
One more solution is to just verify the client_id you've been using the whole time..because with every update in the list of redirect_uri, the client_id gets updated.
Worth mentioning when one uses libraries to handle oauth: some libraries fail to care about the protocol that is used (or at least require further parametrization). Eg, I gave Linkedin https://example/callback as oauth2 url, but the library sent the request with http://example/callback as parameter.
I had this when trying to authorise from a zurb Reveal modal popup. In my case, the issue was the URL for the page that was being displayed in the popup was not in my OAuth2 Redirect URLs list on the LinkedIn developer site.
That was easy to miss because the page URL from the page in the modal is not the URL that was currently showing in the browser's address bar. Once I added the URL for the page being shown in the pop up it worked.
After spending hours i finally get to the solution. You got an error no issues just check the url and find redirect_uri. Copy and Paste it's value it in your linkedin dev account oauth2 redirect field.
Make sure to add both with and without trailing '/' as redirect url.
http://localhost:8000/oauth/complete/linkedin-oauth2
http://localhost:8000/oauth/complete/linkedin-oauth2/
We've setup federated security using ThinkTecture server.
When a user wishes to access a particular URL, they get redirected to the Identity Provider Server (IDP), they login, get authenticated.
Then, the IDP server will redirect the user back to the "Redirect URL" specified in the configuration for that Relying Party.
Instead, I want it to be redirected to the originally requested URL.
Is this possible? I've read a little about the wreply parameter, but not sure how I use this and intercept the authentication levels calls on the original web server, before the redirect.
Update
I've realised that my problem is due to my url containing a hash, e.g. http://domain.com/#customer/123 and nothing after the hash is passed into the redirect url within WIF. See my answer below for more details.
It's up to your app to remember context info like this in the wctx param. If you're using WIF in the RP then this should be done automatically.
I figured out what was happening. I am using WIF and as Brock's answer suggested it should be doing everything itself...and it was.
Normally if you request a url like: http://domain.com/page and the 'Redirect To'/ReplyTo setting in ThinkTecture is just http://domain.com/.
Then when WIF calls out to the STS, it takes the path of the requested domain, in this case /path and adds it to the &ru param within the &wctx param. The &wctx param will look like this: rm=0&id=passive&ru=%2fpage.
Then after the STS has authenticated it redirects the user back to the ReplyTo url, http://domain.com with a body parameter of wctx and WIF picks this up and uses the ru param to do another redirect.
The problem is that my requested url was http://domain.com/#page and WIF doesn't include the #page in the ru param. So my ru param was just /, so it kept redirecting to http://domain.com which there was correct (yet incorrect).
Guess I need to set the ru value myself with the full URL... unless there is a better way.