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 : http://github.com/solid/node-solid-server/blob/main/index.html
• the root/index.html page for pod's created before NSS 5.1.7 http://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?)