Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sign in with publicKey #2034

Closed
wants to merge 8 commits into from

Conversation

friedger
Copy link

This PR

  • adds field publicKey to UserInputType
  • adds redirect to sign in requests if the user input comes with a publicKey value. The redirect value is the encrypted redirect link.

This is a proof of concept towards
opencollective/opencollective#1749

Corresponding UI looks like this:
opencollective/opencollective-frontend#1833

Probably it is not necessary to include blockstack.js as only function encryptContent is needed.

After sign in the user name contains the blockstack id of the user:
Screenshot from 2019-05-27 11-07-28

@znarf znarf self-requested a review May 28, 2019 09:13
@@ -27,6 +27,7 @@
"babel-plugin-add-module-exports": "1.0.2",
"babel-plugin-lodash": "3.3.4",
"bcrypt": "3.0.6",
"blockstack": "^19.1.0",
Copy link
Member

Choose a reason for hiding this comment

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

You said integrating this blockstack library might not be mandatory. What would be the alternative? If it's simple, then let's do that.

Copy link
Author

Choose a reason for hiding this comment

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

I had a look but it is a bit more complicated.

if (process.env.NODE_ENV !== 'production' && user.email.match(/.*test.*@opencollective.com$/)) {
if (
(process.env.NODE_ENV !== 'production' && user.email.match(/.*test.*@opencollective.com$/)) ||
user.publicKey
Copy link
Member

Choose a reason for hiding this comment

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

If there is no e2e tests, then let's not modify that.

@@ -34,19 +59,25 @@ export const exists = async (req, res) => {
export const signin = (req, res, next) => {
Copy link
Member

Choose a reason for hiding this comment

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

At this stage, can you have a specific signin endpoint for blockstack? And use a dedicated exists method?

To minimize footprint in server/controllers/users.js, supporting functions may be loaded from lib/blockstack.js

@@ -204,12 +206,25 @@ const mutations = {
throw new Error('User already exists for given email');
}

if (
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it's useful to do any modification in these GraphQL queries. The signin endpoint should be enough.

Copy link
Author

@friedger friedger May 28, 2019

Choose a reason for hiding this comment

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

This is for creating a new profile with blockstack. However, we can remove these, and limit the creation of new profiles with blockstack to personal profiles that are handled through signin, not createUser

Copy link
Member

Choose a reason for hiding this comment

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

Ok, sorry, I was a bit wrong. createUser was indeed used for signups.

But, please handle that in a separate endpoint (ie: blockstackSignin / blockstackSignup), or a separated GraphQL mutation (ie: createUserWithBlockstack).

Copy link
Author

Choose a reason for hiding this comment

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

I have re-added it and moved everything into separate methods.

Copy link
Member

@znarf znarf left a comment

Choose a reason for hiding this comment

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

Because this is an experimental feature at this point. Let's try to keep modifications to the existing codebase to the minimum, and make the feature easy to disable or to remove. Think of it as a plugin, not something hardcoded in the codebase.

Copy link
Member

@znarf znarf left a comment

Choose a reason for hiding this comment

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

Looks good on the API side.

@friedger
Copy link
Author

I have added the updateUserPublicKey mutation to better handle existing users

@znarf znarf temporarily deployed to opencollective-staging-api June 21, 2019 11:12 Inactive
@friedger
Copy link
Author

friedger commented Jul 4, 2019

Can I do more to get this one merged?

@znarf
Copy link
Member

znarf commented Jul 4, 2019

@friedger nothing on the API side, this is more on the frontend side that we had open questions. We need to have another look and test again all the different cases.

@znarf znarf added the stale label Nov 6, 2019
@znarf
Copy link
Member

znarf commented Mar 16, 2020

This was pretty good work and I'm sorry we let this PR go stale.

Unfortunately, after discussing it with the team last week, there was no consensus to move it forward and I'll have to close it.

This could be revisited once supporting multiple identity providers become a priority.

@znarf znarf closed this Mar 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants