Skip to content

fix: resolve User is not unauthenticated error seen on logout #10349

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

Merged
merged 3 commits into from
Oct 19, 2023

Conversation

Kira-Pilot
Copy link
Member

@Kira-Pilot Kira-Pilot commented Oct 19, 2023

Resolves the below error seen when logging out which was flagged in Slack:
image

I believe this issue stemmed from 0f2d4fd, which we could revert in its entirety no seems broken before, although I'm not sure why were were caching the response from /api/v2/users/me in the first place. For now, I've just ensured we always have fresh data when retrieving that endpoint. It appears we only call the me() handler in our AuthProvider anyway.

site/index.html Outdated
@@ -17,7 +17,6 @@
<meta property="og:type" content="website" />
<meta property="csrf-token" content="{{ .CSRF.Token }}" />
<meta property="build-info" content="{{ .BuildInfo }}" />
<meta property="user" content="{{ .User }}" />
Copy link
Member Author

Choose a reason for hiding this comment

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

Can I get a gut check here that this is safe to take out?? Seems fine but I am not very familiar with these tags and I don't want to break anything.

Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't be taken out! It makes the page load faster. See:

coder/site/site.go

Lines 302 to 307 in 21f8731

// Cookies are sent when requesting HTML, so we can get the user
// and pre-populate the state for the frontend to reduce requests.
// We use a noop response writer because we don't want to write
// anything to the response and break the HTML, an error means we
// simply don't pre-populate the state.
noopRW := noopResponseWriter{}

Copy link
Member Author

Choose a reason for hiding this comment

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

@kylecarbs @BrunoQuaresma Gotcha! So if I understand correctly, we return some API responses when the user requests index.html. This is achieved via these meta tags.

I see this pattern some places in the app:
getMetadataAsJSON<Entitlements>("entitlements") ?? API.getEntitlements()

And I'm confused because 1) wouldn't we always want fresh entitlement data? and 2) don't we already load entitlement data again in our DashboardProvider which wraps all authenticated routes?

Copy link
Member

Choose a reason for hiding this comment

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

Whenever the user loads index.html (e.g. you navigate to dev.coder.com), that would provide fresh entitlement data. It's similar to making the request from the FE, we just do it on page load.

The DashboardProvider re-fetching it would be a bug in that case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, but given this pattern:
async () => getMetadataAsJSON<User>("user") ?? API.getAuthenticatedUser(),
if a user doesn't refresh the page between login and logout, I think we'll see this bug because the user request is never rehydrated, right


return API.getAuthenticatedUser();
},
} satisfies UseQueryOptions<User>;
Copy link
Collaborator

@BrunoQuaresma BrunoQuaresma Oct 19, 2023

Choose a reason for hiding this comment

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

Hm... @Parkreiner @Kira-Pilot maybe we should do something different like:

 return {
    queryKey: meKey,
    initialData: initialMe,
    queryFn: API.getAuthenticatedUser,
 }

Because if the initialData is undefined the query will be loaded anyways.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah...This works perfectly. I double-checked the React Query type definitions, and somehow missed that initialData had an extra undefined type tagged on to its allowable values, and that it wouldn't affect the type parameters at all. I also double-checked the documentation, and found a section on this use case

I'm going to make another PR simplifying all the other functions that work like this

Copy link
Collaborator

@BrunoQuaresma BrunoQuaresma left a comment

Choose a reason for hiding this comment

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

If that works, that is great!

},
} satisfies UseQueryOptions<User>;
queryKey: ["me"],
initialData: getMetadataAsJSON<User>("user"),
Copy link
Member

Choose a reason for hiding this comment

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

My concern with this approach is that getMetadataAsJSON will get recalculated every single render, even though the value is basically a constant embedded in the HTML

This should be safe to extract outside the function

@Kira-Pilot Kira-Pilot merged commit 9c9319f into main Oct 19, 2023
@Kira-Pilot Kira-Pilot deleted the logout-error-fix/kira-pilot branch October 19, 2023 18:50
@github-actions github-actions bot locked and limited conversation to collaborators Oct 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants