Improve Login Flow

[discorick]

Good enough:

• Change the copy of the "Sign in" button to an icon button with the octocat and "Sign in with GitHub" - @discorick
• /login Simplify the two step process with just [Sign in with GitHub] - @discorick
• /login Add (Green icon) Your email to the permissions asked for - @discorick
• "Sign in with github button" Change it's default behavior to "public" scope + email - @discorick
• Force a re-auth for all new "login" clicks
• Move public vs private to separate OAuth applications - @rauhryan
• Store credentials in couchdb (must be encrypted)
• Change copy on pricing page to say we store tokens with XYZ encryption and never look at your data without your expressed permission
• Ensure that email that is collected is making it into intercom [Discorick/issues controller #1 criteria for acceptance]
• Sense public auth only on the dashboard and provide an upgrade option - @discorick

Better:

• Skip /login all together and default to "Email scope"
• [DASHBOARD] If we only have the "email" scope, the landing page should be a "Welcome" here's how you get started similar to what [/login] does today.
• [DASHBOARD] If we know they only have Public access, have an option to upgrade to private ("Not seeing your private repositories? [Upgrade access] [?]"

[rauhryan]

@discorick if you need further inspiration or ideas, refer to https://libraries.io for general UX ideas

[drusellers]

Store credentials in couchdb (must be encrypted)

Ohhh!!! 👍

[drusellers]

I'd love to review the encryption approarch

[rauhryan]

keep an eye out for the PR ;)

[dahlbyk]

[Sign in with github button] Change it's default behavior to "public" scope + email

Note that explicitly requesting public scope will actively remove permissions for private scope. You had mentioned having multiple applications for OAuth, does that come into play here? Or is there a way with Warden to just make sure we have at least read:org (and user:email?) to pass through to the repo list?

Force a re-auth for all new "login" clicks

I don't understand what you mean by this. What is expected behavior if someone is already logged in?

Store credentials in couchdb (must be encrypted)

What does this gain us?

[rauhryan]

You had mentioned having multiple applications for OAuth, does that come into play here?

Yes, that is critical! Forgot to add that

[edit]
added another task to the checklist above

[rauhryan]

I don't understand what you mean by this. What is expected behavior if someone is already logged in?

Translation: strangle hold the problem, if a user is already logged in, continue to let them use the application unaffected until with have completed a shippable version of the "better" path

If a user is NOT logged in, force the new path, if they ARE logged in, wait til they get logged out

[rauhryan]

What does this gain us?

Gains us a ton of value

• We can default anonymous login's to the email scope
• then we have who they are
• we pull that document out of couch to see what level of credentials they allowed
• thus giving the user a smoother "login" experience.

Later...

We get the ability to change the state of the system from GitHub webhooks using the "actors" token

This is a MAJOR prerequisite to HuFlow

[dahlbyk]

move public and private access into separate OAuth applications

So we end up with three apps?

1. HuBoard app with read:org,user:email for initial login to see dashboard and read-only boards
2. HuBoard Public app with public_repo to make public repo boards read/write
3. HuBoard Private app with repo to make private repo boards read/write

Or with two apps we would presumably combine 2 into 1?

Assuming we want to keep the existing HuBoard app as the "main" one, I'm wondering what the ideal UX is to get through the "now we need email" transition. If we ask for read:org,user:email without logging out will it leave the existing public_repo/repo permissions intact or at that point will a second authorization be required?

---

Store credentials in couchdb (must be encrypted)

What does this gain us?

Gains us a ton of value

This feels like a large enough engineering effort (doing this right is a Big Deal™) that it's worth breaking out separate from an initial effort to get email addresses into Intercom. What are the incremental steps we can take to achieve the short-term goal (contact info) in alignment with this future vision?