notes/cisco_ft_securex_registration.org
This commit is contained in:
parent
77f78096fb
commit
283861fee4
1 changed files with 3 additions and 3 deletions
|
@ -287,7 +287,7 @@ Note we should test that the user created that way could login correctly.
|
|||
|
||||
If possible (if we do not have any dependency cycle issue), it would be
|
||||
nice to put this new route under ~/iroh/iroh-auth~ (so ~IROHAuthWebService~)
|
||||
because this web service already support access to non login users.
|
||||
because this web service already supports access to non-logged-in users.
|
||||
|
||||
So have a new ~GET~ endpoint; ideally:
|
||||
|
||||
|
@ -304,7 +304,7 @@ Where ~ENCRYPTED_DATA~ should contain the following:
|
|||
|
||||
and
|
||||
|
||||
- ~role~ ; optional and only if accepted, if none provided, default to ~user~
|
||||
- ~role~; optional and only if accepted, if none provided, default to ~user~
|
||||
|
||||
The separation of the ~role~ query parameter is important in order to give a
|
||||
chance for the UI to change the associated role before user creation.
|
||||
|
@ -317,7 +317,7 @@ If someone hit this endpoint, then you should:
|
|||
2. Check the ~org-access-request~ id and secret matches a pending org access request.
|
||||
If not, return the corresponding error message.
|
||||
3. check that ~approver-id~ is a ~user-id~ of an admin of the ~org~ of the ~org-access-request~.
|
||||
4. If everything is fine, perform a patch that could potentially create the new user.
|
||||
4. If everything is fine, perform a patch that could potentially create a new user.
|
||||
|
||||
In order to make this work, you should probably have some work to do in the
|
||||
email creation.
|
||||
|
|
Loading…
Reference in a new issue