Description

timbl

opened on Sep 2, 2017

Issue body actions

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

1. timbl

   added

   blocker

   bug

   on Sep 2, 2017
2. RubenVerborgh commented on Sep 2, 2017

   

   RubenVerborgh

   on Sep 2, 2017

   Contributor

   More actions

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

   self-assigned this

   on Sep 2, 2017
4. RubenVerborgh

   added this to the 4.0.0 milestone on Sep 2, 2017
5. dmitrizagidulin commented on Sep 2, 2017

   

   dmitrizagidulin

   on Sep 2, 2017

   Contributor

   More actions

   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.
6. RubenVerborgh

   assigned

   dmitrizagidulin

   and unassigned

   RubenVerborgh

   on Sep 2, 2017
7. dmitrizagidulin commented on Sep 2, 2017

   

   dmitrizagidulin

   on Sep 2, 2017

   Contributor

   More actions

   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
8. RubenVerborgh commented on Sep 14, 2017

   

   RubenVerborgh

   on Sep 14, 2017

   Contributor

   More actions

   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.
9. dmitrizagidulin commented on Sep 14, 2017

   

   dmitrizagidulin

   on Sep 14, 2017

   Contributor

   More actions

   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.
10. RubenVerborgh commented on Sep 14, 2017

    

    RubenVerborgh

    on Sep 14, 2017

    Contributor

    More actions

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

    added

    on-hold

    on Sep 14, 2017
12. dan-f commented on Sep 15, 2017

    

    dan-f

    on Sep 15, 2017

    Contributor

    More actions

    Fixed in #593
13. dan-f

    closed this as completedon Sep 15, 2017
14. timbl commented on Mar 23, 2018

    

    timbl

    on Mar 23, 2018

    ContributorAuthor

    More actions

    This bug seems to have crept back in.
    It certainly currently is a problem on timbl.com, using the current head of master 1a04fae
15. timbl

    reopened this on Mar 23, 2018
16. RubenVerborgh commented on Mar 23, 2018

    

    RubenVerborgh

    on Mar 23, 2018

    Contributor

    More actions

    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 returnToUrl is not escaped, causing this problem (and several other potential ones, related to query string for instance).
17. RubenVerborgh

    added a commit that references this issue on Mar 23, 2018

    Send full returnToUrl.

    8e3c6d0
18. RubenVerborgh commented on Mar 23, 2018

    

    RubenVerborgh

    on Mar 23, 2018

    Contributor

    More actions

    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.
19. dmitrizagidulin commented on Mar 23, 2018

    

    dmitrizagidulin

    on Mar 23, 2018

    Contributor

    More actions

    @RubenVerborgh Great work on this!
20. RubenVerborgh commented on Mar 23, 2018

    

    RubenVerborgh

    on Mar 23, 2018

    Contributor

    More actions

    @dmitrizagidulin Thanks, now it's your turn in nodeSolidServer/oidc-auth-manager#17 😉
21. RubenVerborgh

    added a commit that references this issue on May 4, 2018

    Send full returnToUrl.

    299f5d6
22. timbl

    added

    authentication

    on May 9, 2018
23. RubenVerborgh commented on Jul 19, 2018

    

    RubenVerborgh

    on Jul 19, 2018

    Contributor

    More actions

    Should be fixed.
24. RubenVerborgh

    closed this as completedon Jul 19, 2018

Issue actions