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>
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
#sample uses PRNG under the hood which is pseudo random, which means that given enough magic link codes you can predict which code would come next. To fix that we have to switch to CSPRNG - SecureRandom.random_number - which isn't easy to predict based on previous results.
Aligns with Rails conventions for organizing concerns in a dedicated
concerns directory alongside existing concerns like Attachments,
Mentions, Searchable, etc.
Patch load_schmema! to set the default value for UUID primary keys. This
removes the need to patch ApplicationRecord + Rails models individually.
It also means we no longer need to patch the default in for the integer
primary key in Search::Record::SQLite.
- 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.
The problem was that publishing a card with `#publish` was tracking the event
after updating the status, which was clearing the saved changes and preventing the
code from detecting the mention.
See:
https://app.fizzy.do/5986089/cards/2835
Previously if someone started signing in on their phone, but finished it on their laptop, they'd end up on the menu screen with no account. Bu tracking the purpose of a Magic Link we can always direct the user to sign up if they requested a magic link through sign up. This also makes the logic for changing the copy in the email more robust.
Mike Dalessio