dappros / ethora

A 'super app' engine for your project. React Native (iOS, Android) and React.js (Web, desktop). Social Sign In 🄵, Messaging 💬 (chat, voice, push notifications), Web3 Wallet 🪪 (profile QR, documents, coins, NFT), DLT 🔐 (provenance, crypto signing), Gamification 🤩, Social Commerce and more.
https://ethora.com/
GNU Affero General Public License v3.0
426 stars 83 forks source link

API /users/ update (especially for DELETE) #557

Open phwizard opened 1 week ago

phwizard commented 1 week ago

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.

CleanShot 2024-09-10 at 12 12 09@2x

--

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/

phwizard commented 1 week ago

@transkarpation as discussed like you mentioned:

ще пригадав що ми відправляли листа на пошту коли юзер з 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.