Clean up intercepted login

[Brian Lewis]

The intercepted login occurs when the client has a bearer token and submits it with an API request, but the token is rejected. (generally, expired)

The modal login gets a new token and carries on with the interrupted operation.

Things to do:

1) If the intercepted login fails (e.g. user mistypes password) system navigates back to signin anyway - this should be suppressed.

2) Default the login name to the currently stored login name - ie you have logged in, your token is expired, you get to login in again just be supplying password.

3) If the new login uses a different user name, we should invalidate the templateCache. That way, the server may decide to deliver templates that are configured according to "claims" owned by the current user. e.g. filter dialogs may offer different options.

[Ghislain Hachey]

Was this work done?

[Ghislain Hachey]

Issue #390 was marked as a duplicate of this issue.

[Ghislain Hachey]

Issue #212 was marked as a duplicate of this issue.

[Ghislain Hachey]

Moving #212 and #390 here as it is all related.

• The popup dialog is launched by an interceptor when a 401 error is returned - this typically means the bearer token has timed out. By launching through an interceptor in this way, the original request can be resubmitted, this time with valid credentials.
• This dialog needs to be restyled.
• Also it seems this does not resume the task that was interrupted any longer; it just returns to the home page.
• 401 errors are intercepted , login dialog is displayed, and then request is resubmitted. this does not happen on Saves through the Editable pattern.

[Ghislain Hachey]

@Brian Lewis is everything in this ticket working as envisaged now?

[Ghislain Hachey]

This is done as per @Brian Lewis comment