This addresses a DoS vulnerability where the response might be massive
leading to OOM errors, as the response is read in full in memory by
default.
To prevent this, we need to read the body in chunks, checking the
size of the chunks we've read and raising if we go over a certain limit.
I've set the limit to 100 KB because the responses to these requests
should be fairly small or even empty, and we only care about the status
code in the end.
(Caught one such uniqueness exception in the wild)
* 200 OK -> 204 No Content, default status
* No need to touch the subscription when found
* Drop superflous test
Rails memoizes `@app_env_config`, so running push subscriptions test
after join codes test will result in running with `show_exceptions:
:none`, causing RecordInvalid to raise instead of returning 422 status.
References #1996
When ActiveStorage::Record uses `connects_to` for read replica support,
it creates a separate connection pool from ApplicationRecord. This causes
`after_commit` callbacks to fire in non-deterministic order - the
Attachment's `create_variants` callback can fire before the User model's
upload callback completes, resulting in FileNotFoundError.
The fix removes replica connection configuration from ActiveStorage::Record
so it shares the same connection pool as application models, ensuring
proper callback ordering.
Also reverts test workarounds that were added to work around this issue,
since the root cause is now fixed.
See: https://github.com/rails/rails/issues/53694
Avoid Sentry exceptions when attackers try to stuff invalid emails. The
browser performs form field validation that should normally prevent this
from occurring, so we just return 422 without validation error messages.
See similar change in #1996 for sign-in and sign-up
Avoid Sentry exceptions when attackers try to stuff invalid emails. The
browser performs form field validation that should normally prevent this
from occurring, so we just return 422 without validation error messages.
Also:
- extract redirect_to_session_magic_link helper
- some controller refactoring and cleanup
Specifically this will help people understand why their SVG avatar
uploads are being rejected, and will keep the RecordInvalid exception
out of Sentry logs.
Adds verified? check to bundling_emails? to prevent notification emails
from being sent to users who have never authenticated. This closes the
spam vector where bad actors could create users for known email
addresses and trigger unwanted notifications by mentioning them.
Co-Authored-By: Claude <noreply@anthropic.com>
User are marked as verified after a join code is redeemed. The user is
redirected to Users::VerificationsController, either:
- after submitting a valid magic link code,
- or immediately after redeeming the join code (if they're already
authenticated with the correct identity)
Account owners are automatically verified when the account is
created (because they have already provided a magic link code at that
point).
This sets up for later commits that will backfill existing users and
require verification before sending notification emails.
Co-Authored-By: Claude <noreply@anthropic.com>
Reworked the magic link stimulus controller, because the system test
was causing double-submission of the form (because the event was
bubbling up). I think that change simplifies the form and will still
work well for iOS devices.
Process variants synchronously on attachment to close the window between
image upload and variant availability, guaranteeing that we won't have
lazy variant processing attempts in GET requests.
Tradeoff is that we do variant processing in upload requests, which is
actually desirable. We're working with images that should take
milliseconds to resize given that we'll already have the file on hand.
References https://github.com/rails/rails/pull/51951
Add SSRF protection for web push endpoints:
- Resolve endpoint IP once and pin it for connection
- Validate endpoints resolve to public IPs
- Whitelist permitted push service hosts
Add missing IP ranges to SsrfProtection:
- 100.64.0.0/10 (Carrier-grade NAT, RFC6598)
- 198.18.0.0/15 (Benchmark testing, RFC2544)
Note: link-local (169.254.0.0/16) is already covered by ip.link_local?
using the "standard" email regexp URI::MailTo::EMAIL_REGEXP. The form
field will validate this in the browser, but if bots are creating
identities, they can put whatever they want in here. So let's add some
protection against that.
The HtmlHelper regex was renamed here to avoid confusing Brakeman,
which does imprecise constant lookup and was confusing the two
constants, one of which uses `\A` and `\z` and the other does
not (intentionally).
ref: https://app.fizzy.do/5986089/cards/3276
We missed this one when we went to MySQL. This can results in cards tagged with cards
from other accounts. No data leaked though: the symptom is that you see the card
tagged as expected but you don't see the tag in the menu.