From 283861fee4327682c95629a00e8efa29417d4cff Mon Sep 17 00:00:00 2001 From: "Yann Esposito (Yogsototh)" Date: Fri, 1 Apr 2022 17:39:23 +0200 Subject: [PATCH] notes/cisco_ft_securex_registration.org --- notes/cisco_ft_securex_registration.org | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/notes/cisco_ft_securex_registration.org b/notes/cisco_ft_securex_registration.org index 1f3dd681..32920b70 100644 --- a/notes/cisco_ft_securex_registration.org +++ b/notes/cisco_ft_securex_registration.org @@ -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.