but this module has not been updated for 2 years.
Are you trying to limit genuine or malicious users? A malicious user can
always circumvet the limites by creating his own cookies and sending
them.
Are you trying to limit genuine or malicious
users? A malicious user can
always circumvet the limites by creating his own
cookies and sending
them.
Genuine users of specific application - this why I though that session
should be most reliable way. The other option
is to limit by IP but AFAIU this is not good in case several users are
connecting from behind the same proxy.
Could you recommend other options?
should be most reliable way. The other option is to limit by IP but
AFAIU this is not good in case several users are connecting from behind
the same proxy. Could you recommend other options?
You need some sort of a way to ensure that the per user token (in this
case session id in a cookie) was actually issued by you. The token
should have the following properties:
Computationally inexpensive to check if you had issued the token
Computationally prohibitive for others to create a token that will
pass the test above
Failure to produce a legitimate toke by the user shoudl result in a HTTP
403
user token (in this
case session id in a cookie) was actually issued
by you.
The web application which I need to throttle is a php one. I’m not a
php coder and only slightly familiar with php - can I assign a custom
algorithm to php session id generation?
Also how can I verify the session id inside nginx? Should I write a
special verification code in nginx embedded perl?
Failure to produce a legitimate toke by the user
shoudl result in a HTTP
403
Now that I think about cookie based limiting again - it’s not clear to
me how new client connections will be handled, by
the connection/request limiting modules, before the application assigns
them a valid cookie?
It is not clear to me if i any nginx builtin variable is accessible inside any module directive (which uses variables).
I mean there are several phases in HTTP request processing (like I saw here catap's blog ~ nginx: фазы обработки http запросов) - and it’s not clear to me at which phase the $cookie_name is generated (or any other variable) and whether it’s generated after or before the limit_req_zone/limit_zone directives are processes?
Variable $cookie_name is available as soon as nginx has Cookie
header from client. It happens before request processing phases.
Now that I think about cookie based limiting again - it’s not clear to
me how new client connections will be handled, by the
connection/request limiting modules, before the application assigns
them a valid cookie?
Excellent point. You can never rate limit the connects. You always have
to accept the connection, inspect the cookie and then decide if you want
to service the request or not. The rate limiting is enforced at an
aplication level and not at a network level.
It is not clear to me if i any nginx builtin variable is accessible
inside any module directive (which uses variables).
I mean there are several phases in HTTP request processing (like I saw
here catap's blog ~ nginx: фазы обработки http запросов)
and it’s not clear to me at which phase the $cookie_name is generated
(or any other variable) and whether it’s generated after or before the
limit_req_zone/limit_zone directives are processes?
Thanks
Alex
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.