Skip to content
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

Open
jzielke opened this issue Sep 16, 2014 · 8 comments
Open

Question on Callback URL and ProviderName #154

jzielke opened this issue Sep 16, 2014 · 8 comments
Assignees

Comments

@jzielke
Copy link

jzielke commented Sep 16, 2014

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

@PureKrome
Copy link
Member

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..).

@jzielke
Copy link
Author

jzielke commented Sep 22, 2014

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

@PureKrome
Copy link
Member

Yes, we hosted our own oAuth server

heh. I was scared you were going to say that (but guessed, that's what you ment).

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

image

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 HashSet or an IDictionary ?

@PureKrome PureKrome added this to the 2.0 - .NET 4.5 & Async/Await milestone Sep 22, 2014
@PureKrome PureKrome self-assigned this Sep 22, 2014
@jzielke
Copy link
Author

jzielke commented Sep 24, 2014

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
Cache["ProviderKey"] = providerKey;

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.

@PureKrome
Copy link
Member

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 :)

@jzielke
Copy link
Author

jzielke commented Sep 24, 2014

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

@PureKrome
Copy link
Member

don't bother with a PR because the current code is -way- off my latest branch. I've done some serious refactoring compared to master.

but well done! nice!

@PureKrome
Copy link
Member

@jzielke I coded this up on the 🚅 this morning. Thanks heaps for the idea! It will go into the next main release, though :(

PureKrome added a commit to PureKrome/SimpleAuthentication that referenced this issue Oct 10, 2014
@PureKrome PureKrome removed this from the 2.0 - .NET 4.5 & Async/Await milestone Oct 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants