Jumping to redirect uri of original page

[jeff-zucker]

[Edit] See summary of this issue below.

If we login on pageA on domainA, get redirected back to pageA, click on an HTML link that points to pageB on the same domain, if pageB calls UI.authn.checkUser(), pageB will load and then redirect to wherever pageA redirected to.

Test it for yourself. The link is a plain HTML anchor to a page that contains nothing but a call to UI.authn.checkUser() and some text.

https://jeff-zucker.solidcommunity.net:8443/test/jump-uri.html

[jaxoncreed]

Did the solution of saving the page uri in local storage then setting retrieving it after the refresh token redirect work?

[jeff-zucker]

I can only do that if I catch the page redirect, write the cookie, logout, and then create a link from the cookie. But in this example it's not a matter of saving anything. The link is hard coded. It is impossible to move off of pageA to pageB without redirecting back to pageA if both pages have currentUser() no matter where the link comes from.

[jeff-zucker]

At the moment, this issue only impacts browse.html in two not so-common cases - a) user mounts browse.html on their own pod and then tries to use it to examine their own pod - it works everywhere else but not on the pod it is mounted on which jumps out of browse.html, b) user is logged in and has a second window/tab at another browse instance - the second will redirect to the first.

[jaxoncreed]

It is impossible to move off of pageA to pageB without redirecting back to pageA

At least based on my understanding, if you save the URL on pageB right before currentUser() is called, you'll be able to restore it after it gets redirected to pageA.

[scenaristeur]

Could be same as https://github.com/inrupt/solid-client-authn-js/issues/1473 ?

[jeff-zucker]

@scenaristeur, it certainly looks like the same behavior.

@jaxoncreed - No, storing cookies does not solve this particular behavior. Do you agree with @scenaristeur that this is an inrupt/solid-client-authn-js bug? If so, I'd be inclined to close this here until that is fixed there.

[jeff-zucker]

The issue of two webapps in the same browser is covered here : https://github.com/inrupt/solid-client-authn-js/issues/1647. It is definitely an inrupt-client-authn issue, not a SolidOS issue. Apparently it is not currently expected to work. :-( That explains why I couldn't get it to work :-).

[jeff-zucker]

Summary of problems/solutions for this issue:

• Server-root index.html

  • Problem 1 : you can't know a user's webid before login so you can't hard-code a redirect link to their pod

  • Solution 1 : start mashlib on the server-root page, then when they get redirected after login, read the webid and redirect to the webid

  • Problem 2 : using that solution loses login because cookies are from the server root origin not the pod origin

  • Solution 2 : login at server-root; get redireced back to serverroot; write a cookie of the webid; logout; get redirected back after logout, read the cookie, erase the cookie, print a link to the webid document so the user can click the link, go to their webid document, and login there. See https://solidcommunity.net/index.html for the working code.

• pod-root index.html

  • Problem : Inrupt's solid-client-authn can only store one redirect URL for a given origin so that once a user has logged in with a given redirect URL, any pages on that origin will be redirected back to that URL. In this case, all links would keep reloading the index.html page.

  • Work-Around : It is a known issue with inrupt/solid-client-authn and can't be fixed until that is. So best option is to simply rename index.html in all user's pods so that they are no longer active but their data isn't lost.

• multiple web apps simultaneously

  • Problem : If you start browse.html or any webapp (e.g. solid-panes/dev) on domainA in one tab and then open it or any other app on domainA in a second tab, the second tab page will redirect to the same page as the first tab.

  • No solution until Inrupt's client changes. This is the caused by the same redirect behavior mention above for the pod-root index.html.

• running browse.html from a pod

  • Problem : if a user installs browse.html as a page on their NSS pod, it will mostly work as expected except that if they try to use it to examine their own pod, browse.html will close and NSS's databrowser.html will be opened.

  • Solution : Just be aware this can happen, so don't be surprised if testing in your own pod has slightly different results.