@rajdip-b picking this as this does not require major change, can work parallelly with create user #13
assign this to me

@Sachinsharma01 assigned to you. Do open a thread in discord regarding this issue since we still haven't fixed on what parameters we will do the rate limit. So you can get on with this after we have came to a decision!

ok, got it

As per discussion, we are going to have rate limiting as below

We would want to send OTP, validate OTP to be rate limited to 10 requests per minute for a single user
Upon multiple failures of validate OTP (20 consecutive times over any period), we want to send a mail to the user that their account failed authentication 20 times. They might want to take the necessary steps.
The rest of the endpoints will follow a standard 20-50 requests per minute based on the computation power it takes, but we will stall that for a later issue.

Yes, correct. That looks good! @Sachinsharma01

yeah, picking this up for development

can I work on this issue? @rajdip-b

Sure thing! Go ahead.

The requirements of this issue is still not clear, so please feel free to add a list of the implementations you would be making before you go ahead and code it.

But the next 10days are very hectic for me and I can only start solving after that. If that's okay with you

Yeah no problem with that

Hi there, My team and I are paricipating in FOSS Hack 2025 are interested in working on this issue. Could you please provide guidance and more information regarding this issue.

Howdy! yes, we will update the issue description with the details shortly. This issue has been present for a long time now.

Howdy, Thanks for assigning the issue, I'll review the details once updated and get started. Let me know if there's anything specific you'd like us to consider.

Hey, Rajdip hope everything's going well, so fosshack's tmrw, can you please guide us with the details regarding the api rate limiting issue.

Oh boy, yes i absolutely forgot. I'm updating this right away. Thanks for dropping in a reminder

Okay I think as of now this is a pretty generalized issue. We don't have any specific use cases as of now. What we would ideally like to have is, all the endpoints should have a rate limit for the number of requests. For instance, we don't want a user to be able to spam our APIs with automated requests. Let's say, someone tries to create a DOS attack on our servers by making expensive requests.

The solution we would like to have is, put in a configurable number of requests per second that would be accepted by any users. We should be filtering this both based on IP Address and user ID.

Hey Rajdip, Good Morning and a Happy Sunday :)
I’ve set up global rate limiting that applies per user (if authenticated) or per IP (if not). Also fixed the OTP validation issues, so it’s workin now. Do you think we should set a specific lockout duration, and should users get notified when their account gets locked? currently in the api logs it would show the 429 too many request error.

So I was also thinking about future enhancements, like account lockout for too many failed OTP attempts, but I’m not exactly sure how I’d do it. Right now, I’m thinking of storing the lockout status in the database since I’m not familiar with it and don’t want to break anything.

I don't think an unlock feedback would be needed.

Also, we don't want the locks to be specific, but general to all the endpoints. But we should also have the ability to configure the max hits for each and every endpoint. I would suggest you to develop a custom decorator to override this. Something like @MaxRequestsPerUser(20). By default, the value can be 10 per second (or whatever you feel is okay) if the annotation is not specified. But if it is, we should accept the value as an override.

As for storing the status, i think the cache might be a better place to do it. A tuple like (userId, endpoint, lockedUntil) would be a good choice.

oh ok, well i have already implemented a general lock out period for all endpoints, we will work on the overide usinng a decorator. might i push a pr so you can review my progress?

@Dhanushranga1, please open a draft PR linking this issue!

@Dhanushranga1, please open a draft PR linking this issue; otherwise you will be unassigned from this issue after Tue Feb 25 2025 10:02:30 GMT+0000 (Coordinated Universal Time)!