@@ -12,13 +12,13 @@ First of all the user must go to the sign up page accessible from the login page
* contain at least one lowercased character
* contain at least one number
Passwords are always encrypted with a public key retrieved from the `legacy auth middleware` before they are sent accross the network. Only the legacy auth middleware knows the private key that allow the decryption of the password.
Passwords are always encrypted with a public key retrieved from the [legacy auth middleware](../../middlewares/legacy-auth.md) before they are sent accross the network. Only the legacy auth middleware knows the private key that allow the decryption of the password.
Before being able to submit the form, the user has to accept the general terms of use and the processing of its information.
When the form is submitted, the account is not directly created. In fact, a request is made to the [legacy auth middleware](../../middlewares/legacy-auth.md). The service stores temporarily the user account information in a Redis database and send an email to the user's email address through the [email service](../../services/mailer.md). The purpose of this email is to confirm the validity of the user's email address. Indeed the email contains a unique link which expires after 24h.
The link is actually a link to the login page of our application that includes a `token` query param. When the `LoginComponent` of the Angular app detects a `token` param in the url, it sends an HTTP request to the `Legacy auth middleware` including the token. If the token is still valid the user account associated with this token is created in the real user database of the [legacy auth service](../../core/legacy-auth.md).
The link is actually a link to the login page of our application that includes a `token` query param. When the `LoginComponent` of the Angular app detects a `token` param in the url, it sends an HTTP request to the [legacy auth middleware](../../middlewares/legacy-auth.md) including the token. If the token is still valid the user account associated with this token is created in the real user database of the [legacy auth service](../../core/legacy-auth.md).
For more information about this process read [this](../../../miscellaneous/authentication&authorization.md) section of the documentation.
...
...
@@ -30,9 +30,9 @@ A checkbox on the left of the password input allow one to display the content of
## Password forgotten
A user that forgets its password can click the `Password forgotten` button from the sign in page. The application will then display a second form asking the user to enter its email address. When the form is submitted, the password is encrypted with the public key retrieved from the legacy auth middleware. Then just as in the sign up process the app sends a request to the middleware that in its turn sends an email to the user address ,through the [mailer](../../services/mailer.md), containing a link valid for 24 hours.
A user that forgets its password can click the `Password forgotten` button from the sign in page. The application will then display a second form asking the user to enter its email address. When the form is submitted, the password is encrypted with the public key retrieved from the [legacy auth middleware](../../middlewares/legacy-auth.md). Then just as in the sign up process the app sends a request to the middleware that in its turn sends an email to the user address ,through the [mailer](../../services/mailer.md), containing a link valid for 24 hours.
The link sends the user on the page dedicated to the reset of the password. This page first verifies that a token is indeed present in the query param of the current url. It also checks with the legacy auth middleware if the token is still valid. In the failing case a message ask the user to restart the password reset process from the beginning. When the token is valid, the user is asked to enter a new password. Finally the application sends the request to the middleware along with the token from the query param. The middleware checks again the validity of the token and then make an HTTP call to the `Legacy auth` service in order to apply the new password to the email associated to the user account.
The link sends the user on the page dedicated to the reset of the password. This page first verifies that a token is indeed present in the query param of the current url. It also checks with the [legacy auth middleware](../../middlewares/legacy-auth.md) if the token is still valid. In the failing case a message ask the user to restart the password reset process from the beginning. When the token is valid, the user is asked to enter a new password. Finally the application sends the request to the middleware along with the token from the query param. The middleware checks again the validity of the token and then make an HTTP call to the `Legacy auth` service in order to apply the new password to the email associated to the user account.
Here's a diagram that sums this up.
...
...
@@ -141,7 +141,7 @@ end
## User update
A user can easily update its profil information from the user profil page. He needs to agree to the general term of use and the process of its information before sumitting any changes. To update the profil, the application calls the authentication service. In its turn it makes the appropriate request to the legacy auth middleware and then generate a new JWT with the latest user information. Finally the authentication service replies to the application with two cookies to replace the older ones.
A user can easily update its profil information from the user profil page. He needs to agree to the general term of use and the process of its information before sumitting any changes. To update the profil, the application calls the [authentication service](../../services/authentication.md). In its turn it makes the appropriate request to the [legacy auth middleware](../../middlewares/legacy-auth.md) and then generate a new JWT with the latest user information. Finally the [authentication service](../../services/authentication.md) replies to the application with two cookies to replace the older ones.
Here's in bit more details the different exchanges that take place during the update of the user's profil.
...
...
@@ -309,3 +309,29 @@ end
```
## User accesses
This page is composed of two tabs:
* one for the restricted access datasets that the user can access
* one for the restricted access datasets that the user can require access to
In both tab, a dataset's name is an internal link that redirects to the corresponding dataset detail page.
### Request access to a new dataset
Each dataset can have many different available services (WMS, WFS...). The user can request access to all the services for this particular dataset or chose to require access only to the services he/she is interested in.
<!-- TO BE COMPLETED -->
<!-- At first the user is granted a one month access. He/she will receive an email asking for more details about the use he/she will do of the services. -->
Once a service has been requested it will disapear from the available services list. Instead it will appear in the user accesses tab.
### User accesses management
A user access state can have three different values:
* Pending, the user request hasn't been accepted yet
* Ok, the user request has been accepted and the expiration date has been reached
* Expired, the expiration date has been reached
From this table, one can remove its access to a service but can also renew it if it has expired or if it is soon to be expired. The user and the dedicated team on our side will receive an email acknowledging the request. However, there is currently no way in the backend to change the state of the service to `renewal request pending` so there will be no change in the application until the request has been accepted.
