This is the core part of the Account SDK, which simplifies accessing and using Schibsted account. The core SDK has two responsibilities: Controlling login flows for users and providing easy to use network calls. This provides the login engine, which is used by our UIs and can optionally be used to do custom implementation
Please note that using the APIs alone is neither recommended or supported by the Account team. If you choose not to use the controllers, you do so at your own peril. The APIs will not be covered in this readme, but you can have look at the service package, which provides Retrofit2 calls for the Schibsted account APIs.
There currently available flows are:
To initialize the login flows you need to implement the corresponding contract, PasswordlessContract, LoginContract or SignUpContract. These contain all the required steps which might be requested by the engine, to which a user must provide additional input. The callbacks themselves receive tasks as parameters, on which you can do different actions, like provide additional fields, accept user agreements etc.
Once you have implemented the contracts, you should initialize the controller you want to use, i.e. PasswordlessController or LoginController. To start the login routine, call the start(...) function and the controller will try to perform as many tasks as possible automatically and will prompt the contract if it needs additional input.
Any errors which occurs when executing a task will will be propagated to the callbacks provided to those actions.
When the login flow is completed, the onLoginCompleted function will be called with your User object, which also contains the session.
After a successful login, you get a User object. The user object is responsible for performing actions on the user, like updating profile data. It also has a reference to its session, from which you can request one time login codes or logout the current session. After logging out a session, you should not perform any actions on either the session or the user.
The SDK provides the AccountService which includes the UserPersistenceService. This automates persisting and refreshing the stored user on token updates etc as well as logouts. To use this, you should bind this anywhere where your user is active.
Example
public class MyActivity extends AppCompatActivity {
private AccountService accountService;
@Override
protected void onCreate(Bundle savedInstanceState) {
accountService = new AccountService(getApplicationContext());
getLifecycle().addObserver(accountService)
}
// If you for some reason don't have the most recent support library, you can call these manually instead
// @Override
// protected void onStart() {
// accountService.bind();
// }
// @Override
// protected void onStop() {
// accountService.unbind();
// }
}
You can manage user sessions by using the static functions of the User class. Normal use cases are usually limited to resuming sessions, but it’s also possible to remove previous sessions or clear all sessions. Please note that if your intention is to log out the user, you should call user.logout(...).
Example
User user = User.resumeSession(context, myUserId, new new ResultCallback<User>() { ... })
User user = User.resumeLastSession(context, new new ResultCallback<User>() { ... })
To logout a user, you call the logout(...) function on the User object. This will invalidate the user session and AccountService will pick this up and remove the session from persistence.
If you need to respond to events when a user logs in etc, you can register a BroadcastReceiver to the LocalBroadcastManager to get the event. The event actions are available in the Events class
You can authenticate your requests by binding a session to an OkHttpClient from the User object. As long as the user is logged in, this will allow authenticated requests and keep your session alive. To bind a session, please see the User.bind(OkHttpClient.Builder, List<String>) function for details.
The second parameter specifies which hosts you will use the authenticated requests for. For security reasons you should not attach session information to requests that does not need to be authenticated, as this would allow third parties to hijack a session from a user.
By navigating (for example by using Custom Tabs) to the URL for Schibsted account web login those flows can be used to log a user in. This can also be used to pick up an already logged in user session in the browser and get a logged in user in the native app.
Example
String redirectScheme = ctx.getString(R.string.schacc_conf_redirect_scheme);
String redirectHost = ctx.getString(R.string.schacc_conf_redirect_host);
Boolean persistUser = true;
URI redirectUri = URI.create(redirectScheme + redirectHost);
CustomTabsIntent.Builder builder = new CustomTabsIntent.Builder();
CustomTabsIntent customTabsIntent = builder.build();
customTabsIntent.launchUrl(ctx, Uri.parse(Routes.loginUrl(ctx, redirectUri, persistUser).toString()));
What is the difference between one time code and one time session url?
The two serves different purposes, the one time code is used to give an auth code which can be used to get a token on behalf of the user. This can be passed to your back-end if you need to perform actions on the user. The one time session url is normally used to authenticate a web view. Pass this to a web view with a redirect of your choice and you will end up having the user authenticated in that web view.