Restore session for several applications under the same origin

[josephguillaume]

I'm hosting PodOS elements-based apps on my pod running SolidOS.
If I am logged in to SolidOS and then try to open one of the PodOS apps hosted on my pod, PodOS instead redirects to SolidOS. I am unable to use my PodOS elements-based app unless I turn off restore-previous-session.

Conversely, if I login to to the PodOS app first, I am unable to open SolidOS until the session expires (and silent authentication fails).

This happens because of the upstream issue inrupt/solid-client-authn-js#1647

I expect the same error would occur if:

• I am hosting PodOS elements-based apps on my pod running PodOS.
• I have two PodOS apps hosted on the same domain

[josephguillaume]

The issue and possible solutions are discussed in the upstream ticket.

For PodOS, possible solutions include:

1. Waiting for upstream to resolve the issue
2. Reimplementing session restore functionality and not using the upstream
3. Using client identifiers in parallel to the upstream, as suggested in Restore previous session #8 (comment)

Two key use cases for PodOS are affected, with different consequences.

If I'm hosting PodOS elements-based apps on my pod, I am unable to use them in conjunction with SolidOS running on that pod. I can either turn off restore-previous-session (until option 1 or 2 is realised), or if option 3 is implemented, the app would need to use a client identifier document and the two session restore mechanisms could coexist.

If I'm using PodOS as the interface for my pod, then I can't host any other app using the upstream library on the same domain. That might be an acceptable outcome already given that PodOS is operational. I don't think a client identifier can be used in this case, as the intent is to redirect to the window location in every case, but perhaps there is a way to use a single redirect url?

[angelo-v]

+1 for implementing support for client identifiers. In case of the pod interface version one could redirect to the root of the pod, then client side routing needs to redirect back to the original URL