SOLID POD: Login page should always respect the SOLID server URL provided by user

[cdawei]

Currently, the Login page makes use of the SOLID server URL provided by user if not logged in. However, if a webId has logged into the app, the Login page ignores the provided server URL.

For example, suppose a webId associated with server SERVER_A has previously logged into the app, thus the app caches the login details. Now a user restart the app and provides SERVER_B on the Login page, and click the login button, the app then directly logs into the app using the cached login details. However, it seems more appropriate to redirect the user to the login page of SERVER_B in this case.

[tonypioneer]

When the user clicks the Login button, the app will first log out of the currently signed-in Pod, clear the cache, and then prompt the user to log in again. If there is no existing login cache, the Continue button will be disabled and greyed out; if a login cache exists, the user can click the Continue button to sign in to the previously used server and account.

[gjwgit]

Just a few clarifications as I think this changes the use cases.

• If a login is cached and the solid server is the same as previously, will I still automatically go straight in?
• If the login is cached and the solid server is now different, will it first log out and thengo to the login page?
• If there is no login cache should the CONTINUE button be greyed out? I might be able to use the app without logging in? How do I handle that scenario now?

Seems like the new paradigm is

• If I tap LOGIN I always expect to login new?
• If I tap CONTINUE then I will use the previous login.

I'm not sure the new paradigm works for apps that don't require a login, necessarily?

Perhaps the workflow should be

• If I tap LOGIN and there is a cached login with the same server as specified then I use that and go into the app
• If I tap LOGIN and there is a cached login with a different server to that specified then I have a new login through the browser
• What about the case of a different USER? Let's not deal with that for now. Possible future feature. For now the workaround is to assume the previous user has logged out if they care about that and are sharing the device.
• If I tap LOGIN and there is no cached server then login through the browser is initiated
• If I tap CONTINUE and there is a login cached then that will be used
• If I tap CONTINUE and there is no login cached I continue to use the app without a login until possibly the app notices it needs a login and then prompts at that time.

[srodriguez142857]

To add a bit more for this conversation, many websites have the following design:

1. They request the user to actively "Stayed signed in (not recommended for shared devices)", if the user wants to.
2. They request the user to "Try another account" to sign in using a different ID:

A couple of observations:

• As mentioned in our meeting, the "Continue" button is useful for the apps' features that do not require interaction with a POD.
• Either issuing a new login or logging in with a cached, authenticated ID, the user must always know the flow and what action the app will perform (the UI should be simple and intuitive).

[tonypioneer]

To add a bit more for this conversation, many websites have the following design:

1. They request the user to actively "_Stayed signed in (not recommended for shared devices)_", if the user wants to. 2. They request the user to "_Try another account_" to sign in using a different ID: A couple of observations:

• As mentioned in our meeting, the "Continue" button is useful for the apps' features that do not require interaction with a POD.
• Either issuing a new login or logging in with a cached, authenticated ID, the user must always know the flow and what action the app will perform (the UI should be simple and intuitive).

Thanks @srodriguez142857 for the suggestion. We can discuss it in tomorrow's meeting.

[tonypioneer]

Just a few clarifications as I think this changes the use cases.

• If a login is cached and the solid server is the same as previously, will I still automatically go straight in?[ ] If the login is cached and the solid server is now different, will it first log out and thengo to the login page?[ ] If there is no login cache should the CONTINUE button be greyed out? I might be able to use the app without logging in? How do I handle that scenario now?

Seems like the new paradigm is

• If I tap LOGIN I always expect to login new?
• If I tap CONTINUE then I will use the previous login.

I'm not sure the new paradigm works for apps that don't require a login, necessarily?

Perhaps the workflow should be

• If I tap LOGIN and there is a cached login with the same server as specified then I use that and go into the app[x] If I tap LOGIN and there is a cached login with a different server to that specified then I have a new login through the browser[x] What about the case of a different USER? Let's not deal with that for now. Possible future feature. For now the workaround is to assume the previous user has logged out if they care about that and are sharing the device.[x] If I tap LOGIN and there is no cached server then login through the browser is initiated[x] If I tap CONTINUE and there is a login cached then that will be used[x] If I tap CONTINUE and there is no login cached I continue to use the app without a login until possibly the app notices it needs a login and then prompts at that time.

All the items in the workflow above have been implemented.

[gjwgit]

@tonypioneer could you create a new issue for the suggestion from Sergio. Thanks.