Newer
Older
# User management
## Sign up
There are two steps to create an account on data.grandlyon.com.
First of all the user must go to the sign up page accessible from the login page and fill the form. A few information are required such as the firstname, the lastname and the email. A password also has to be entered. It must:
* have at least 6 characters
* contain at least one special character
* contain at least one uppercased character
* 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](../../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](../../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.
## 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](../../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](../../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.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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
note over middle: Look for token in Redis.
front <-- middle : boolean
end
group Password reset
front -> middle : <b>GET</b> /publicKey
front <-- middle : { publicKey }
front -> middle : <b>PUT</b> /user/resetPassword
note over middle: Look for token in Redis.
middle -> django : <b>POST</b> /update_user_password/
middle <-- django
note over middle: Delete token from Redis.
front <-- auth : void
end
```
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
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](../../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.
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
Here's in bit more details the different exchanges that take place during the update of the user's profil.
```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 "Kong" as kong
group User update
front -> auth : <b>PUT</b> /user/update
auth -> middle : <b>PUT</b> /user/update
middle -> django : <b>POST</b> /update_user/
middle <-- django : Ok
middle -> django : <b>POST</b> /get_user/
middle <-- django : { userInfo }
auth <-- middle : { userInfo with encrypted password as authzKey}
auth -> kong : <b>PUT</b> /consumers/:email
auth <-- kong : Ok
auth -> kong : <b>GET or POST</b> /consumers/:email/jwt (POST if no creadetials exist for this user)
auth <-- kong : { credentials }
front <-- auth : { token: jwt }
end
```
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
From its profile page a user can access to the password update tab. He/she can change its password by filling the dedicated inputs. However the current password must be reentered.
The password update is done through a call to the [legacy auth middleware](../../middlewares/legacy-auth.md). If the request is successful the app will trigger a new login with the new credentials that will be transparent for the user. Doing so, the user wont be logged out on the next authenticated HTTP call (as the password would be outdated) and wont need to reconnect manualy while he/she just entered in the latter form.
```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
group Get Public Key
front -> middle : <b>GET</b> /publicKey
front <-- middle : { publicKey }
end
group Password update
front -> middle : <b>PUT</b> /user/updatePassword
middle -> django : <b>GET</b> /get_user/
middle <-- django : Ok
middle -> django : <b>PUT</b> /update_user_password/
middle <-- django : Ok
front <-- middle : void
end
group Legacy login
front -> auth : <b>POST</b> /login/legacy
auth -> middle : <b>POST</b> /user/login
middle -> django : <b>POST</b> /get_user/
middle <-- django : { userInfo }
middle --> auth : { userInfo with encrypted password as authzKey}
auth -> kong : <b>PUT</b> /consumers/:email
auth <-- kong : Ok
auth -> kong : <b>GET or POST</b> /consumers/:email/jwt (POST if no creadetials exist for this user)
auth <-- kong : { credentials }
front <-- auth : { token: jwt }
end
```
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
From its profile page, one can also delete its account. A modal is asking for a confirmation in order to prevent that an unwanted click deletes the user account without any possible rollback.
This diagrams shows the different exchanges made.
```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 "Middleware Legacy Auth" as middle
participant "Legacy Auth (Neogeo)" as django
group User account deletion
front -> middle : <b>DELETE</b> /user
middle -> django : <b>POST</b> /delete_user/
middle <-- django : Ok
front <-- middle : void
end
```
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
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.