@@ -24,6 +24,127 @@ For more information about this process read [this](../../../miscellaneous/authe
## Sign in
Obviously, on the sign in page the user can enter its credentials in order to authenticate himself/herself. For more details refer to [this](../../../miscellaneous/authentication&authorization.md) section of the documentation.
A checkbox on the left of the password input allow one to display the content of the input.
## 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.
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.
Here's a diagram that sums this up.
```plantuml
!define BLACK #333745
!define RED #d5232a
!define GREEN #37A77C
' Base Setting
skinparam BackgroundColor transparent
skinparam Sequence {
ArrowThickness 1
ArrowColor RED
LifeLineBorderColor GREEN
ParticipantBorderThickness 1
}
skinparam Participant {
BackgroundColor #FFFFFF
BorderColor BLACK
FontColor BLACK
}
skinparam note {
BackgroundColor #FFFFFF
BorderColor BLACK
FontColor BLACK
}
participant "Front" as front
participant "Authentication Service" as auth
participant "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django
participant "Email Service" as email
participant "Kong" as kong
participant "OIDC Server" as oidc
group Password forgotten
front -> middle : <b>POST</b> /passwordForgotten
note over middle: Set token in Redis with ttl 24h.
middle -> email : <b>POST</b> /email/send (body contains the link to the reset password form)
middle <-- email : void
front <-- middle : void
end
group Verify Password reset token validity
front -> middle : <b>GET</b> /isPasswordResetTokenValid
The sign out button is available in the dropdown menu that can be displayed with a click on the user button of the header of the app.
Cookies are used to store the two authentication pieces and more particularily `HTTP only` cookie to store the JWT. It means the application cannot manipulate this cookie, the only way is to force it's expiration through our backend service. This is why the application makes a call to the [authentication service](../../services/authentication.md) which returns two new cookie with the same keys but with outdated expiration dates. Those cookies will replace the two existing ones in the user's browser, and as they are expired they will be removed and user signed out.
```plantuml
!define BLACK #333745
!define RED #d5232a
!define GREEN #37A77C
' Base Setting
skinparam BackgroundColor transparent
skinparam Sequence {
ArrowThickness 1
ArrowColor RED
LifeLineBorderColor GREEN
ParticipantBorderThickness 1
}
skinparam Participant {
BackgroundColor #FFFFFF
BorderColor BLACK
FontColor BLACK
}
skinparam note {
BackgroundColor #FFFFFF
BorderColor BLACK
FontColor BLACK
}
participant "Front" as front
participant "Authentication Service" as auth
group Logout
front -> auth : <b>GET</b> /logout
front <-- auth : [200] + cookies with outdated expiration dates
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 and set two cookies to replace the older ones.
When the user receives the "account validation" email, he/she/it is invited to click the link. This will open the web application that will get the Uuid4 token from the url and call a validate account endpoint of the middleware.
When the user receives the "account validation" email, he/she is invited to click the link. This will open the web application that will get the Uuid4 token from the url and call a validate account endpoint of the middleware.
If the token is still in Redis, then the middleware can process with the account creation calling the legacy Auth service.