Android: Blocking when an account is deleted in server side

[jesmrec]

Steps

1. In app, login in an account
2. In server, delete the account
3. In app, select the account in drawer or in account manager
4. Redirection to login view

The account does not exist anymore, so credentials will never work (username is non-editable). If you tap on "Go Back" button, the files view or settings view (depending whether the app has more accounts or not) is shown for a little while, but you are redirected again to login view. It is a bit annoying to switch to another account or tap on "new account".

Expected behaviour? Switch to another account, or to login view if the app has no accounts. The question is if server side answers in the same way if the credentials have changed and if the account is removed to detect these two different cases.

[jesmrec]

In the case of authentication (OAuth2 or whatever), if the user credentials are revoked, the side-effect is the same, making the app annoying to use. Not easy to reach the login view to add a new account.

[theScrabi]

So the idea was to redirect the user to the account select window instead of the login view. This way the user is still able to select another account or delete one if no other is there.

[jesmrec]

Some thoughts related:

• If the account was removed, the user is redirected to account select view in case that more accounts are attached. Then, if the user selects again the server-removed account, he should be redirected again to account select view in a loop, until he selects a different account or remove the account from the device.
• In case of having only one account attached in the device, the user will be redirected to login view instead of account select view.
• This behaviour will apply not only for the case of an account removal, but also all 401 cases? @theScrabi

agreed with this new behaviour? @michaelstingl @davigonz

[theScrabi]

So what we found out is that the app acts different on the deletion of basic outh and oauth2 accounts. On basic auth it only shew a snackbar of an error while on oauth the user got redirected to the login view.

For basic auth i made the app now have the same behaviour by replacing the call for the snackbar with a call for requestAuthentificationUpdate()

later on I will replace the methode for requestAuthentificationUpdate() with a methode for selecting other accounts. If no other account is available the user will be redirected to authentication update anyway.

[michaelstingl]

Great teamwork. Go for it!

[davigonz]

agreed with this new behaviour?

Yes but just an improvement I came up with about the next thought

If the account was removed, the user is redirected to account select view in case that more accounts are attached. Then, if the user selects again the server-removed account, he should be redirected again to account select view in a loop, until he selects a different account or remove the account from the device.

@michaelstingl @jesmrec @theScrabi What about deleting the account when the app detects that the server account was removed? I mean, instead of keep showing it in the account select view in a loop when the user selects the server-removed account, just delete it from the list if is not longer available in the server. IMHO, keep a loop for this doesn't make sense.

[jesmrec]

@theScrabi and me were discussing about that. Is there any way to detect a removed account in server-side?

[theScrabi]

@theScrabi and me were discussing about that. Is there any way to detect a removed account in server-side?

One method that works the same for basic auth and oauth

[jesmrec]

The case of SAML behaves in same way. SAML session expires itself and the expected behaviour is asking credentials again, so it should be redirected to login view.