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

Way to disable girderToken in hash on oauth callback? #188

Open
zachmullen opened this issue Oct 11, 2019 · 6 comments · May be fixed by #190
Open

Way to disable girderToken in hash on oauth callback? #188

zachmullen opened this issue Oct 11, 2019 · 6 comments · May be fixed by #190
Labels
bug Something isn't working

Comments

@zachmullen
Copy link
Member

Right now there doesn't seem to be a way to change the callback URI, which automatically contains the Girder auth token.

Ideally I'd like a way (maybe it should be the default?) to not append a hash string at all. As of right now, it's creating malformed URLs with multiple hash strings in cases when the starting URL already contains a hash component.

@zachmullen zachmullen added the bug Something isn't working label Oct 11, 2019
@zachmullen
Copy link
Member Author

@mgrauer @subdavis DANDI tag

@subdavis
Copy link
Contributor

subdavis commented Oct 11, 2019

Where should it go instead?

Ideally I'd like a way (maybe it should be the default?) to not append a hash string at all.

I don't think I'm following. It seems like this would prevent authentication altogether.

it's creating malformed URLs

Could you share an example?

location.hash = location.hash.replace(`${OauthTokenPrefix}${token}${OauthTokenSuffix}`, '');

This should only result in the removal of the girderToken parts.

@subdavis
Copy link
Contributor

Are we talking about the situation where the GWC app is served from the same origin as girder such that it has access to the cookies set by girder and therefor doesn't need to read the token from the hash string?

@zachmullen
Copy link
Member Author

It's this bit

return (await this.girderRest.get('oauth/provider', {
            params: {
              redirect: `${window.location.href}${OauthTokenPrefix}{girderToken}${OauthTokenSuffix}`,
              list: true,
            },
          })).data;

I am not doing anything to read the token from the hash, I think it's fine just getting set via the cookie since I'm same-origin.

@subdavis
Copy link
Contributor

#189 is one possible solution. There are others.

@zachmullen
Copy link
Member Author

I'm not sure what solution is best, I was originally thinking of just stripping out the whole infrastructure surrounding our automated token setting from the hash and just letting downstreams handle this with an oauthRedirect prop and using their own vue-router downstream.

This line is the culprit in my case. setCookieFromHash is a bit messy, in that it doesn't just set the cookie, but it also mucks around with the hash.

Because I'm same-origin, I do have that cookie, so setCookieFromHash is never being called. So each time I logout and login my hash is just getting longer and longer e.g.

http://localhost:8081/#/#girderToken=2CRLmVUqkhXG5ljL5ZTz71F1dnmKhPBAuIufReyGKAzMqnR9ICuH5v4wm7MGPXHe__#girderToken=mqQ4JQ0bvJvTDftegaMAAMHXY9DvoIVk3Ww1PcSVksp7J9xSYnY4yeLGXQlJZhxd__.

The redirect itself is problematic because window.location.href may already contain a hash, but this code essentially assumes it doesn't. It happens to work because we're using naive string replacement in setCookieFromHash, but it doesn't feel great.

Would anyone be heartbroken if I just ripped this functionality out and made this downstreams' problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants