You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please verify the current implementation and implement new features or update if needed so that:
3rd party developers can use this 'externalID' (also can be called UUID) parameter when doing a DELETE operation of the User. Please do the same for UPDATE as well. Maybe other operations too such as retrieve a list or search users, if you think necessary.
This will support the following scenario in a convenient way for 3rd party developers. So that they can use IDs for Users from their existing system and they don't have to create another database to memorize Ethora ID's for all Users.
UPD:
also proposed to add bypassEmailConfirmation flag for POST method.
If specified, then User will be considered verified and confirmation e-mail will not be sent. This is for use case N3 where we trust external system has already verified their users.
ще пригадав що ми відправляли листа на пошту коли юзер з email реєструється, тоді для цих юзерів що створюються іншими серверами ми email не будемо відправляти? якщо небудемо то вони і зайти в веб портал не зможуть
my proposed solution to this is add an optional parameter to POST method:
bypassEmailConfirmation
if specified, then User will be considered verified and confirmation e-mail will not be sent. This is for use case N3 where we trust external system has already verified their users.
In our API we already have externalID parameter.
Please verify the current implementation and implement new features or update if needed so that:
3rd party developers can use this 'externalID' (also can be called UUID) parameter when doing a DELETE operation of the User. Please do the same for UPDATE as well. Maybe other operations too such as retrieve a list or search users, if you think necessary.
This will support the following scenario in a convenient way for 3rd party developers. So that they can use IDs for Users from their existing system and they don't have to create another database to memorize Ethora ID's for all Users.
UPD:
also proposed to add bypassEmailConfirmation flag for POST method.
If specified, then User will be considered verified and confirmation e-mail will not be sent. This is for use case N3 where we trust external system has already verified their users.
--
More details in forum here: https://forum.ethora.com/topic/22-integrating-ethora-chat-component-users-system-with-your-existing-legacy-system/
This is to support Use Case N3 as described here: https://forum.ethora.com/topic/21-chat-component-use-cases-for-users-authentication/
The text was updated successfully, but these errors were encountered: