Description
It lets you determine whether a logged-in user has enough data defined in a section. It comprises 2 parts:
- Check if data need to be completed.
- If they need to be completed, show the user an appropriate interface.
This flow is handled using 2 calls to 2 methods.
Step 1: Check if data need to be completed
To check if a user needs to complete the data for a specific section, a call has to be made to the DRUID API with the following data:
Endpoint URL:
GET https://{your-endpoint-domain.com}/user/api
Request parameters
| Parameter | Description | Type |
| w.section | The entry point about which you want to ask. | string |
| f | For this case, this parameter must be set to UserMeta | string |
| s | For this case, this parameter must be set to needsToCompleteData | string |
| oauth_token | access_token of the logged user | string |
Request example
Response
| Attribute | Description |
| userBelongsTypology | User belongs to scope typology |
| needsToCompleteOptionalData | User does not have some optional field filled, so you can redirect user to complete_account to allow fill it |
| needsToConfirmIds | User have pending id confirmation (eg: email, mobile..) so you can redirect user to complete_account to allow confirm it |
| needsToCompleteData | User does not have some mandatory field filled, so you can redirect user to complete_account to allow fill it |
| needsToAcceptConsents | The user has some non mandatory consent to false, so you can eventually redirect user to the data completion to allow you to set it to true if he/she wish. |
| needsToAcceptTerms | User must accept some t&c . After login. The user will be required to accept them if he/she wants to continue. |
Step 2: Redirect to complete account
If some data need to be completed, the user has to be asked to complete them.
The authorization sequence is started by redirecting the browser (all of the page) to a DRUID URL with a set of configuration parameters that tell the server what type of access to the DRUID resource servers your application requires. As in other scenarios, DRUID takes care of user authentication, creating the shared session in all domains and consent to access to the data requested by your application.
In this particular case, the user must be authenticated on the server or a logged-in user access token must be provided.
Endpoint URL:
GET https://{your-endpoint-domain.com}/oauth2/authorize
| Parameter | Description | Type |
| client_id | identifies the app | string |
| redirect_uri | URL to which the OAuth server will redirect the user’s browser after completing the authentication process by the users. These URLs have to be registered in the cockpit panel. | string |
| response_type | The value must be set to none. | string |
| x_method | Possible values could be ‘complete_account”, to redirect user to desired flow. | string |
| state | Allows you to restore the previous state of your application. The state parameter preserves some state objects set by the client in the Authorization request and makes it available to the client in the response (eg: session identifier, json info base64 encoded…). The content must be url urlencoded. | string |
| scope | Scope is a mechanism in OAuth 2.0 to limit an application’s access to a user’s account. In the case of DruID, you must send the id of the entrypoint you want to use for the desired flow. | string |
Response
The server checks that the input parameters are correct, and if found to be logged in, redirects the user to the next step. If the user is not logged in, the user is redirected to the login screen.
When the user completes the actions on the displayed screen, the OAuth server responds to the browser control to the app via GET to the URL it received in the redirect_uri parameter.
Error codes
The possible errors in this step are:
- invalid_request
- invalid_client
- unauthorized_client
- redirect_uri_mismatch
- unsupported_response_type
- invalid_scope