-
Notifications
You must be signed in to change notification settings - Fork 235
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 protocol mismatch (behind HAProxy, LinkedIn provider) #524
Comments
Does the proxy send an X-Forwarded-Proto header? If so, then if I were you, I would write a middleware or one probably exist anyway, just set the requests protocol to be that had value. You likely have other features in MVC that probably don't work properly without doing that. |
Adding the code below at the beginning of ConfigureAuth fixed the redirect_url, thanks. But now I'm getting an apologetically sounding error from LinkedIn: "Your LinkedIn Network Will Be Back Soon We’ve notified our operations staff that you are having a problem reaching LinkedIn." - any idea what's that's all about?
|
can you use the api through the proxy with just postman? |
Thanks will try postman next week. I've also opened a case with LinkedIn support, so see if they have any suggestions. |
Sorry to come back again, I really appreciate your help with this. I got the proxy issue figured out. I don't know if there's anything to test with Postman. The application generates a GET request when LinkedIn login button is pressed, and LinkedIn responds with an error - I'm not even getting to the part where I would enter credentials. Here's my application, really basic: https://linkedin-poc-soren.dppl.com/Account/Login (press LinkedIn button on the right, with Inspector open) |
Hello again, still trying to figure this out. I found this post about scope today: Could this have something to do with the malfunction I'm experiencing? I tried replacing the value of "scope" variable in my link, but that didn't help. Maybe there's something more that needs to be done. For comparison, here's a working link that I found on an unrelated site: Just out of curiosity I changed scope in the working link to r_liteprofile, and it returned an error. LinkedIn support is useless if you're not a partner. |
I moved the app to my local PC (no proxy) and I still get the same error. Looking at the registered application on LinkedIn, I see that OAuth2.0 Scopes "no permissions added". And I'm not able to modify that. Under (additional) Products tab, the closest thing I found is "Sign In with LinkedIn using OpenID Connect" - Standard Tier - whatever that means. There's no longer a plain "Sign in with LinkedIn" product, like this post describes: https://stackoverflow.com/questions/62390915/cant-add-oauth-2-0-scopes-linkedin Also led me to this page: https://docs.pathfix.com/integrating-with-linkedin
I wonder if they only support OpenID now. |
So, I added the product "Sign In with LinkedIn using OpenID Connect" to application registration. And now have scopes openid/profile/email listed. Then I used the link generated by your library, and changed "scope" value from "r_liteprofile,r_emailaddress" to "openid+profile+email", and the error was gone, it loaded the LinkedIn login form. then I tried to overwrite Scope option in my code:
But that simply appended the new values to existing r_* scope items. Looks like those may be hard-coded in your LinkedIn library. |
Hello TerribleDev, hope you had a nice break. Have you had a chance to look at the code? I think if I only had the ability to completely overwrite Scope, that could potentially solve the problem. Unless you see some other issues. Thanks. |
Greetings,
My application is behind a proxy which handles all SSL support, so the application itself is set up as non-secure website in IIS. When sign-in request goes out to LinkedIn, the "redirect_uri" uses "http://" prefix, but LinkedIn expects "https://". According to your code, looks like Request.Scheme is being used to set the protocol part. I tried using ProxyHost option, but that doesn't accept the protocol part (it's still prepended with "http://").
ProxyProtocol option would have been a useful feature, or allowing to override the protocol in ProxyHost ;) What solution would you recommend that would override "redirect_uri" in the request to incorporate "https"?
Thanks!
The text was updated successfully, but these errors were encountered: