Auth middleware and server functions

Ephem commented 1 year ago

[x] Review the documentation: https://clerk.com/docs
[x] Search for existing issues: https://github.com/clerkinc/javascript/issues
[x] Go through package changelog files.
[x] Provide the Frontend API key from your application dashboard.

Package + Version

[x] @clerk/nextjs 4.19.0

Dependencies + versions

Relevant ones:

"dependencies": {
    "@clerk/nextjs": "4.19.0",
    "next": "13.4.4",
    "react": "18.2.0",
    "react-dom": "18.2.0",
}

Browser/OS

N/A

Description

I'm not quite sure if this fits best as a bug or a feature request, but since following the current docs in this case does present as a bug I'll file it as such.

Reproduction:

Add the auth-middleware to a Next-app using the app-router
Set experimental: { serverActions: true } in next.config.js
Add a server function to a file (use server at top) and call it from a client component (can pass it down as a prop from a server component or import directly, refer to the Next.js-docs)
Call the server function with an expired session cookie (like the case mentioned in background fetching in your docs)

The auth middleware will return a 401 with the interstitial, but Next is expecting a RSC payload. There is also a Next.js bug that currently causes this to fail silently so the server function simply returns undefined in these cases, making it impossible to catch and retry.

(This might also be the case for regular RSC calls, that are not server functions, but I have not run into that since when the page is focused the token is revalidating automatically, but there's probably edge cases.)

Since it's not possible to set headers for server function calls, following the guide in cross origin requests does not work. You could pass the token as a parameter to the server function, but that would mean you would have to pass it around to every single nested server function you want to call on the server if doing validation in multiple places.

The workaround I ended up with was doing await getToken() (without actually using the returned token) before calling the server function, which from my reading of the Clerk src currently guarantees the session cookie will have been written with a non-expired cookie(?).

So as you can see there's a few different things going on, and I think it makes sense to tackle this more as a "figure out the auth-story with server functions" than a single specific bug (and I totally get that this is all still alpha/early days!), but I thought I'd file what I've run into and my findings so far in case it's helpful. 😄

clerk-cookie commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

Ephem commented 1 year ago

I am no longer working on the project that had this issue, but it is not stale. This is the only time I will comment to keep it open.

jescalan commented 1 year ago

Closing as a duplicate of https://github.com/clerkinc/javascript/issues/1537 - we are looking into this and will get it addressed as soon as possible though!

clerk-cookie commented 1 month ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

clerk / javascript