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

[Issue #2653] Sign in component #3281

Open
wants to merge 19 commits into
base: feature/nextjs-auth
Choose a base branch
from

Conversation

acouch
Copy link
Collaborator

@acouch acouch commented Dec 18, 2024

Summary

Fixes #2653

Time to review: 5 mins

Changes proposed

Mobile

Figma

image

Local

image

Deskstop

Figma

image

Local

image

@@ -44,6 +44,11 @@ locals {
manage_method = "manual"
secret_store_name = "/${var.app_name}/${var.environment}/api-auth-token"
},
# URL for the API login route.
AUTH_LOGIN_URL = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This isn't secret so it goes next to the NODE_OPTIONS key above

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is the same as the API_URL right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@coilysiren Secrets knows how to read from SSM where as the standard env vars are more "constants?" Right? Or is there a way to read from SSM there too?

Copy link
Collaborator

@doug-s-nava doug-s-nava left a comment

Choose a reason for hiding this comment

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

can we confirm that the sign in button should get the same hover indicator as the nav items? seems slightly weird to me to have two items showing the same indicator at the same time:
Screenshot 2024-12-18 at 11 59 14 AM

frontend/src/components/Header.tsx Outdated Show resolved Hide resolved
frontend/.env.production Outdated Show resolved Hide resolved
const LoginLink = () => {
return (
<Link
href={process.env.auth_login_url as string}
Copy link
Collaborator

Choose a reason for hiding this comment

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

this works with next dev where the variable is defined in the env file, but won't work with build && start when it's coming from SSM. The env var won't be available to the app until run time, and for a client component to pick up directly from process.env the variable needs to be:

  • prefixed with NEXT_PUBLIC and
  • available at build time

I'd recommend reading this in from process.env in the environments file, then prop drilling it down to the header component from the nearest server component. It may work to import directly from the environments file, but I doubt it.

Copy link
Collaborator

@mdragon mdragon Dec 19, 2024

Choose a reason for hiding this comment

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

I wish local Next/React did a better job of highlighting/blocking this anti-pattern.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@doug-s-nava b/c these pages are statically rendered, there isn't a server side place to put the env for the static pages, unless we use wrap them in a suspense boundary. @mdragon that isn't an anti-pattern, it is the rec from next documentation

That could be the way to go. As of this comment, the CDN is rendering the suspense on the search page without a loading state, meaning the header could potentially use suspense without a "flicker."

If we switch to dynamic rendering, then we could just use this pattern as is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Noting we resolved this, decided to use a route handler for the public client side envars for the time being then will remove that once we can use dynamic routing.

frontend/next.config.js Outdated Show resolved Hide resolved
frontend/tests/components/Header.test.tsx Outdated Show resolved Hide resolved
frontend/src/components/Header.tsx Outdated Show resolved Hide resolved
frontend/src/components/Header.tsx Outdated Show resolved Hide resolved
@doug-s-nava
Copy link
Collaborator

Also if we're not updating the button to a logged in state when user is logged in in this change I think we need a ticket to handle that

@acouch acouch force-pushed the acouch/issue-2653-login-component branch from 5b3b8af to a28c443 Compare December 19, 2024 13:46
@acouch
Copy link
Collaborator Author

acouch commented Dec 20, 2024

Also if we're not updating the button to a logged in state when user is logged in in this change I think we need a ticket to handle that

@doug-s-nava this seemed like enough to chew on for a PR and the provider wasn't available when I started. I can do a follow-up for the same ticket now that the user provider is available.

doug-s-nava and others added 8 commits January 2, 2025 16:21
* adds route at /api/auth/callback to be hit by the flask API at the completion of the login flow
* adds jwt token parsing logic
* adds support for a "SESSION_SECRET" env var
* adds a User page for temporary testing
@acouch acouch force-pushed the acouch/issue-2653-login-component branch from a28c443 to 0179346 Compare January 2, 2025 21:21

return (
<a
{...passHref}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the easiest way I could think of to disable the login button while it fetches.

Copy link
Collaborator

Choose a reason for hiding this comment

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

And just to make sure I'm keeping all the different tickets straight, Doug has a separate ticket to hide this button behind a feature flag?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes

Copy link
Collaborator

Choose a reason for hiding this comment

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

what about moving the fetch and state management into this component, and implementing a loading state (which in this case would just hide the link, I guess?)

return Response.json({
api_url: environment.API_URL,
auth_login_url: environment.AUTH_LOGIN_URL,
node_env: environment.NODE_ENV,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't see this being consumed anywhere yet, but per the discussion on the other ticket, should this use the new ENVIRONMENT since NODE_ENV is just prod everywhere except localhost?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The NODE_ENV is different than the env we set per environment. I could remove this as it isn't being used.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I removed it

Copy link
Collaborator

@doug-s-nava doug-s-nava left a comment

Choose a reason for hiding this comment

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

a couple of nits

SENDY_API_URL=
SENDY_LIST_ID=

API_URL=http://api.simpler.grants.gov
Copy link
Collaborator

Choose a reason for hiding this comment

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

🎉

export const dynamic = "force-dynamic";

export function GET() {
return Response.json({
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I misinterpreted the conversation yesterday - I thought that this route would be redirecting the request to the correct API endpoint, rather than returning the url. I know this is temporary so it's probably not a big deal, but that would save us a round trip, and then we can avoid the state management on the client. Does that raise the level complexity too much?

Copy link
Collaborator Author

@acouch acouch Jan 3, 2025

Choose a reason for hiding this comment

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

I'd like to keep the same pattern of getting the envar itself and pass to the component which is what we'll be moving to. The redirect also adds additional complexity for the UX, going back to get provide a proper error page etc. This seems like the easiest temporary solution.

/>
</div>
<div className="usa-nav__primary margin-top-0 margin-bottom-1 desktop:margin-bottom-5px text-no-wrap desktop:order-last margin-left-auto">
<div className="usa-nav__primary-item border-0">
<LoginLink auth_login_url={authLoginUrl} />
Copy link
Collaborator

Choose a reason for hiding this comment

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

can we commit to camelCase?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Updated, thanks.


return (
<a
{...passHref}
Copy link
Collaborator

Choose a reason for hiding this comment

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

what about moving the fetch and state management into this component, and implementing a loading state (which in this case would just hide the link, I guess?)

@acouch
Copy link
Collaborator Author

acouch commented Jan 3, 2025

what about moving the fetch and state management into this component

@doug-s-nava want to avoid a loading state for every page request. this way the user just gets the link, and it isn't available if there is some server issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants