Email verification - implementation issues

[Łukasz Lewczyński]

Hi all,

Currently, I am working on the OLMIS-4833 which is about adding the email verification mechanism to the OpenLMIS system. According to the ticket when a user updates his email address, the user should still retrieve notifications to the old email address until the new email will be verified (by clicking the link in the email that was send by the system).

Currently, the email field is only in the reference data user resource and the email verification mechanism is in the auth service. In other words currently the auth service does not know anything about user email but because of the ticket it has to know if the user changed his email address.

I am not sure how exactly implement this in our system. I thought about few solutions:

1. move email field from the reference data service to the auth service

In this solution the auth service and the mechanism have all needed information. Problem is that now if user details will be changed we would need to send two requests to the both services.

Other problem is that currently all services use only the reference data user resource and they do not know anything about the auth user resource. So we would probably need add additional call to the auth service when a service will try to send a notification to the user.

2. block possibility to edit email field by a request to the reference data service

In this case we still need to send two requests to the both services but the request to the reference data service will not contain email field (it would be also impossible to change the value of the field). Those details would be in the request to the auth service. The email field in the reference data user resource would be updated by the auth service when a user will click the link in the verification email.

Example of the happy path:

1. user modify the email
   
2. the reference data does not know anything about the change
   
3. the auth service knows about the change and send verification email
   
4. user clicks the verification link
   
5. the auth service updates the email field in the reference data user resource 

3. move mechanism to the reference data service

In this case we move email verification mechanism to the reference data service. All needed details are in one service. I am only not sure if the reference data service should have any advanced business logic. From what I see now it only contains data that are used by other services.

4. merge user requests to one and send it to the auth service

This is something I have been thinking about for some time. Currently when a user is created we need to send two requests. I think we could merge them and send a single one to the auth service and it would be responsible to send correct data to the reference data service. In this case from the UI perspective we have a single request to the backend. We would only need to disable some endpoints from the reference data for the users so they need to use endpoint in the auth service. Also in this case it should be easy to check if email address has been changed.

Example of the happy path:

1. the auth service gets a user creation/update request
2. verification of auth data
3. send reference data to the correct service and wait for response
4. save auth data to the database
5. return response

From my perspective the 4th option is the best. It requires some additioanl efforts - both on backend and UI - but in my opinion it is the most clean solution. Also I think we solve some issues (that we don't see now) because we will have a single request and all will be done in single transaction.

The 3rd option looks also good but like I said I am not sure if this mechanism should be in this service.

In 1st and 2nd options we need to remember that some user details are updated by one endpoint and other details are updated by another endpoint and I think is incorrect behavior.

Any thought?

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[Chongsun Ahn]

Hey Łukasz,

Thanks for this detailed write-up; it helps to frame the conversation.

If I am thinking about this task (updating a user’s email address) from a client (UI) perspective, I would simply think about updating a user’s information. I don’t really care what is triggered with that update, like an email being sent to verify the email address I updated. Therefore I agree with you that the first two options don’t seem correct, as they require the client to know that in certain conditions (updating an email address), two requests need to be made. I also agree that it doesn’t make much sense to do such logic in the Reference Data Service, since its main responsibility is to provide data to other services.

What makes the most sense to me is a variant of the fourth option, where the Reference Data Service gets the request, then passes off any email verification to Auth. Once Auth gets a valid verification request, it can let Reference Data know that the email address is verified. So the happy path would be:

• Reference Data: get a user create/update request
• Reference Data: notice email address updated, send message to Auth for email verification
• Auth: get request, send an email to new email address
• (some time later) Auth: get a verify email request
• Auth: validate, send message to Reference Data to flag email address as verified
• Reference Data: email address now verified
• Auth: clean up

This option is basically like option 4, except that Reference Data has most of the User info, rather than Auth. I haven’t thought through why that might be better than just doing option 4, except for the fact that we already have most User data in Reference Data already. It might be a significant refactor to move it to Auth and there may be some issues that come up that we cannot foresee.

One thing to note is that both the old and new email addresses would need to be stored until verified, but that would probably be true for any option.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

[Łukasz Lewczyński]

Hi Chongsun,

Your option looks good but when I added API keys I tried to create a connection between reference data and auth service - in other words the reference data service would know that there is the auth service - I remember that we decided to change the approach because we would like to avoid situations where the reference data service communicates with any service. In the 4th option the request is sent to the auth service but some part of the data would be transfer to the reference data. We would still have two user resources in two services. From the UI perspective we would only need to do one call - now we have to do two calls.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

On Fri, Jun 8, 2018 at 8:45 PM, Chongsun Ahn <chongs...@villagereach.org> wrote:

Hey Łukasz,

Thanks for this detailed write-up; it helps to frame the conversation.

If I am thinking about this task (updating a user’s email address) from a client (UI) perspective, I would simply think about updating a user’s information. I don’t really care what is triggered with that update, like an email being sent to verify the email address I updated. Therefore I agree with you that the first two options don’t seem correct, as they require the client to know that in certain conditions (updating an email address), two requests need to be made. I also agree that it doesn’t make much sense to do such logic in the Reference Data Service, since its main responsibility is to provide data to other services.

What makes the most sense to me is a variant of the fourth option, where the Reference Data Service gets the request, then passes off any email verification to Auth. Once Auth gets a valid verification request, it can let Reference Data know that the email address is verified. So the happy path would be:

• Reference Data: get a user create/update request
• Reference Data: notice email address updated, send message to Auth for email verification
• Auth: get request, send an email to new email address
• (some time later) Auth: get a verify email request
• Auth: validate, send message to Reference Data to flag email address as verified
• Reference Data: email address now verified
• Auth: clean up

This option is basically like option 4, except that Reference Data has most of the User info, rather than Auth. I haven’t thought through why that might be better than just doing option 4, except for the fact that we already have most User data in Reference Data already. It might be a significant refactor to move it to Auth and there may be some issues that come up that we cannot foresee.

One thing to note is that both the old and new email addresses would need to be stored until verified, but that would probably be true for any option.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

[Chongsun Ahn]

Hey Łukasz,

For API keys, what was the reasoning to avoid situations where reference data would communicate with other services?

I’m not sure I understand why reference data would explicitly know there is an auth service. Yes, it would be communicating via HTTP to a REST API, but it wouldn’t know there is something call an “auth service”. It would just know that the email address has been updated, so it needs to go to a certain API to start an email verification.

For both options, the UI would only need to do one call, one to update a user. The only differences between the two options I see is:

• Which service calls the other to start email verification
• Which service contains most of the user information (including email address)

Let me know if I’m missing something.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

[Łukasz Lewczyński]

Hi Chongsun,

Thanks for replay. I only found a question in this review but quite possible that there was a small discussion on showcase about connection between reference data and auth services and why the reference data should not know about the auth service. I mean if the service should communicate with any other service in our eco system.

If you don't mind I will implement my version of the 4th option where UI calls endpoint from the auth service and it calls the endpoint from the reference data when user is created/updated.

Thanks,

Lukas

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

On Sat, Jun 9, 2018 at 12:00 AM, Chongsun Ahn <chongs...@villagereach.org> wrote:

Hey Łukasz,

For API keys, what was the reasoning to avoid situations where reference data would communicate with other services?

I’m not sure I understand why reference data would explicitly know there is an auth service. Yes, it would be communicating via HTTP to a REST API, but it wouldn’t know there is something call an “auth service”. It would just know that the email address has been updated, so it needs to go to a certain API to start an email verification.

For both options, the UI would only need to do one call, one to update a user. The only differences between the two options I see is:

• Which service calls the other to start email verification
• Which service contains most of the user information (including email address)

Let me know if I’m missing something.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog