Handle re-installation of 3rd party app about android-singlesignon HOT 15 CLOSED

so, this can be closed, or? :-)

from android-singlesignon.

• remove 3rd party app after everything worked & re-install it --> should ask again for authentication
• remove files app after everything worked & re-install it -> 3rd party also should again ask for authentication

from android-singlesignon.

First one works out of the box as we overwrite token on "grant access".

from android-singlesignon.

Second one returns "invalid token", which is in https://github.com/nextcloud/android/blob/c52f9c842f44b5c9e42b1125468fa03dd554d162/src/main/java/com/nextcloud/android/sso/Constants.java#L17

@stefan-niedermann @desperateCoder 3rd party apps should check for this and start their own re-authenticate process again.

Would that work for you?

from android-singlesignon.

We could do it like this, but should we? This is a case, future users of the SSO have to be aware of. Is it impossible for the SSO lib to handle this?

For me this shouldn't be a problem, but it's inconvenient tbh.

from android-singlesignon.

hm, I have no idea how to handle this via SSO:

• install files app & authenticate account
• install 3rd party app
• grant account to 3rd party
  • token is stored in files app (this is needed to verify app calls)
  • sso account is stored via shared preferences in 3rd party app
• remove files app --> no tokens are available
• re-install files app
• login into files app with account from above
• 3rd party app tries to access said account
  --> files app will refuse as there is no token in files app and throws error CE_1 (EXCEPTION_INVALID_TOKEN"

tl;dr: if files app is deleted, we do not know anything about already authenticated accounts/apps.

from android-singlesignon.

So how can you tell, when to throw the exception mentioned above? Isn't that exactly the case when we have to reauthentificate?

from android-singlesignon.

The exception is thrown by SSO/files.
I'll change this in above scenario.

from android-singlesignon.

So now I'm confused. File app says CE_1. SSO still knows selected account. Can't SSO catch CE_1 and try to reauthentificate/re-grant?

Sorry if I am talking nonsense, I don't have had a deep-dive into the whole process.

from android-singlesignon.

@desperateCoder I just build the latest master for the SNAPSHOT mechanism of jitpack to pick it up in case you build/compile the deck app: https://jitpack.io/com/github/nextcloud/Android-SingleSignOn/master-8b590d8028-1/build.log

from android-singlesignon.

@AndyScherzinger ok? afaik i currently use -SNAPSHOT as version for SSO, but i wonder if all problems are already solved? See above... 🤔

from android-singlesignon.

@desperateCoder not sure what has been fixed already...

from android-singlesignon.

Okay, just pushed some changes. If you want to handle reauthentication, you can use this snippet

// caught TokenMismatchException
try {
    SingleAccountHelper.reauthenticateCurrentAccount(this);
} catch (NextcloudFilesAppAccountNotFoundException | NoCurrentAccountSelectedException | NextcloudFilesAppNotSupportedException e) {
    UiExceptionManager.showDialogForException(this, e);
} catch (NextcloudFilesAppAccountPermissionNotGrantedException e) {
    // Unable to reauthenticate account just like that..
    // TODO Show login screen here
}

And you need this one in the activity, that you use to make the call above:

AccountImporter.onActivityResult(requestCode, resultCode, data, this, new AccountImporter.IAccountAccessGranted() {
    @Override
    public void accountAccessGranted(SingleSignOnAccount account) {
        Log.d(TAG, "accountAccessGranted() called with: account = [" + account + "]");
        mApi.initApi(new NextcloudAPI.ApiConnectedListener() {
            @Override
            public void onConnected() {
                Log.d(TAG, "onConnected() called");
            }

            @Override
            public void onError(Exception ex) {
                Log.e(TAG, "onError() called with:", ex);
            }
        });

    }
});

Example: https://github.com/nextcloud/news-android/blob/master/News-Android-App/src/main/java/de/luhmer/owncloudnewsreader/NewsReaderListActivity.java#L435

from android-singlesignon.

So now I'm confused. File app says CE_1.

File app says CE_1 because Files app is storing the token and after re-installation the token is gone.

SSO still knows selected account.

There is no "SSO". Just think of SSO as your app: SSO is storing infos about known account / token within your shared config of your app.
That is the reason why "SSO"/your app still knows the account/token, because it is not deleted.

Can't SSO catch CE_1 and try to reauthentificate/re-grant?

See above. SSO is part of your app and like the initial account setup you have to react on it. SSO never knows how you implemented your first login.
(with David's change it is hopefully now a bit more cleaner)

from android-singlesignon.

Ok, I see. It's ok as it is and as @David-Development proposed.

I see the difficulties but I'm sure, we could solve this with a strategy pattern if we wanted. Just by passing the behavior by implementing an interface.

Don't get me wrong, this is fine tuning, nice to have, I'm just pitching.

from android-singlesignon.