The sample custom integration example does not seem to be practically useful

[andersr]

I am currently looking at adding a custom auth integration and reviewing the example provided in the docs.

In this example, it appears that the assumption is I would call db.cloud.login({ email: "[email protected]" ) which then would result in a call from dexie cloud to the endpoint I have added in fetchTokens in cloud.config.

However, with that model, the server has to basically respond immediately with a token, which does not allow for completion of an actual login flow. (Eg an OTP roundtrip.)

It seems that the way this should work is that, once I have completed my custom login, I can do a POST to Dexie cloud "/login" endpoint that effectively is the equivalent of db.cloud.login({ email: "[email protected]" ) but which is coming from a server. Without that I am not clear as to how the current custom auth model is practically useful.

Any clarifications would be appreciated!

[dfahlander]

The fetchTokens is an async callback and can start any flow required for the authentication before returning its promise. However, an authentication flow can often involve redirections of entire page. Custom authentication will require you to control the backend that serves your frontend. So there are some options:

1. Let the backend handle authentication prior to serving the application. In this scenario, you will have an authenticated user at the time the application is loaded.

2. Let the application load regardless of whether user is authenticated with your authentication provider or not and let the flow of authentication start with your fetchTokens callback interacting with your server, to 1) fetch a local path on your server that can verify whether user is authenticated or not, and take actions such as responding with some JSON content that code that makes your callback either prompt for authentication in custom dialogs, or redirect the page to a login page and eventually arrive here again once the flow is done.

Both these scenarios are quite similar, just that the second one is prepared for non-authenticated users and take actions to initialize authentication flow.