Closed mikker closed 1 year ago
Thank you Mikkel for your continuous work on this gem, it's one of my favorite.
I love and really look forward having tokens hashed
I've always felt weird that the sign in would accept any email and say that if you're there you may receive an email. I understand the reasons behind it, but from a UX point of view it's not that great
Some food for thoughts:
dEW23dGRfsIRwef
Thank you @xdmx!
have you thought about having a token like what used nowadays […]:
Yes, this was what I was trying to describe in point number 4 ( Add new input token manually screen when signing in.). This is the approach that I'm using in an actual app, gerating 6 chars, only upper case and numbers:
class AuthToken
CHARS = ('A'..'Z').to_a + (0..9).to_a.map(&:to_s)
def self.generate
Array.new(6).map { CHARS.sample }.join
end
end
Rate limiting code requests is a very good idea 👍
I don't think we should add more complexity to the views or the controller. It's not very hard to add your completely own, custom controller and view code if you have special needs, like AJAX responses and such. I'd rather provide examples of custom code than include actual implementations that we'd just have to then support going forward.
Yes, the render on create
is sort of weird and messes with reloads. I'm not sure how big a problem it is outside development but it is sure a bit annoying when testing the create
action.
Having official support for system and controller/request specs (started in #71) would be really nice for 1.0
I can’t think of major changes that would be needed. But 1.0 should be turbo compatible. I think that would only mean form errors may need to be handled differently.
I can’t think of major changes that would be needed. But 1.0 should be turbo compatible. I think that would only mean form errors may need to be handled differently.
I was trying out Turbo with my app the other day. I didn't spend a whole lot of time on it, but I did get the following error when trying to request a passwordless sign on:
Error: Form responses must redirect to another location
I do use custom templates for my session/new
and session/create
, but they don't fundamentally change anything. I can get round this by adding data: { turbo: false }
to my form_with
, but obviously then I don't make use of Turbo.
How can the open redirect vulnerability be avoided?
Probably, by making sure that passwordless_query_redirect_path cannot redirect to other websites.
In the rare instance of a multi-domain application, a passlist can be issued via a config param.
It seems to me that destination_path
should accept only a path to the same domain, but here: https://github.com/mikker/passwordless/blob/484e05df011c3f588db880a85b070bb3808e7c43/app/controllers/passwordless/sessions_controller.rb#L77
Are we sure that host
can only be the application host?
It's currently not possible for users to update their email addresses. For any long-lived application, this is a required feature. With @rickychilcott we're thinking of the best approach here: #106
Regarding the Turbo issue: I believe responding with a 422 (Unprocessable Entity) should address it (based on this comment https://github.com/hotwired/turbo-rails/issues/12#issuecomment-754629885)
EDIT: ah sorry, this only applies for error scenarios
@mikker what is missing to bring this to the finish line and release a v1 with these changes?
Would you consider releasing a v0.11 with these changes and then separately add the remaining ones (shorter tokens and sign in message) and then release a v1?
Following the semver a 0.x it would be acceptable to change something that could break (like the routes and hashed tokens) as it's still in development:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
This PR marks the beginnings of working towards a 1.0 of Passwordless.
There will be breaking changes.
Plans
isolate_namespace
users.sign_in_path
and even weirdermain_app.whatever_path
.passwordless_for :users
and:admins
) is broken