auth-upgrade : old login/logout is not using the new authorization

[bourgeoa]

Some internal NSS web apps are using the old authentication.

• the register page : https://github.com/solid/node-solid-server/blob/main/index.html
• the root/index.html page for pod's created before NSS 5.1.7 https://github.com/solid/node-solid-server/blob/v5.1.6/default-templates/new-account/index.html

[jeff-zucker]

This is considerably more complex than I first thought. The problem is that we can not login from outside SolidOS and then load a SolidOS page because loading a new page loses the login. The new auth flow requires that the login be from SolidOS itself, not outside SolidOS.

For the register page (https://solidcommunity.net/index.html) I think the best we can do is provide an input box for them to enter their username which would bring them to their podRoot. If they have no index.html they will get a SolidOS page with a login button. If they have an index.html with links to e.g. /public or /foo and those links would go to SolidOS pages with login buttons.

Thoughts please!

[jeff-zucker]

Further investigation shows that if I use inrupt/solid-client-authn-browser directly, I can set the redirectUrl in the webapp. BUT the redirect URL must be known before the login happens. On a user's index.html we can hard-code a redirect to their profile or storage. On the server root we can't know their webId without asking so there is no way to have a login button there AFAIK.

[ewingson]

so given the server root on the one hand and the pod root of a user on the other hand we have to differentiate between

<button id="login" type="button" class="hidden btn btn-default btn-success">Log in</button>
((using /common/js/solid-auth-client.bundle.js))
and

<script>document.addEventListener('DOMContentLoaded', function() { panes.runDataBrowser() })</script>

the complexity of the issue is stunning me and it seems not clear, if we can keep the upper.

[timbl]

I wonder whether all the workflows around registration and login at the server pages were documented anywhere.

Asking some for their webid never used to a thing, as you would log in, the login process would remember it or ask for it, and then the app would get it returned from the auth code. If their go to the root of the server then we could log them in to find which user they are, and then I guess redirect them to their pod. But normally that should not be a path they use, they should normally bookmark their pod not the server.

Maybe if people need to be reminded where their pod is on thd server we could store their webid in a cookie of the server, but that is not crucial.
I'm trying to understand which workflow we have problem with. Is it registration, or someone logging onto the root and being directed to their pod, or something else?

[SharonStrats]

I guess the question is do users usually go to their index.html and stay and not go to SolidOS? If the answer to this is not usually. If the predominant behaviour is to go directly from there to SolidOS, then I really prefer what you are suggesting. As I think the current behaviour isn't ideal for those who go to SolidOS after because we have to login twice. If we know their webID then great, otherwise the next best thing. Or maybe a button that says go to your "POD" or such to login.

[timbl]

If part of the problem is people who have put an index.html file in their own pod, (which is very reasonable as everyone should have their own web site, then how about having a backdoor to a control panel which will allow them to get in and configure their pod, looking at the files in the pod root objectively with no interpretation. Like

https://bob.solidcommunity.net/.well_known/solid/dashboard

or something like that we would program the server to respond to that address for any pod. Or is there an existing account page in .well_known space which we could add this functionality?

[bourgeoa]

@jeff-zucker

1. the actual process on server root register is the following :

• register/login page : if click on login
• logout page with a link to the user logged in
• if click on the link redirect to the user profile page

May be you can do the same process.
When logged-in can we redirect to any page in same pod and stay logged-in ?

2. pod root with index.html you solved it and I tried it. It works.
   This is my podRoot/index.html with redirect to /public (update of your code)

<!DOCTYPE html><html><head>
  <meta charset="UTF-8" />
</head><body>
  <span id="webId"></span>
  <input id="oidc" value="https://solidcommunity.net:8443" style="width:24em" />
  <button id="loginButton">Login</button>
  <button id="logoutButton">Logout</button>

<script src="https://cdn.jsdelivr.net/npm/@inrupt/solid-client-authn-browser@1/dist/solid-client-authn.bundle.js">
</script>
<script>

const iscan = solidClientAuthentication;
var session = iscan.getDefaultSession();

const loginButton = document.querySelector("#loginButton");
const logoutButton = document.querySelector("#logoutButton");
const webIdArea = document.querySelector("#webId");
loginButton.onclick = ()=> { 
  return iscan.login({
    oidcIssuer: document.getElementById("oidc").value,
//    redirectUrl: window.location.href,
    redirectUrl: "https://bourgeoa.solidcommunity.net:8443/public/",
    clientName: "Minimal login/logout"
  });
};
logoutButton.onclick = async ()=> { 
  await session.logout();
  showLoginStatus();
};
 async function handleRedirectAfterLogin() {
  await iscan.handleIncomingRedirect();
  showLoginStatus();
}
function showLoginStatus() {
  session = iscan.getDefaultSession();
  if (session.info.isLoggedIn) {
    loginButton.style.display = "none";
    logoutButton.style.display = "inline-block";
    webId.innerHTML = `Logged in as ${session.info.webId}`;
  }
  else {
    loginButton.style.display =  "inline-block";
    logoutButton.style.display = "none";
    webId.innerHTML = `Not logged in.`;
  }
}
//handleRedirectAfterLogin();
</script></body></html>

[timbl]

All these are solved by that code?

[jeff-zucker]

No, unfortunately that isn't a solution. There are two workflows involved.

1. The server root index.html has a login button which formerly was able to let the user login, then grab their webId from the login and print a pointer to their profile. This will no longer work because we need to redirect directly to the profile, not back to the index.html and we can't know which profile to redirect to until after the login and we need to specify the redirect before the login. We could ask for the username, go to login, redirect to that username's pod or profile, but that would mean asking for username twice. I suggest we replace the login button with an instruction sentence "Go to your Pod to login". I do not see logging in from the server root as a common flow.

2. The pod root index.html at some user's "home page" has a login button that will also not work for the same reasons. @bourgeoa - yes it's possible to rework my code to redirect from the home page to the profile, but that is not really what we want for either the user or the visitor. I am in favor of Tim's suggestion above that we have a special address for user to get a databrowser view of their pod root. So the user would login at that backdoor or at one of their pod pages, not at the index.html. Visitors would not need to login at the index.html, They can just click on one of the links on the index.html and then login on that link rather than on the index.html. I don't see a problem with this, there isn't really any advantage for the visitor to login on the index.html page itself rather than on a content page that requires a login.

@ewingson - yes we would need to remove the existing code for the login buttons but no we would not need to replace it with a script. Let's say the visitor comes to https://you.solcom.net/index.html and clicks on a link to https://you.solcom.net/public/ - there will be a login button on the /public/ page because it is a page served by the databrowser and login in there will keep the login as long as the visitor stays in that databrowser. So from a dev's point of view, things are very simple - no login buttons on HTML pages, login buttons on all other pod-served pages as part of the databrowser with no need for any special login code in the HTML.

[ewingson]

@jeff-zucker @timbl @SharonStrats @bourgeoa @theRealImy

Let's say the visitor comes to https://you.solcom.net/index.html and clicks on a link to https://you.solcom.net/public/

this connects some imaginary dots in my (apprentice) mind.
in special, we would make the login-code in the you subdomain part, not in the server root.

besides, that is how I chose to make on solidweb.me, as @RubenVerborgh said there will be no standard UI.
which shows, the path is not completely wrong.

thank you all for your patience explaining the stuff.
if its just questions I ask, that keep me learning and help clarify things, sure.

• we will have the actual Login-Button using a link on the pod root index
• why do I hesitate to actually code stuff (it all seems like not interconnected in my 3 pounds brain)

from my experience side I just can tell one small simple detail: when upgrading NSS per npm I have to manually put hands on the index.html (which in future might only show the user the path/link) - I begin to think as a dev - if not like a machine

[timea-solid]

@ewingson yes I feel the same.

Now after understanding (connecting the dots), I fully support the removing of login from non databrowser (SolidOS server) pages. This would be a step forward towards a better UX.

My opinion on your thought @jeff-zucker

1. A user mostly lands on solidcommunity.net to register a Pod. When they registered they are, already, being redirected to their Pod. So, people who navigate to solidcommunity.net and already have a Pod should be guided to their Pod -> "Go to your Pod to login"

2. I agree with Tim's suggestion too (now that I understand). We do have different views for the user so lets make use of them. See diagram: https://miro.com/app/board/o9J_lsrieoc=/?invite_link_id=802499867311

[jeff-zucker]

we would make the login-code in the you subdomain part, not in the server root

No, we will not make any login code at all. Logins will all happen using the databrowser and do not require any extra code. Users will not login on an index.html page. They can go to an index.html page and link from there to a databrowser page and login in on that databrowser page.

@RubenVerborgh said there will be no standard UI

That's correct, no standard UI will come with CSS, each pod provider will have to provide their own, either mashlib or penny or something else. But that does not mean that it is a good idea to have servers with non-standard setups, especially at this point in Solid when it is hard enough developing tutorials and materials to teach people how to use pods. "CSS provides no front-end to pod providers" is different from saying "Pod providers should provide pods to users with no front-end."

[jeff-zucker]

So the consensus seems to be that we should not have login buttons on index.html pages.

Further, @timbl said in chat :

It would be best for future maintenance if we could delete all files which are unchanged versios originally stored in tehir pod and not touched by them.

So, any objections to this plan? :

• server root : replace login button with non-clickable message "If you already have a pod, go to it's address (like https://YOU.solidcommunity.net/) and login there." (wording changes welcome)
• pod root :
  • no index.html = no action
  • index.html unchanged from server-supplied index.html (based on length?) = delete it
  • user-modified index.html = leave as is
• registration page :
  • replace login button with same text as server root

We would need to warn users about the changes and tell those with modified index.html pages that they should remove login buttons from those pages.

[ewingson]

a) server root

direct user to pod makes perfectly sense (check for cookies ?) ... must be non clickable cause in that point of time we don't know the user...

b) pod root

LGTM (maintenance needed)

c) regging

the simplest part, remove

then the actual login happens at the second site, will that confuse them ?
concluding after all this seems like simplification, no objections (but what do I know?)

[jeff-zucker]

@ewingson - my suggestion was to remove that button and replace it with the same text as on the server root page, for the same reason. We don't yet know who the user is.

[ewingson]

@jeff-zucker

this seems well thought through simplification
and finding the index.html's in question seems manageable

[bourgeoa]

We must not neglect that a pod is a web server.
It is difficult to pretend that the web apps in general should not have login/logout functions.

Do I misunderstand something ?

The server root/index.html with register/login is mainly used after pod creation. It is the way to return to the user his webId and link to his profile.

[jeff-zucker]

@bourgeoa - I'm afraid that I don't understand what you are saying. I also don't understand what you mean by a "webapp". The index.html pages are not apps. What does logging in to an index.html accomplish?

[jeff-zucker]

It is the way to return to the user his webId and link to his profile.

That flow is no longer possible. The webId can only be returned to a known place and we can't know what place that is until they are logged in. So logging in on the server root page will only return to the server root page and clicking a link to their profile from that page will lose the login.

[bourgeoa]

That is the actual process

[jeff-zucker]

I still have no idea what part of this you either object to or think should be done differently.

[bourgeoa]

When you register a new pod you need to be returned you webId this is the identity provider part of NSS. Then you should be proposed to link to login to that pod storage.

[jeff-zucker]

Yes, that part works fine - after you register you are directed to your pod where you need to login. I am not suggesting any changes to that. I am talking about removing the login button from the index.html before you register.

[jeff-zucker]

And removing the "already have an account" button on the registration page itself. But leaving the rest of the registration flow the same - redirects to the pod where user needs to login.

[bourgeoa]

Ok agreed I had a wrong workflow just checked by creating a new pod that you are redirected to you pod.
The only point a bit disturbing is that nowhere you webId is displayed as such : this is your webId : xxxxxxx
But that can be revisited later.

[ewingson]

the Webid is shown in the old (1) and new (2) index.html (in 2. it might be fn for formatted name)
we should not step back, so it's solveable
[edit] just realized, 2. might be already an app/databrowser/solidos page and no real, physical index.html which indicates this is not part of the problem

[timea-solid]

Sorry to insist, the current user experience, flow (before auth-upgrade) is depicted here: https://miro.com/app/board/o9J_lsrieoc=/?invite_link_id=998159892622
I confirm that after registration one is redirected to pod root.

[timea-solid]

I am personally not sure about the user experience if we delete the pod root page - did I understand it correctly?
Is this the root pod index page?

However, I propose to have a branch for these changes in place and simply test it out and see how it looks/feels to the user flow.

[ewingson]

if I get it right, this |^ is the result of the databrowser app and not a filebased index.html.
but yes, this is the pod root. only mashlib has (kindof if you want) calculated it. this is what we get without index.html. prior 5.1.7 shall be deleted. just my understanding of it.

[jeff-zucker]

@timea - That is the pod root but it is not an index.html, as @ewingson says, that page is autogenerated by mashlib. It has its own issues but they are not related directly to the question of the index. html. The index.html page occurs at the pod root only if the user created one or got an assigned one before 5.1.7 . What you are showing is what one sees if there is no index.html.

Pod root has three different possibilities. a) If the user got an account before 5.1.7 and did not erase it, got an actual index.html. You can see it here : .https://github.com/solid/node-solid-server/blob/v5.1.6/default-templates/new-account/index.html. That is what we want to eliminate if unchanged. 2) If the user does not have an index.html and the visitor is not logged in, they see what you posted two comments up - a databrowser-generated page with the home icon active, that is a databrowser page, not an HTML page so logining in from there is fine. 3) If the user does not have an index.html and they go to their pod root when logged in, they will get that same generated databrowser page but with a menu for "my stuff", "my storage", etc. That is also a databrowser page so does not need any changes related to this issue.

Server root has a button to login and a button to sign up. The login button needs to go because it logs us in to the index.html page, not to a databrowser page. The sign up button should stay and properly returns the user to their pod. The registration flow should not change, the buttons to login instead of register need to go.

So the changes are only to remove the login button from the server root and from the registration page but not otherwise touch the registration flow. And for people who got an index.html but didn't change it, that index will be erased and users will instead see the home-icon page you showed.

[jeff-zucker]

Summary of progress so far.

a) Initially tried to redirect from server-root index.html to login back to index.html and either redirect or link to pod. Tried with both ui-authn and directly with inrupt/solid-client-authn-browser. In all cases it would go to the pod, and then immediately redirect back to index.html.

b) Then tried to add mashlib to the server-root index.html. I was able to go from index to login, back to index where I used gotoSubject() to get to the user's pod. This worked with a test file in my own pod and successfully kept the login. However, with @ewingson's help, I saw that this would not work when served from my pod because of 403s generated by a mismtatch of origins.

c) I have now created a version of b that replaces the existing default-templates/server/index.html with one using the same method as b. It is here: #1620. Waiting to see if when depoloyed at server root we can avoid the 403s.

[timea-solid]

Update after the latest PR from Jeff:
"So it looks like logging in on the server-root rather than the pod-root breaks the ability to open new tabs/windows with login kept. This is because the cookies are set by domain and there is a mismatch. What this means for user is that they can click "show your profile" and the "goto" links when logged in at their own pod and the links will preserve the login however the links will not preserve the login if they logged in at the server root."
To be continued...

[timbl]

Propose we solve this later after rolling out the new mashlib and NSS

[jeff-zucker]

After much experimentation, the server-root index.html is solved - we redirect to a page showing the user's pod address and let them click it then login again on their pod. The user's pod root index.html is undsolvable before Inrupt change their client so removing them is the best bet. See more detailed summary at
SolidOS/solidos#73 (comment).