Recover Session object in the same domain when switching to a new path/page

Hi,

I guess the short answer to my question is going to be NO, but I would like to continue the discussion of the existing topics: Session restore with solid-client-authn-browser, Losing session when going to different page after login , to see if there’s any progress on this area or someone has a clever workaround in order to be able to reconstruct a Session object in a new page inside the same domain.

I basically get a valid session in my index.html via login request and I try to “force” restoring it but when I navigate a different page detailview.html there’s no way I can generate again the same session. I tried by sending the sessionId as a query param in the URL:

http://localhost:1234/detailview.html?sessionId=18e878b1-0661-434e-94bb-b3c8e1cbe151

to invoke any of the the methods:

await session.clientAuthentication.getSessionInfo(sessionId)

or

await session.clientAuthentication.validateCurrentSession(sessionId)

but the resulting info is not as expected.

In index.html / index.js I get:

{
    "sessionId": "cd43afb5-9381-45a2-bb3a-a61706117fa5",
    "webId": "https://fandroide.solidcommunity.net/profile/card#me",
    "isLoggedIn": true,
    "redirectUrl": "http://localhost:1234/?state=0ec498c2ef964c6abdd8c2636a0d23c0",
    "issuer": "https://solidcommunity.net",
    "clientAppId": "5138d1ea8ad2cb2871243c179d6b996b",
    "clientAppSecret": "d4b0c72d99db894333a162dbda516029",
    "tokenType": "DPoP"
}

but in detailview.html / detailview.js I get:

{
    "sessionId": "cd43afb5-9381-45a2-bb3a-a61706117fa5",
    "isLoggedIn": false,
    "redirectUrl": "http://localhost:1234/?state=0ec498c2ef964c6abdd8c2636a0d23c0",
    "issuer": "https://solidcommunity.net",
    "clientAppId": "5138d1ea8ad2cb2871243c179d6b996b",
    "clientAppSecret": "d4b0c72d99db894333a162dbda516029",
    "tokenType": "DPoP"
}

No webId is defined nor "isLoggedIn" is true, despite the rest of the values are the same (clientAppId, clientAppSecret, etc)

I also know the resulting session object is not valid because if I try to fetch any private resource I’ll get a 401 Unauthorized error.

I thought something like:

const newsession = new Session(session, sessionId)

could do the trick but it’s not.

If someone is interested in giving it a try here’s the repo and steps to reproduce it:


    git clone https://github.com/fan-droide/solidclientwebapp.git
    cd solidclientwebapp
    git checkout test-session-btw-pages
    npm i
    npm start

Any suggestion would be appreciated, thank you!

Try passing the restorePreviousSession option, that should have the behaviour you want, but note: the redirectUrl and clientName / clientId + clientSecret / clientId (url) must be exactly equal between your pages, otherwise you’ll get issues.

The redirectUrl is also cached for the lifetime of that client (such that someone can’t MITM or CSRF attack your application through the authn SDK).

We generally recommend using a single page application architecture, we’re your using one javascript execution context for the lifetime of your application, e.g., using react-router in React, vue.js or angular, as this makes a whole bunch of things simpler & the user experience also more seamless. (I’m not sure how the History API work when changing documents off top of head, but maybe you could try that too).

If the page/document unloads, you loose the state that’s held in-memory by the SDK, and it needs to be recreated.

Also: Just to repeat myself, session.clientAuthentication is an private internal API of the SDK, and not a public API, therefore it may be subject to breaking changes in any release, only the public API of our SDKs is supported per the Inrupt Product Lifecycle and Maintenance Policy.

2 Likes

Just to add on top of @ThisIsMissEm’s response, session restore across different pages on the same domain is very similar to session restore on browser refresh, which is described in our authentication documentation.

Mostly, you’ll want to have a call to handleIncomingRedirect with the restorePreviousSession flag set when loading pages where you want the session to be restored. As @ThisIsMissEm pointed out, you may be interested in frameworks handling client-side routing.

2 Likes

Thanks @ThisIsMissEm and @zwifi for your feedback!

I’ve tried with restorePreviousSession = true but I’m afraid it’s not working as expected. You can check the code here:

The flow I need is described as follows, in case it helps to understand better the scope:

  1. At Home Page (index.html ) the user can authenticate by choosing any issuer, in this case Inrupt. The user clicks on “Redirect Login”:

  1. If the user successfully logs in, it’s redirected to Home Page again and the WebId is shown and the Session object contains info (see console’s screenshot):

  1. Then the user clicks on “Go To Detail” to navigate to /detailview.html but there the session can’t be restored:

I’ve tried with getDefaultSession() but it doesn’t help either.

NOTE: I don’t want to force automatic navigation or redirect to detailview.html after login, I want to keep a valid session on both pages, index.html and detailview.html.

A demo app for the aforementioned code can be found here:

https://solidwebapp-7a3cf.web.app

Thank you so much again for your replies and help!

Looking at your code, detailed view isn’t doing a login or handleIncomingRedirect, only index. As there’s a fullpage navigation between index & detailed, both will need that logic, as when you do a fullpage navigation, the javascript context is lost.

The smoothest user experience really is to use client-side routing, otherwise every page in your app will have to go through the login/restore process, rather than having a seamless experience.

1 Like

Thanks again for your great support, @ThisIsMissEm!
I think that’s the answer I was expecting but I wasn’t sure if there was another mechanism to restore the same Session object being in the same domain though a different page. I hope this topic can help in the future to others that have the same question and who knows, maybe someone has a new proposal as it was not obvious for me after going through the documentation. I’ll investigate client-side routing :slight_smile: