-
Notifications
You must be signed in to change notification settings - Fork 82
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
Question on Callback URL and ProviderName #154
Comments
Hi @jzielke - sorry mate, I sorta don't understand the question. So - you have your own OAuth server and your own OAuth server is returning 2x It's easier to pass the providerKey across both ways .. but maybe it's possible via the state value (ie. state value is the key, with the providerKey being the value..). |
Hey @PureKrome Yes, we hosted our own oAuth server. Don't ask, long story and a PIMA everyday. The server does not look for a querystring on the callback URL so it just appends ?Whatever to the end of the callback URI that is passed up. Since there is already a ?ProviderKey in the URI, that does not work too well as the ? gets doubled. If the server was paying attention, it would append a &Whatever if it saw a ?Whatever already there. The server is written in Ruby so I cringe at the thought of even changing the code. I went ahead and put it in the local cache and everything seems OK so far. We will see what happens. Thanks for the response and great code, which I probably just broke. :) John |
heh. I was scared you were going to say that (but guessed, that's what you ment).
i guess the server should tokenize the querystring params and then pass them back. That said, I'm not sure if other providers like Google, FB, etc. actually allow that and do that. Hmm . I might see if I can get a spike to see if the code can 'remember' the providerKey in our code? Using a |
What I ended up doing, which seems to be ok, was to put it the cache in my provider and check the cache on the return call instead of the querystring. Where the session state, redirect url and redirect to provider URL are being stored I added a Since the only option is to use our provider, I don't see an issue. If multiple providers are allowed, things might get out of sync. |
This was the idea I was thinking (and waiting for @phillip-haydon to comment on). In our code, we Cache things also. So that's what I was thinking of maybe doing too. Which is basically what you're doing :) |
Yep, that is were I put it and in the AuthenticateCallback function below, put a double check to check the Cache if the Request.Query.providerkey comes back empty. Thanks for the help. I also made some other minor changes in comment spelling when I was looking through things. Just my OCD on curvy red lines under words in the IDE that can to be fixed. I can put it into a pull request |
don't bother with a PR because the current code is -way- off my latest branch. I've done some serious refactoring compared to but well done! nice! |
@jzielke I coded this up on the 🚅 this morning. Thanks heaps for the idea! It will go into the next main release, though :( |
Our OAuth Server appends to the end of the Redirect URI it's information and really does not look what is there. Not sure if this an OAuth thing as from what I have read, any extra params should be part of the state parameter.
Example Call
....&redirect_uri=http://localhost:7000/authentication/authenticatecallback?providerkey=[ProviderName]&response_type=......
Return Redirect
http://localhost:7000/authentication/authenticatecallback?providerkey=[ProviderName]?code=[Code]&state=[Some GUID]
If you notice there are two ? in the uri. One before the provider and one before the code=. The second ? is what the oAuth server is appending to the end of redirect_uri. When the code processes the providerkey, I get [ProviderName]?code=[Code] as the value, so of course it does not match and fails.
Is there something I can add to fix or change this? Is there any alternative to passing the providerkey as part of the redirect URI? Maybe looking it up in the cache or something?
Thanks
The text was updated successfully, but these errors were encountered: