github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-10-18 11:32:15 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Server side calls also subject to rate limiter #656

New Issue
Closed
opened 2026-03-13 07:59:05 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-03-13 07:59:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @matthiasfeist on GitHub (Feb 11, 2025).

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

When using a server side call e.g. https://www.better-auth.com/docs/basic-usage#server-side-authentication then this call is not handled by the rate-limiter. At least I can't see that it adds rows to the database whereas the Client Library does.

Describe the solution you'd like

I believe it would be an amazing feature if the server side calls could be configured to also be subject to the rate limiter.
That would make my NextJS Server actions much safer by default since I handle most of my logic there.

Describe alternatives you've considered

n/a

Additional context

No response

Originally created by @matthiasfeist on GitHub (Feb 11, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. When using a server side call e.g. https://www.better-auth.com/docs/basic-usage#server-side-authentication then this call is not handled by the rate-limiter. At least I can't see that it adds rows to the database whereas the Client Library does. ### Describe the solution you'd like I believe it would be an amazing feature if the server side calls could be configured to also be subject to the rate limiter. That would make my NextJS Server actions much safer by default since I handle most of my logic there. ### Describe alternatives you've considered n/a ### Additional context _No response_
GiteaMirror commented 2026-03-13 07:59:05 -05:00
Author
Owner
Copy Link
Copy Source

@jslno commented on GitHub (Feb 13, 2025):

I think it would be better if it would provide something like await auth.rateLimiter.check('KEY', { /*...options */ }). Like this you could use it outside better-auth with a single configuration source and also rate limit by your own key.

@jslno commented on GitHub (Feb 13, 2025): I think it would be better if it would provide something like `await auth.rateLimiter.check('KEY', { /*...options */ })`. Like this you could use it outside better-auth with a single configuration source and also rate limit by your own key.
GiteaMirror commented 2026-03-13 07:59:06 -05:00
Author
Owner
Copy Link
Copy Source

@matthiasfeist commented on GitHub (Feb 13, 2025):

That's also a great approach!

@matthiasfeist commented on GitHub (Feb 13, 2025): That's also a great approach!
GiteaMirror commented 2026-03-13 07:59:07 -05:00
Author
Owner
Copy Link
Copy Source

@Kinfe123 commented on GitHub (Mar 31, 2025):

i dont think that actually some that is related to the core of the library. since the already existed one just meant just to avoid the overhead on adding guards on those sensitive endpoints. i guess for now this is not gonna be included as core of the package and it should not have to be based on our rule on adding the server side ratelimiter as well. we will open it if it is something that is really needed but it could be handled with your storage choice and schema.

@Kinfe123 commented on GitHub (Mar 31, 2025): i dont think that actually some that is related to the core of the library. since the already existed one just meant just to avoid the overhead on adding guards on those sensitive endpoints. i guess for now this is not gonna be included as core of the package and it should not have to be based on our rule on adding the server side ratelimiter as well. we will open it if it is something that is really needed but it could be handled with your storage choice and schema.
GiteaMirror commented 2026-03-13 07:59:07 -05:00
Author
Owner
Copy Link
Copy Source

@budivoogt commented on GitHub (Jul 4, 2025):

i dont think that actually some that is related to the core of the library. since the already existed one just meant just to avoid the overhead on adding guards on those sensitive endpoints. i guess for now this is not gonna be included as core of the package and it should not have to be based on our rule on adding the server side ratelimiter as well. we will open it if it is something that is really needed but it could be handled with your storage choice and schema.

Apologies, but could you attempt to explain your point of view again here? I didn't understand your response. I also have implemented BA server-side and would love for the auth.api calls to be rate limited too. What's the reasoning behind not including server-side requests in the limiting? Are there any advantages to that which I'm missing?

@budivoogt commented on GitHub (Jul 4, 2025): > i dont think that actually some that is related to the core of the library. since the already existed one just meant just to avoid the overhead on adding guards on those sensitive endpoints. i guess for now this is not gonna be included as core of the package and it should not have to be based on our rule on adding the server side ratelimiter as well. we will open it if it is something that is really needed but it could be handled with your storage choice and schema. Apologies, but could you attempt to explain your point of view again here? I didn't understand your response. I also have implemented BA server-side and would love for the `auth.api` calls to be rate limited too. What's the reasoning behind not including server-side requests in the limiting? Are there any advantages to that which I'm missing?
GiteaMirror commented 2026-03-13 07:59:08 -05:00
Author
Owner
Copy Link
Copy Source

@vnphanquang commented on GitHub (Sep 11, 2025):

I'd also advocate for the ability to rate limit auth.api on server, or some auth.rateLimiter API as suggested by jslno.

My use case is to do some server-side data validation before sign-up/sign-in. This involves querying database, which is not available client-side.

It's true that workaround is possible, such as passing data in header and perform said validation via better-auth hooks, but I'd argue it's more ergonomic on the server, especially when using form data, which would otherwise require additional JS on the client.

@vnphanquang commented on GitHub (Sep 11, 2025): I'd also advocate for the ability to rate limit `auth.api` on server, or some `auth.rateLimiter` API as suggested by `jslno`. My use case is to do some server-side data validation before sign-up/sign-in. This involves querying database, which is not available client-side. It's true that workaround is possible, such as passing data in header and perform said validation via better-auth hooks, but I'd argue it's more ergonomic on the server, especially when using form data, which would otherwise require additional JS on the client.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#656