Way to disable girderToken in hash on oauth callback?

[zachmullen]

trafficstars

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]

@mgrauer @subdavis DANDI tag

[subdavis]

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]

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]

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]

https://github.com/girder/girder_web_components/pull/189 is one possible solution. There are others.

[zachmullen]

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?