Hi Indunil/Isura, I have a general comment on this. Are we not planning to support this in the UI at least in the public release? Because planning for backend only IMO is not a good idea from previous experience because it will remain at the same state for years. Don't want to go back there. And from a capabilities POV it won't be considered as OOTB capabilities of the product, which makes it hard to sell :).
On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne <is...@wso2.com> wrote: > Hi Indunil, > > > > On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake < > indu...@wso2.com> wrote: > >> Hi, >> >> With IS 5.3.0, we have currently provided a Rest API for resending >> confirmation code (Refer [1]), which supports only for self signup feature. >> So that, we are planning to provide a more generic REST API and a OSGi >> service, for resending confirmation code for any scenario. >> >> >> >> Following are the scenarios, currently where we are sending confirmation >> emails in IS. >> >> - *Password Reset* - password recovery using email-based notifications >> - *Account Confirmation* - email confirmation on user self >> registration >> - *Ask Password* - ask password from user through confirmation email >> - *Admin Forced Password Reset*- admin to trigger a password reset >> for a given user account >> - *Admin Forced Password Reset With OTP* - admin send an email to >> the user with a one time password that the user can use to login once to >> the account after which, the user will be prompted to set a new password >> - *Email Confirmation *- account confirmation through email >> notification >> >> > IMO it is not required to have an option to resend the confirmation codes > for following scenarios. > > > - Password Reset > - Admin Force Password Reset > - Admin Force Password Reset with OTP > > There is no intermediate step between sending confirmation and validating > confirmation in mentioned scenarios. So, instead of resending the code, > users can start a new flow again. (Ex. Try another attempt to reset > password ) > BTW, it is good to have a generic API to resend the confirmation codes. > Yes. Please carefully consider the scenarios where "resending" is absolutely necessary. Wherever we can "restart" the process we don't need to "resend". We can have two types of emails as far as I understand; emails with confirmation codes for verification and emails with just text for notification. Please consider these two kind of mails also when designing. Are we planning to support "resend" for emails for just notifications? E.g. user account disable? > > > > >> In there, the confirmation emails get expired after a configured time >> period in order to make the accounts secure. After the expiration, we may >> need to resend the confirmation emails. >> >> So with this implementation, when we request for resending confirmation >> code, previously issued code (even though, it's still not expired), should >> get expired and the new confirmation code should considered as active. So >> that in any scenario, if a user is requesting to use an expired >> confirmation code, we need to redirect the user, to an error page >> mentioning of using an expired confirmation link. >> >> In case of user self registration, if request has made for resending >> confirmation link, after a account activation, I think it should be handled >> in the self registration API (currently Re-Send button to resend the >> confirmation link will be appeared in the login page, when we try to login >> to an unverified account). We may not need to consider it, when resending >> the confirmation code. WDYT? >> > I am not sure I understood the differences in the scenarios you are explaining well. Can you explain in a different way? > >> >> >> Other than that, I think we can consider following scenarios as further >> improvements. WDYT? >> >> - In case of a forgery, we may need to expire the confirmation link, >> manually before the configured time (without resending the confirmation >> link). >> >> > +1. Please create a improvement Jira to track this. > >> >> - >> - Currently for resending confirmation email for user self >> registration, we have provided support in the login page where user can >> request to resend confirmation link (We have not added this to the >> documentation, created a doc jira in [2]). In order to resend the >> confirmation emails from admin (or user with a required permissions), we >> can provide support in management console to : >> - select the user(s) to whom need to resend the activation email >> - select a role, to send confirmation emails to a group of users - >> here we may need to automatically skip over users who have already >> activated there accounts in case of self registration >> >> +1 to consider resending to a group of users if we feel it's useful. Can we introduce a new role that contains all the users to whom emails have been sent and confirmation pending? And may be another role to contain all the users who have confirmed? Otherwise there is no way to easily retrieve the list of users who are pending confirmation or already confirmed. *@Maduranga* implemented a similar use case for a customer recently. Please discuss with him and see how he did it. Thanks & Regards, Johann. >> - >> >> >> >> Thanks > Isura. > >> Appreciate your ideas and comments on this. >> >> [1] https://github.com/wso2-extensions/identity-governance/blob/ >> master/components/org.wso2.carbon.identity.user.endpoint/ >> src/main/java/org/wso2/carbon/identity/user/endpoint/impl/Re >> sendCodeApiServiceImpl.java >> [2] https://wso2.org/jira/browse/DOCUMENTATION-7189 >> >> Thanks and Regards >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > > *Isura Dilhara Karunaratne* > Associate Technical Lead | WSO2 > Email: is...@wso2.com > Mob : +94 772 254 810 <+94%2077%20225%204810> > Blog : http://isurad.blogspot.com/ > > > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
