feat: polly-based rate limiter for limiting amount of emails that could be sent for passwrod reset/email-confirm#2
Conversation
…ld be sent for passwrod reset/email-confirm
| var result = await _emailSender.SendResetEmail(email, callbackUrl); | ||
| if (result.HasError) | ||
| { | ||
| return StatusCode(500, result.Error); |
There was a problem hiding this comment.
changed to 429.
Usually (not normally, but usually) 429 response it returned with RetryAfter header or something like that, but sadly (and very oddly) sliding window setup from Polly does not properly give RetryAfter by itself (tested it) - i guess for now it would not be problem, as we are not aiming to get 429 properly handled by Launcher RIGHT NOW, but it will be when we will be back to it...
| public sealed class EmailSender : IEmailSender | ||
| { | ||
| private readonly IRawEmailSender _rawEmailSender; | ||
| private readonly MutexDatabase _mutex; |
There was a problem hiding this comment.
MutexDatabase is not in use now - should i remove it? It looks kinda neat. It also is related to table for storing data - should i remove it too?
|
Tested:
|
…mail on register.
| /// </summary> | ||
| public sealed class LimitOptions | ||
| { | ||
| public int MaxEmailsPerHour { get; set; } = 5000; |
There was a problem hiding this comment.
Limit name changed, as now it represents not per-hour but per-window limit - i think it should be okay?
|
I am not very happy with caching Polly pipelines in memoryCache, they are not fat but it just does not sound pleasing (those are objects that would live quite long as a result and will stay away from being GCed). If we had Angular front-end and webapi back-end i would have just rate-limited requestes to back-end using middleware, but with razor - it won't be looking good, i bet... |
1 participant
Improvement to email sending logic that would enable rate-limiting said process based on target email addresses.
Added polly, changed shared static class that was doing formation of emails into interface, default implementation and decorator that uses rate-limiting. EmailSendingResult is result of sending, that possibly can contain error text (if sending failed).
Changed most of code to properly use result and display error.
Rate limits are applied based on target address, as scenario with forgotten password includes situation when current (target) user is not logged in (and it is just simpler).
Change to ValueTask is dictated by advertised way of using Polly rate limiter (it does not really hurt code that was touched).