Make the initial login flow more robust. about juju-dashboard HOT 6 CLOSED

This is happening because it's trying to send a login request after the websocket connection has been terminated. I'm assuming this happens after you've let it sit for a while without logging in?

I need to add the Pinger facade to keep this connection open until the user clicks to log in. Once logged in we request the model list often so we probably don't need it there, but it can't hurt to also add the Pinger to the controller once logged in.

from juju-dashboard.

This is in the small tasks epic for this iteration, does it mean you are planning to work on this for this iteration? If that's the case we need to assign also the milestone, and move the card to the current column.

from juju-dashboard.

This is actually a combination of three issues:

1. As previously mentioned, the websocket connection to the controller will terminate after one minute of inactivity making it impossible to send the actual login message.

2. When the connection to the controller is made it returns a url which we then make a long polling HTTPS request to. This connection will return a 'logged in' value once the user visits the supplied 'visit url'. If this url is not visited within ~50s then it will also be terminated by the remote end. While we can retry this connection when it's closed, the token will eventually expire and then even if the user clicks to log in the request will fail.

3. Once a connection is made to the controller we need to perform some activity on it every minute or it will be closed down by Juju as inactive.

In order to robustly solve this issue we need to address all three problems:

1. Remedied by using https://www.npmjs.com/package/reconnecting-websocket in place of the built in websocket implementation. This package implements the same w3c api so it's a drop in replacement.

2. This will require an architecture/approach change to handling the login mechanism. We want to immediately connect to the controller on application load and attempt to log in to provide a good user experience. But upon failure we cannot simply retry forever and hope the user doesn't just walk away from their browser for days. This is also bad for power/bandwidth consumption on mobile devices. If we're unable to immediately log in using a stored macaroon we may want to disconnect from the controller and not make the polling request to the 'wait url' until the user interacts with a separate login button.

   • The redirect login flow should be available in a couple months so before investing heavily in making this login more resilient lets revisit this in a couple months to see the status on the auth updates permitting a redirect login flow.

3. We'll use the Pinger facade to keep the connection open. This facade was explicitly designed for this issue when developing the old GUI.

from juju-dashboard.

@hatched how are we planning this? You broke this epic down in the comment, should probably be issue attached here? CC @cristinadresch

from juju-dashboard.

Is this still relevant or did we include in the Vancouver POC epic? @hatched @hatched @cristinadresch

from juju-dashboard.

The root cause of this issue still exists. This is not part of the POC.

from juju-dashboard.