HI, 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. > +1, I also think no need re send the code if user can retry the scenarios. > > > > >> 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? >> >> >> >> 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). >> >> In this scenarios how do we going to identify the incident and who will going to revoke the conformation code. > >> - >> >> > +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 >> >> >> >> Thanks > Isura. > >> Appreciate your ideas and comments on this. >> > This is open ended feature. shall we break down the tasks, So it whould be easy for you to start. -Ishara > >> [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/ > > > > -- Ishara Karunarathna Technical Lead WSO2 Inc. - lean . enterprise . middleware | wso2.com email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
