Bugfix: implement rate limiting for auth endpoints

[MikeSoft007]

​

Description

This pull request introduces rate limiting to selected API endpoints in our application. The goal is to prevent abuse and ensure fair usage by restricting the number of requests a client can make within a given time frame.

Rate Limiting Implementation:

• Added rate limiting middleware to the application.
• Configured rate limits for key API endpoints, including:
  -- /api/v1/auth/magic-link: Limited to 5 requests per minute per user.
  -- /api/v1/auth/login: Limited to 10 requests per minute per user.
  -- /api/v1/resource/*: General rate limiting applied across all resource-related endpoints.

Configuration:

• Introduced environment variables to manage rate limiting settings:
• RATE_LIMIT: Sets the maximum number of requests per time window (e.g., 100 requests per minute).
• RATE_LIMIT_SCOPE: Determines the scope of rate limiting (e.g., by IP address, user ID, etc.).
  ​

Related Issue (Link to issue ticket)

hngprojects/hng_boilerplate_nestjs#911

​

Motivation and Context

This change is required to ensure that the backend can handle request loads more effectively and prevent abuse, especially in high-traffic scenarios. Implementing rate limiting helps to maintain service availability and improves the overall user experience by ensuring that the API remains responsive and fair to all users.
This change is required to ensure that the backend can send emails that are more aligned with the requirements of the endpoints.

How Has This Been Tested?

The change was tested using integration tests in a development environment. The tests included:

• Sending various requests from Postman and verifying that the rate limiting is enforced correctly.
• Ensuring that users receive a 429 Too Many Requests response when exceeding the rate limits.
• Confirming that valid requests within the rate limits are processed as expected.

​

Screenshots (if appropriate - Postman, etc):

​

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  ​

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[johnson-oragui]

@MikeSoft007

add slowapi to requirements.txt, then update the branch