Since Rails added authentication generation, which is cool, I wonder if we can add another generator to create magic link-based authentication instead of password-based authentication? Magic links have quite a lot of advantages: you don’t need to store passwords, you don’t need to create 2FA, you don’t need a ‘forgot your password’ feature, etc. I would be happy to contribute if this idea sounds valuable.
I like this idea!
Rails Authentication generator wants to be minimal. This is good cos it clears the magic behind authN and authZ somewhat. For things like this, I would rather a gem pool of different auth generators for rails, unlocking different capabilities.
1 Like
I recently built my own magic link authentication using the ActiveRecord::TokenFor::ClassMethods - Ruby on Rails API functionality.
This worked great but I had to scrap it and replace with a emailed code.
Here’s why I replaced the magic link authentication:
-
Outlook was pre-fetching the link and invalidating the token. In general, get requests should not be making any changes because they get pre-fetched in various scenarios. I added a post-based step but encountered 2.
-
Some email systems automatically flag and quarantine long links as malicious. Especially in the enterprise world.
So, I replaced the long link with a 6-digit single use code which expires in a few minutes. Also use rack-attack to limit code entry attempts.
Hi! I actually have a hybrid approach in my app. The magic link has an embedded 6-digit code which keeps it short. When a user tries to sign in, they receive an email where they can either click the link or copy the code to enter it manually in a form that appears after entering their email and clicking sign in.
By the way, when you mention a post-based step, do you mean that when the user clicks the link, they’re taken to a page where the code is pre-entered and they must click a button? I haven’t got users struggling with prefetched links yet but I think eventually I will get some.
It is ultra-important that GET requests never change anything. Long ago, before REST was a thing in Rails, the destroy action was kind of like the edit action, in that the only difference between it and show was the presence of a URL segment. /widgets/42/delete or similar.
Yahoo came out with their toolbar extension for various browsers, which would “speed up” the Web by pre-fetching all the visible links on the page in the background. Much hilarity ensued, and many folks discovered that their fancy Web 2.0 apps didn’t have adequate database backups.
Suddenly, Rails got the REST religion, and the destroy action became a POST masquerading as a DELETE (using the _method hidden field element). Since the toolbar could not submit forms without a user click (indeed, browsers generally won’t do that at all or allow it to this day), the crisis was averted, and we all learned a bit more about network protocols.
Walter
1 Like