ostap
After opening a magic link, the user must click a confirmation button to log in and invalidate the token. I assume this exists to prevent email scanners from consuming links.
Could this be automated with a short JS setTimeout that submits the confirmation request automatically? Or is this a bad idea? I assume that scanners only fetch the HTML and don’t always have a headless browser or keep it open for long.
Current behaviour after the registration link is opened:
Current behaviour after the login link is opened:
mix phx.new example --module=Example --database=sqlite3 --no-live
cd example
mix ecto.create
mix phx.server
mix phx.gen.auth Accounts User users # n - Using Phoenix.Controller only
mix deps.get
mix ecto.migrate
mix phx.server
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
garrison
I would say this is a dangerous assumption. If the scanners don’t use a headless browser that would make it trivial for bad actors to bypass the scanners with a simple React app. Given that the scanners and the bad actors are locked in an endless back-and-forth my guess would be that the scanners have been running JS for a while.
There is a mutual understanding between the scanner developers and web developers that scanners will not issue POST requests. Everyone is on the same page about this, so it is unlikely to change.
On the other hand, if you design a login page using some timeout, even if you test to ensure that it works today the scanner could always change its behavior tomorrow and break your website while you’re asleep.
I think it would be wise to stick with the standard method.
ostap
Thank you! Decided to try a slightly riskier/novel approach:
My BotD library fork detects whether the visitor is not a bot (headless chromium), and only then will the form be submitted automatically.
I think it’ll be worth it as a UX improvement. But we’ll see if anyone complains
; it’s a small side project where I’m testing this out.