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
[NAN-578] Implement Google Social Login/Signup #1872
[NAN-578] Implement Google Social Login/Signup #1872
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in staging, works well 💪🏻
@@ -0,0 +1,82 @@ | |||
interface Props { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was the impression that /ui
folder was for Generic reusable component, this one is really a one of. (my pov is that everything is related to ui anyway so it's either an unnecessary hierarchy level or it's specific for one scenario)
@bodinsamuel Thanks for the review. I updated the PR based on some of your feedback. The other items I didn't see as blocking but let me know if you feel strongly about any items I didn't address and I can add more color on why I didn't adjust it based on your feedback. |
} | ||
|
||
const createAccountIfNotInvited = async (state: string, name: string): Promise<number | null> => { | ||
const parsedAccount = (state ? JSON.parse(Buffer.from(state, 'base64').toString('ascii')) : null) as InviteAccountState | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot JSON.parse throw an exception? What should happen in this case?
} | ||
|
||
return accountId; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this be?
const res: Result<InviteAccountState> = parseState(state) // returns a valid InviteAccountState or a ResultErr
if (isOk(res)) {
const validToken = await userService.getInvitedUserByToken(token);
if (validToken) {
await userService.markAcceptedInvite(parsedAccount.token);
}
return parsedAccount.accountId ;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, updated
if (!workos) { | ||
errorManager.errRes(res, 'workos_not_configured'); | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my comment above. This is not a concern for the user and I think it would be better to crash the server at startup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WorkOS is only required for Cloud so don't think it should crash here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what I mean is this is a configuration issue that would better detected as soon as possible (aka: when the app starts) rather than deferred to whenever a request is being received.
For sure for non-cloud setup this configuration can be ignored.
I prefer never to deployed a misconfigured app than getting a bug report by an end-user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I gotcha, but who are we protecting here? Developers running the application locally? Cloud will have the necessary env variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I gotcha, but who are we protecting here?
We protecting our future self
Cloud will have the necessary env variables.
They will, until one day the infra changes and configuration is somehow forgotten or messed up.
In general trying to detect error as soon as possible is a good principle to follow.
Not a blocker though.
? `${authorizedUser.firstName || ''} ${authorizedUser.lastName || ''}` | ||
: authorizedUser.email.split('@')[0]; | ||
|
||
const accountId = await createAccountIfNotInvited(state as string, name as string); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should state and name be validated prior to make sure they are acceptable string. That would also avoid having to cast them
@@ -260,6 +292,79 @@ class AuthController { | |||
next(error); | |||
} | |||
} | |||
|
|||
getHostedLogin(req: Request, res: Response, next: NextFunction) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what Hosted
referred to here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hosted = WorkOs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find our use of Hosted rather confusing, everything is hosted by default.
Is it enterprise, cloud or community? if hosted = enterprise + cloud
maybe we can come up with a naming more representative like "managed".
Plus we use hosted
for self-hosted in the Docker images right now, which is the opposite
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments 👌🏻
@@ -260,6 +292,79 @@ class AuthController { | |||
next(error); | |||
} | |||
} | |||
|
|||
getHostedLogin(req: Request, res: Response, next: NextFunction) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find our use of Hosted rather confusing, everything is hosted by default.
Is it enterprise, cloud or community? if hosted = enterprise + cloud
maybe we can come up with a naming more representative like "managed".
Plus we use hosted
for self-hosted in the Docker images right now, which is the opposite
If a user is suspended they're essentially locked out of Nango. Handling this seems out of scope of this as it is a known limitation of the invite flow. Let me know if you disagree |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have only one small feedback regarding configuration management but other than that looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments still opened but overall ✅
Tested one last time on staging, all good 👍🏻 |
Describe your changes
Adds in google auth using workos
Issue ticket number and link
NAN-578
Checklist before requesting a review (skip if just adding/editing APIs & templates)