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.
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.
Users could reorder columns they didn't have access to. Fixed by
limiting ColumnScoped to User::Accessor#accessible_columns.
References https://hackerone.com/reports/3449905
* robots.txt: "Please, don't come in." If a page is directly linked, the
URL can still appear in search results, though.
* X-Robots-Tag: "If you're here, forget what you saw." Works even if the
crawler ignores robots.txt or reaches a page via external link. Can
remove already-indexed pages.
* Public boards may not be indexed. They're meant for "anyone with the
link" private sharing, not worldwide publishing.
- Adds a button in Account Settings where you can request a ZIP export of your
Fizzy data
- Export files are created in the background. When ready, a link to
download them is sent to the requester.
- Exports expire after 24 hours. And are limited to 10 per day.
Mike Dalessio