Fragment identifier on main page URI is stripped in login process

[timbl]

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.

[RubenVerborgh]

So the previous bug was #562 and involved a fix in the general 401 response. I'll check what's going on.

[dmitrizagidulin]

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]

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 and
• solid-auth-client #28-Preserve original redirect_uri hash fragment when parsing authentication response

[RubenVerborgh]

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]

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]

Can be tested after #593, and closed if successful.