The Cognitive Distortion Journal (CDJ) is a smart journaling tool that helps remedy distorted thinking. It can feel impossible to follow the CBT technique of labeling distorted thinking and finding alternative modes of thought (i.e. reframing) while cognitive distortions are occurring. The CDJ does that work for you. -- The CDJ is in beta testing!!
This pull request introduces rate limiting to the application, aiming to enhance security by preventing brute force attacks and ensuring equitable resource use across users. By differentiating rate limits between authenticated and unauthenticated users, this provides a more secure and user-friendly experience, allowing for a reasonable number of login attempts while protecting against abuse.
Changes
Integrated express-rate-limit middleware to enforce rate limits on incoming requests.
Configured two rate limiting strategies:
Unauthenticated Requests: Set to allow 10 requests per 10 minutes, aiming to prevent brute force login attempts while accommodating genuine users.
Authenticated Requests: Increased limit to 500 requests per 10 minutes, recognizing the authenticated status and granting more access flexibility.
Custom keyGenerator function to distinguish between authenticated and unauthenticated users, using user ID for authenticated requests and IP address plus session ID for unauthenticated requests.
Custom rate limit exceeded message to inform users when they hit the rate limit, along with instructions on when to try again.
Implemented a custom handler for rate limit violations, throwing an ExpressError with a 429 status code, seamlessly integrating with the application's existing error handling framework.
Rationale
Implementing rate limiting is crucial for securing the application against automated attacks and ensuring that resources are fairly distributed among users. The chosen thresholds aim to strike a balance between security and usability, particularly around the login process, where users might make several attempts before successfully logging in.
Testing
[x] Manual Testing: Conducted manual tests to ensure that the rate limits trigger as expected for both unauthenticated and authenticated scenarios.
[ ] Automated Tests: Add unit tests to verify that the rate limit settings are correctly applied and that the custom keyGenerator function behaves as intended.
[ ] Load Testing: Simulate high-traffic conditions to ensure that the application behaves as expected under load and that legitimate users are not adversely affected by the rate limiting.
Deployment Considerations
Monitor the application logs and user feedback closely following deployment to adjust the rate limits if necessary.
Implement Rate Limiting for Enhanced Security
Overview
This pull request introduces rate limiting to the application, aiming to enhance security by preventing brute force attacks and ensuring equitable resource use across users. By differentiating rate limits between authenticated and unauthenticated users, this provides a more secure and user-friendly experience, allowing for a reasonable number of login attempts while protecting against abuse.
Changes
express-rate-limitmiddleware to enforce rate limits on incoming requests.keyGeneratorfunction to distinguish between authenticated and unauthenticated users, using user ID for authenticated requests and IP address plus session ID for unauthenticated requests.ExpressErrorwith a 429 status code, seamlessly integrating with the application's existing error handling framework.Rationale
Implementing rate limiting is crucial for securing the application against automated attacks and ensuring that resources are fairly distributed among users. The chosen thresholds aim to strike a balance between security and usability, particularly around the login process, where users might make several attempts before successfully logging in.
Testing
keyGeneratorfunction behaves as intended.Deployment Considerations