🥔 `Space`: `Authentication`

zspencer commented 3 years ago

People sign in to a Space by providing an Email Address. Convene confirms they are actually the person with access to that Email Address by sending an email with a link and one-time code that they provide back to us.

Unauthenticated people are Visitors, while Authenticated people are either Guests, Neighbors, or Residents.

Visitors: Unauthenticated People.
Guests: Authenticated People without a Membership in any Space in the Neighborhood.
Neighbors: Authenticated People with a Membership in any (other) Space in the Neigbhorhood.
Residents: Authenticated People with a Membership in the current Space.

In the future, we intend to explore more authentication methods (like, Apple Sign In/web sign in/etc); but not just yet.

Design Assets

From @colombene - Wireframes for authentication flow

Use Cases

[x] 🥔 Signing In by Magic Link
[x] 🥔 https://github.com/zinc-collective/convene/issues/159
[x] 🥔 Sign Out Manually
[x] 🥔 Sign Out from Inactivity

1.1

[ ] 🌫️ Sign in via SMS

Bugs

[x] https://github.com/zinc-collective/convene/issues/1809

user512 commented 3 years ago

Is this feature needed now member can click on the link to identify themselves? This seems to be a useful feature for identify thru phone number instead.

  Scenario: Identification via entering a Code that is Emailed
    Given I have submitted my email in the sign in form
    When I enter the code emailed to me 
    Then I am identified within the Space for a week

Now that we have https://github.com/zinc-collective/convene/pull/150 merged in, I think we just have to implement the avatar on nav bar and expose the logout link to fulfill the Removing my identity from a device scenario.

zspencer commented 3 years ago

@user512 - I would be comfortable deferring the entering of the code to a different Milestone, if you like. However; I think it's an important Scenario to support; as someone may be logging in on a computer that does not have their email address; such as a shared library computer.

user512 commented 3 years ago

I see, I was previously confused by if one do not have email access, how can they enter the code from the email the app sent without realizing people can look at their mobile device.

zspencer commented 3 years ago

@user512 - I have pulled that Scenario into https://github.com/zinc-collective/convene/issues/159 so that we don't have to worry about it just yet.

zspencer commented 3 years ago

While doing some smoke testing in production, I noticed that when I signed in from meet.zinc.coop, it took me to convene.zinc.coop. This resulted in me not being signed in at meet.zinc.coop because the cookies are not shared between domains.

We probably want to respect the custom domain and sign people in on a space-by-space basis when they are custom domains.

anaulin commented 3 years ago

Quick notes from my looking into handling the log-into-branded-domain scenario better: We can override how the magic link email gets sent, and at that point we have access to the original hostname, based on which we can generate the magic sign-in URL. It would look something like:

# config/initializers/passwordless.rb
Passwordless.after_session_save = lambda do |session, request|
  SignInMailer.magic_link(session, request).deliver_now
end

and:

# app/mailers/magic_link_mailer.rb
def magic_link(session, request)
  host = request.host
  token = session.token
  #[... rest of email implementation here ...]
end

zspencer commented 3 years ago

Would that mean we're writing our own mailer or would we monkey-patch the Passwordless one? Either sounds reasonable. Very exciting!

anaulin commented 3 years ago

@zspencer I wrote our own, because it seems easier to follow to me that way, and hopefully less brittle: https://github.com/zinc-collective/convene/pull/223

zspencer commented 2 years ago

Now that Sign in via email is working, and written about I think it's safe for us to close this out!

zinc-collective / convene