Login button visible with private resource using nss #78

[josephguillaume]

Not yet sure if this requires a solid-ui, auth, or NSS solution.

This is adding more detail to: https://github.com/solid/solidos/issues/70#issuecomment-940146896 "On NSS : Login to server-root, on your pod, click on the goto link of a private container. The opened page will show you as logged out but it will also show you private resources."

I have the problem happening sometime after having logged in (possibly days?) when I use a bookmark to go straight to a private resource.

It looks like the problem can occur simply because UI.authn.authSession.info.isLoggedIn=false even when an NSS cookie is set and therefore private access is indeed possible.

To replicate:

1. Go to a private resource on solidcommunity.net
2. Login
3. Delete all localStorage but keep cookies
4. Refresh page
5. Private resource is shown and editable but login button is also shown and UI.authn.authSession.info.isLoggedIn=false

If loggedIn status was based on wac-allow it would be correct, but also dependent on the resource being viewed.

I haven't checked but my guess would be that solid-client-authn-browser relies on the redirect dance to determine logged in status and this is somehow able to be bypassed when the cookie is used??

One fix for the UI to be correct would be to clear the cookie if UI.authn.authSession.info.isLoggedIn=false ...

Edit: isLoggedIn gets set by the redirect handler https://github.com/inrupt/solid-client-authn-js/blob/287f3b8b89d7b0cfb94c8dc251d51eb5380b6412/packages/browser/src/login/oidc/redirectHandler/AuthCodeRedirectHandler.ts#L222 If checkuser fails in solid-ui, mashlib still tries to render the subject using outliner from solid-panes, which succeeds in fetching it as if it is a public resource because the cookie allows it.

[josephguillaume]

This should maybe be a new issue, but it is the converse of this one, so I thought it's worth mentioning here.

When using the community solid server the NSS cookie is obviously never set so the login state is always correct.

Instead, mashlib breaks for things like private images. Mashlib does not seem to make an authenticated request - it relies on authentication via the NSS cookie. On CSS the image fails to load because the DPOP token is not provided and the cookie is not available.

We're caught in the middle of the two authentication mechanisms and we either need to completely switch to DPOP and drop the cookie, or explicitly prefer the cookie for requests on the pod's subdomain (only available using NSS) and explicitly fallback to DPOP when unavailable...?

I notice that solid-client-authn-browser does have some kind of temporary support for cookie based auth for requests, but it's not clear to me that mashlib is using this or that it is useful in this context. https://github.com/inrupt/solid-client-authn-js/blob/784d86c907b4f0c1047b0ee3371df682eadc03ff/packages/browser/src/login/oidc/redirectHandler/AuthCodeRedirectHandler.ts#L244

Edit: I have now added a comment on an existing issue for CSS compatibility of the slideshow pane: https://github.com/solid/solid-panes/issues/301#issuecomment-971409638

[bourgeoa]

@timbl @theRealImy Is this a very general question with solidos or rdflib to default fetch with credentials: 'include' https://developer.mozilla.org/fr/docs/Web/API/Request/credentials

[bourgeoa]

@josephguillaume

When using the community solid server the NSS cookie is obviously never set so the login state is always correct.

Instead, mashlib breaks for things like private images. Mashlib does not seem to make an authenticated request - it relies on authentication via the NSS cookie. On CSS the image fails to load because the DPOP token is not provided and the cookie is not available.

For querying CSS are you using SolidOS webApp (/browse.html) or CSS with an internal SolidOS (https://github.com/solid/community-server-recipes) ?

[josephguillaume]

The CSS case is using an internal SolidOS using community-server-recipes, so the same-site cookie mechanism would work if CSS supported it (which presumably would require it to be in a solid spec somewhere). It's also not a CORS issue.

It's not clear to me that credentials: 'include' would actually use the custom fetch defined by solid-client-authn-browser, which is what would be needed. Note also that in the case of images we're not using fetch directly at all - the url in e.g. slideshow pane is currently specified using the src attribute.

Edit: some ugly workarounds: https://stackoverflow.com/questions/46642960/authorization-header-in-img-src-link https://stackoverflow.com/questions/34096744/how-should-i-load-images-if-i-use-token-based-authentication

It seems like dropping same-site cookie requests would dramatically increase complexity for things like images, and using a cookie is actually one of the listed workarounds for inability to add authentication headers...

[bourgeoa]

@josephguillaume Thanks. I also found this.

https://www.twelve21.io/how-to-access-images-securely-with-oauth-2-0/#:%7E:text=4.%20USE%20SERVICE%20WORKERS

@RubenVerborgh have you any idea to feed our discussion ? Is there a specification issue ?

[RubenVerborgh]

The client/server login state disagreement is a longstanding NSS issue indeed.

The path we've chosen with CSS is to not implement the cookie approach, because the security implications are not clear. This indeed means that non-public resources can only be accessed through apps.

The modern workaround that was recently recommended to me is the Blob API.

[josephguillaume]

Using the Blob API works fine for me and component-based development environments can abstract out the complexity, e.g. https://forum.solidproject.org/t/how-to-add-inline-content-in-an-authenticated-solid-app/4929/5

I'd suggest the next step for this issue is to turn off cookie based authorization for NSS, which would then mean it has the same behaviour as CSS.

Presumably this would be done / would require a new config option here: https://github.com/solid/node-solid-server/blob/830f8849f345e40e471c9efb15dc443825cdbda2/lib/create-app.js#L198

This will obviously break a fair few things in mashlib, but fixing them while using CSS as the test server seems like it provides a clear transition path. Until the transition is complete, the login status on NSS+mashlib would be unreliable, but I don't think it's worth implementing an additional cookie detection routine if it just gets phased out eventually.