Hi, On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby <joh...@wso2.com> wrote:
> 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 :). > AFAIU, you have mentioned about providing UI support for resending confirmation emails? I think we should consider the UI validations in account recovery endpoint, when a previously issued confirmation link is used, as I have mentioned previously (ex: when someone use a previously issued confirmation link for reset password, user should redirect to an error page, without redirect to the password reset page). WDYT? > > 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". > Yes. Planning to cover only the necessary scenarios from the above list. > > 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? > I think it's not needed to resend emails with just text notifications. Or you are considering implementation of a generic API for notification sending in recovery scenarios rather than API for notification resending? > >> >> >> >> >>> 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? > My concern was, when we resending a confirmation email for self registration, in the back-end REST API, we need to validate whether the account have been activated or not? Or we can provide a UI validation as currently in the login page (Re-Send button to resend the confirmation link will be appeared in the login page, if only account is not activated)? > > >> >>> >>> >>> 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/Resen >>> dCodeApiServiceImpl.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>* > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
