1. What is the issue? Please be detailed.
We have an web application with users.
On ODK central we would like to create App user and Web users for some of our application users
For this we are using the REST endpoints to create App user and are able to generate the QR code and this works well.
We are creating WEB users as well.
We would like to use REST API's to directly login as a WEB user. But we are not able to manage the user store and sessions on the client side of the central application
2. What steps can we take to reproduce this issue?
API for creating WEB users
/v1/users (similar to the rest enpoint docs)
API for Creating the App user
/v1/projects/projectId/app-users
API for Login as WEB user
/v1/sessions
3. What have you tried to fix the issue?
We have looked at the client code base and its central state management as well all as the vuejs routing to understand the login/session management workflow.
But we dont want to tweak the client codebase
Is there anyway we can achieve some mechanism of single-sign-on where user registered on our application can be directly taken to the ODK central home page
4. Upload any test forms or screenshots below.
Below are the filepaths on the client application that was used to understand the sign-on workflow
Hi @Vishnu_Prasath! The login flow in the Central frontend relies on the cookie returned by POST /v1/sessions. When the user first visits the frontend, the Vue router will generally redirect them to the login page unless it is able to use the cookie to identify an existing login. However, the API docs recommend not relying on that cookie. We don't consider the cookie part of the stable API, so any aspect of it may change. Currently, the cookie is "domain-locked" because its name includes the __Host- prefix.
If you're reading code in the frontend, note that src/util/session.js contains relevant code. Note though that we don't make guarantees about the behavior of the frontend. Developers should consider the API the stable interface.
There's been some recent discussion about SSO here. We haven't had any new updates since then, but please feel free to continue checking in about our plans related to SSO.
@Matthew_White , Thanks for the inputs. So if the cookie is not a part of the stable API, is there any stable way to do this? We were also thinking of using the client code, front end itself to do the login somehow behind the scenes with some delays. And if that will change, it could be an issue.
The cookie and the frontend aren't part of Central's stable API, but you could try using them as long as it is acceptable to your project's level of risk tolerance knowing that those things may change. You would need to check with each Central release that nothing has changed about the cookie or the parts of the frontend that intersect with the flow that you're designing. For a more stable solution, I think your best bet is to continue to follow discussions on the forum related to SSO.
Thank you @Matthew_White for your respinses. We will choose the stable option for now. We will use the APIs to create webuser and app user acounts and generate the QR Code for the app user. But the login and session management will be done by the Central client code. It is a pain for the webuser to login again into the Central. But that will be fine for now.
And we will follow the thread on SSO fir a stable solution in the future.