Should rootAuthLoader support the loadUser option?

[tmcw]

I recently integrated Clerk into my application, which also uses a relational database, so it needed to use Clerk's externalId setting to cross-reference. So, I then used rootAuthLoader with Remix, and the loadUser option to get the user object, to get the externalId.

This worked in development but is a hazard for production: Clerk's rate limit is 5 reqs/second, so once any website goes above that, you start randomly showing users logged-out states and throwing errors.

The eventual solution - helpfully shown by Clerk's support, which has been great - is to store the necessary data in the user session to limit database access. However, I think it's probably a good idea to guard against other users falling into this trap: 5 reqs / second is a very surprisingly low rate limit, and it very much makes it so that you shouldn't ever require a request to clerk for each pageload.

• [x] Review the documentation: https://clerk.com/docs
• [x] Go through package changelog files.

[dimkl]

Hello @tmcw, thank you for making this comment. We have an internal ticket to tackle some issues with the options passed in our middlewares/ loaders / ... across all of our supported SDKs. It seems that there are some inconsistencies based on framework limitations and other reasons. I leave this issue open and reply when we have finalized our decisions and our API designs to provide a better answer to this.

[tmcw]

Thanks. Trying to dodge the rate limit is really our main struggle with Clerk right now. I totally understand why it'd be a good idea to rate-limit login attempts, but for a method like getting a user object or a jwt token, such a brutal rate limit means that we're needing to add caches and workarounds that we didn't anticipate having to build.

[perkinsjr]

Spoke to tmcw regarding the rate limiting so we should be good on that front.

[clerk-cookie]

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.

[tmcw]

Unless I'm missing something, I still think this issue is valid: if you use rootAuthLoader with the loadUser option, your site will break quickly because of the rate limit. We switched to not using loadUser and trying to rely on the session object, but if loadUser is a footgun, it should probably be documented as such or removed.

[dimkl]

It's still missing. I have marked it as not stale.

[clerk-cookie]

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.

[tmcw]

Keeping this open for the same reasons as above.

[clerk-cookie]

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.

[tmcw]

I… wish that this bot would be turned off or this issue would be solved, it's annoying to have to comment to keep this very clear issue open, and have to advocate for a basic feature/doc improvement on a paid product.

[jescalan]

I'm so sorry @tmcw - we're going to look into getting this one closed out soon!

[tmcw]

Is this still prioritized?

[jescalan]

Hey @tmcw! It is, but it got lost in the backlog for ~2.5 months unfortunately. It was recovered about 2 weeks ago and is marked as a documentation improvement at the moment along with a couple deprecation warnings.

[anagstef]

Thanks @tmcw for mentioning this issue! We have added a deprecation warning on these properties and will be removed in the next major version of @clerk/remix.

The correct solution is the one that is already proposed in the original post: Add the external id info to the session claims and not use any of the loadX functions.

How to setup session claims: https://clerk.com/docs/backend-requests/making/custom-session-token

Example:

Then use it in the rootAuthLoader like this:

export const loader = (args: LoaderFunctionArgs) => rootAuthLoader(args, ({ request }) => {
  const claims = request.auth.sessionClaims;
  if (claims?.extid === null) {
    // do something
  }
  return {
    // data
  };
});

[clerk-cookie]

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.