Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

Add email auth #4539

Closed
wants to merge 16 commits into from
Closed

Conversation

rohitpaulk
Copy link
Contributor

@rohitpaulk rohitpaulk commented Jul 8, 2017

#1052.

This PR allows users to sign-in or create an account on Gratipay using email.

Screenshots

Email HTML

screen shot 2017-07-13 at 4 15 51 pm

Email text

screen shot 2017-07-13 at 4 03 42 pm

Signup flow (GIF)

gif

(http://recordit.co/ZJwXHLYiHF)

Signin flow (GIF)

(http://recordit.co/SX6hYCQI7j)

Non-critical items to reticket

  • Add cron to clean out old email_auth_nonces
  • When we show 'link expired' upon verification, we only say 'Generate a new one'. Provide a button inline instead (or open the sign-in modal with the error message)

Todo

@rohitpaulk rohitpaulk force-pushed the add-email-sign-in branch 7 times, most recently from 9be01a3 to 8ba8127 Compare July 11, 2017 05:38
@rohitpaulk rohitpaulk changed the title Add email sign in (WIP) Add email sign in - part 2 (WIP) Jul 11, 2017
@rohitpaulk rohitpaulk changed the base branch from master to add-email-sign-in-1 July 11, 2017 05:49
@rohitpaulk rohitpaulk mentioned this pull request Jul 11, 2017
1 task
@rohitpaulk rohitpaulk changed the title Add email sign in - part 2 (WIP) Add email sign in - Part 2 (WIP) Jul 11, 2017
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in branch 2 times, most recently from b435633 to f82f314 Compare July 11, 2017 11:14
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in-1 branch 2 times, most recently from 062cc52 to b2d6fe1 Compare July 13, 2017 09:36
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in branch 3 times, most recently from 26bad64 to 06056fa Compare July 13, 2017 09:54
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in-1 branch from b2d6fe1 to b317926 Compare July 13, 2017 09:55
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in-1 branch from b317926 to d4a22db Compare July 13, 2017 09:59
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in-1 branch from d4a22db to 6713c9a Compare July 13, 2017 10:16
@rohitpaulk rohitpaulk changed the base branch from add-email-sign-in-1 to master July 14, 2017 14:40
@rohitpaulk rohitpaulk force-pushed the add-email-sign-in branch 4 times, most recently from 28d9225 to c0d2aca Compare July 15, 2017 12:21
@chadwhitacre
Copy link
Contributor

Re: feature flags:

https://martinfowler.com/articles/feature-toggles.html
https://martinfowler.com/bliki/FeatureToggle.html

Many caveats and best practices in there, e.g.:

Savvy teams view the Feature Toggles in their codebase as inventory which comes with a carrying cost and seek to keep that inventory as low as possible. In order to keep the number of feature toggles manageable a team must be proactive in removing feature toggles that are no longer needed. Some teams have a rule of always adding a toggle removal task onto the team's backlog whenever a Release Toggle is first introduced. Other teams put "expiration dates" on their toggles. Some go as far as creating "time bombs" which will fail a test (or even refuse to start an application!) if a toggle is still around after its expiration date. We can also apply a Lean approach to reducing inventory, placing a limit on the number of toggles a system is allowed to have at any one time. Once that limit is reached if someone wants to add a new toggle they will first need to do the work to remove an existing toggle.

In the interest of standardizing URLs. Current count is 60 - vs. 6 _.
@chadwhitacre
Copy link
Contributor

I see so many similarities between email and accounts elsewhere. We talked about this before (should dig up): why don't we expand the accounts elsewhere machinery to encompass emails?

def with_email_and_username(cls, email, username):
"""Return a new participant with given email and username
"""
username = username and username.strip()
Copy link
Contributor

@chadwhitacre chadwhitacre Jul 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just username = username.strip()?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why not push that down into _validate?

@@ -81,6 +81,28 @@ def with_random_username(cls):
return cls.from_username(username)

@classmethod
def with_email_and_username(cls, email, username):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to see this use the existing username.safely_reserve infrastructure for consistency and code reduction.

@@ -46,7 +46,7 @@
text-align: center;
display: none;
background: transparentize($light-brown, 0.3);
z-index: 1000;
z-index: 900;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this is for a reason, ya?

This was referenced Jul 18, 2017
@mattbk
Copy link
Contributor

mattbk commented Jul 18, 2017

Running into issues on my Macbook, but still running fine on the Ubuntu VM.

@chadwhitacre
Copy link
Contributor

Rebased, was 114f36c.

@chadwhitacre chadwhitacre force-pushed the queue-email-without-participant branch from b80f821 to 4bc67bc Compare August 14, 2017 16:05
@chadwhitacre chadwhitacre force-pushed the queue-email-without-participant branch 7 times, most recently from 89a3ed3 to 13a8cc9 Compare September 1, 2017 19:19
@chadwhitacre
Copy link
Contributor

Coming back here from #4604 ... I am thinking about taking the stub participant approach discussed at ... somewhere? We already have plumbing for routes and exchanges and email addresses, seems wrong to duplicate those to enable anon to make payments. Better to stub out a participant, send a normal email verification, and then populate the return page with a "Confirm Payment" section similar to how we could do package claims on the receiver side.

@chadwhitacre
Copy link
Contributor

I am thinking about taking the stub participant approach discussed at ... somewhere?

#4547 (comment)

@rohitpaulk
Copy link
Contributor Author

Closing as stale

@rohitpaulk rohitpaulk closed this Nov 10, 2017
@chadwhitacre chadwhitacre deleted the add-email-sign-in branch November 10, 2017 14:18
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants