Repository navigation
Main web page login does not set up state of solid-auth-client in-page login #568
Description
Activity
So, what's the proposed plan to tackle this? It seems that the root of the problem is that the first authentication wasn't done by solid-auth-client, so the login is therefore not recognized by it.
If this line of reasoning is correct, then I see several options (there might be more):
- The authentication should be done by solid-auth-client. This means bundling it with node-solid-server.
- solid-auth-client should recognize that the authentication happened. This means that it should pick up the other authentication's state somehow.
- The built-in auth should notify solid-auth-client that authentication happened. This means that the built-in auth should set the solid-auth-client's state somehow.
- We fix the "asking again" problem by adding an extra check to the auth dialog for the built-in auth, and if it is successful, immediately redirects back.
I'm not sure which one is the better here; it all depends on the exact reason why the authentication is not recognized by solid-auth-client and whether that is easy to fix.
I prefer option
1.. Unfortunately there's no way to ask the browser "do we have a webid-tls session?" without possibly initiating a new session.Note option one cures also another much more minor problem that the UI for the main web page authentication is different from the UI for the in-page authentication.
Yes, in webid-tls in the old system, the first thing the script does is load the subject data, and so by the time it gets to render it, it can lok back at the triple metadata for that fetch, and pull the User: header form it, and save that, and all is good. No more round trips.
Some other options:
-
Make cookies non-http-only. We're still filtering on origin, so it would still be secure. (We started rejecting cookies from third-party apps in Reject cookies from third-party applications #526 for security reasons.)The workflow would be:
get to a protected resource, redirected to login, auth'd; get redirected back to original resource, server returns the data browser, and the data browser makes an AJAX request for the RDF as usual. -
RDF-protected resources result in a data browser, as proposed by @timbl. Instead of redirecting to login, server up the data browser (which then itself prompts for login). Gets a session cookie from the server as usual, and the token gets stored in local storage.
-
Option 3 would probably be the fastest to implement -- have the server add the credentials to logged-in users to the data browser page (by rendering it via a handlebars template), which would then store them in local storage.
Option 1 is also doable, but somewhat more involved.
Part of the problem with option 1 is that the current solid-auth-client popup architecture makes it unusable for Solid servers (specifically in multi-user mode). Since the popup (and callback url document) is bound to a particular origin (which is a misunderstanding of the popup threat model), it would only work with the main server uri (
databox.me) but not any of its subdomains (timbl.databox.me).Should be solved by #593, let's verify when that is merged.
On the dz_oidc branch,
If a user logs in to a databrowser page (using TLS in this case), the user is asked for all the choices to authenticate and presses "with certificate" button, and then the page loads.
However, when th code in the page runs, and solid-auth-client code isn't aware of the logged in state, and so the user gets asked to log in all over again. The localStorage which captutes the logged in state has not been set.
(Maybe for webidTLS this should be sessionStorage in fact so hat when the user closes the tab it doesn't get assumed for every use of the browser from then on -- in other words so that the solid logged in state properly echoes the TLS logged in state)
The damage of having the user log in twice is unacceptable.
Note we are comparing this with the original webid-tls world in which the user has only the certificate choice, and no other UI before they can get going and use the page.