Repository navigation
Fragment identifier on main page URI is stripped in login process #571
Description
e.g you open a new Chrome, go to incognito mode, and load:
https://timbl.com/timbl/2017/Solid/HighLevelIssues/index.ttl#this
You end up getting to
https://timbl.com/timbl/2017/Solid/HighLevelIssues/index.ttl
This is only a problem the first time, because of all the redirects, not later when the login state has been stored.
Seems to be a problem with eith TLS or OIDC forms of login. I thought @RubenVerborgh fixed this, at least for OIDC.
Activity
RubenVerborgh commentedon Sep 2, 2017
So the previous bug was #562 and involved a fix in the general 401 response. I'll check what's going on.
dmitrizagidulin commentedon Sep 2, 2017
We fixed the server side redirect, but not for cases where the auth process is initiated from witnin a mashlib app. Will post details shortly.
dmitrizagidulin commentedon Sep 2, 2017
The fix in #562 addressed a slightly different use case.
In this case, however, the hash fragment is being lost - first during the oidc identity provider's authentication response (the provider overwrites the hash fragment with auth response credentials), and second when the auth client parses the response and clears the credentials from the uri.
The upstream issues to fix are:
oidc-op#38-Preserve redirect_uri hash fragment during implicit flow AuthenticationResponse andsolid-auth-client#28-Preserve original redirect_uri hash fragment when parsing authentication responseRubenVerborgh commentedon Sep 14, 2017
Given that nodeSolidServer/solid-auth-client#28 is done, we should be able to close this.
I'm not sure that we need nodeSolidServer/solid-auth-client#28, as the hash is added by solid-auth-client. @dmitrizagidulin, do you think this is still necessary?
We might need to be careful to avoid both components trying to add the same hash. It they do, we might want to lock oidc-op to 0.3.0 for now.
dmitrizagidulin commentedon Sep 14, 2017
Yeah, i think this issue is now resolved and can be closed. And no, don't worry, the oidc-op component will not interfere w the auth client restoring the hash.
RubenVerborgh commentedon Sep 14, 2017
Can be tested after #593, and closed if successful.
dan-f commentedon Sep 15, 2017
Fixed in #593
timbl commentedon Mar 23, 2018
This bug seems to have crept back in.
It certainly currently is a problem on timbl.com, using the current head of master 1a04fae
RubenVerborgh commentedon Mar 23, 2018
So https://timbl.com/timbl/2017/Solid/HighLevelIssues/index.ttl#this currently redirects to https://timbl.com/api/auth/select-provider?returnToUrl=https://timbl.com/timbl/2017/Solid/HighLevelIssues/index.ttl#this.
Note how
returnToUrlis not escaped, causing this problem (and several other potential ones, related to query string for instance).Send full returnToUrl.
RubenVerborgh commentedon Mar 23, 2018
There was a bug on the node-solid-server side, which #648 fixes. The correct URL is now passed to oidc-auth-manager, which now needs to be fixed to handle that URL correctly.
dmitrizagidulin commentedon Mar 23, 2018
@RubenVerborgh Great work on this!
RubenVerborgh commentedon Mar 23, 2018
@dmitrizagidulin Thanks, now it's your turn in nodeSolidServer/oidc-auth-manager#17 😉
Send full returnToUrl.
RubenVerborgh commentedon Jul 19, 2018
Should be fixed.