The work we’d extract from HEY is likely to be high-level, like CurrentAttributes, has_secure_password, and the like. I don’t have any personal interest in a full-on Devise-level extraction. I don’t think that’s a good fit for framework inclusion. There are way too many variations and app-specific flows that isn’t a good fit for framework inclusion, in my opinion.
I’m not precluding others from exploring this. Just want to temper the excitement for an ActiveAuthentication as something that’s coming out of our work on HEY. That’s not something we or I am working on.
Based on what DHH has said above, I think the Django approach would be too heavy handed, but it could still be useful for comparison. I haven’t used it or thought too much about it in about 1.5 years, but from what I remember, it’d be akin to rolling in both Devise and CanCan[Can].
Devise is already solid authentication engine, used by a lot of successful Rails apps. I don’t see point in building Authentication directly into Rails. If someone wants the full control over their auth process Rails offers tools to do that also(has_secure_password, cookies, sessions).
Not sure what could Rails team build that is going to be miles better than Devise.
Now that I think about it more, one of the difficulties of upstreaming authorization, as opposed to authentication, is multitenancy (& more generally policy scoping.)
I wrote a really lightweight authorization system a few years ago for a company that thought the policy-class approach of Pundit/etc was too heavyweight; I don’t remember the public API exactly but I think it looked something like this. Worked well for that team.
class Refund < ApplicationRecord
authorize :admin_or_owner, on: :read
authorize :admin, on: :create
end
But I deliberately didn’t tackle policy scoping and I’m not 100% sure policy scoping can be effectively tackled with that lightweight of an API. Maybe I’m not thinking big enough / being creative enough here, though. I do hear the people who think that lightweight APIs like that are more Rails-y than something like Pundit that introduces a new “pattern class type.”
I think there is value in ActiveAuthentication, but I think the place to start with it might be less big ideas and more “what small pieces can we extract from devise, which has proved itself, that are generalizable at the framework level?”
Maybe what actually makes sense would be rolling in Warden, not Devise?
that would be brilliant! howeverrrr, warden is pretty low-level, and messing with rack’s env in the middle of my authentication code feels somewhat like a “layer clash”.
yeah i haven’t the faintest idea lol. the easiest part is the env part which could just be abstracted into a getter named warden, or auth, or similar. in my opinion the problem is where to define the warden strategies and callbacks. the strategies could be part of config/, in, say, config/auth.rb, with a simple dsl for defining strategies. callbacks could also do that in config or maybe somehow be part of ActionController? i’m not sure.
when i’m using pure warden i put that stuff in the initializers, but that’s not great for Rails i think.
This example solution does not provide any authorization functionality in my opinion. It does not authorize the actor but simply validates the object being acted upon.
I build business applications. Authentication to me is something which doesn’t add a lot of value, so I’m happy to plunk in standard Devise email/password login and call it a day.
Authorization on the other hand is a totally different beast which requires a lot of attention. Authorizing at the model layer doesn’t work since we have dynamic roles, so it feels like I end up defining authorization checks in every controller action, and have a set of controller tests covering the default set of roles.
one thing that would be really nice to see in active_authorization is good test integration.
I mostly use devise, but have used other systems too. I always end up with a bunch of ugly hacks in my testing for authorisation.
speaking personally - I’d love to see for the login systems I see most often.
namely:
email/password
oauth (with easy plugin/configuration for different providers)
omniauth provides a lot of this, but it still makes me do the work to handle integrating multiple login systems and multiple oauth providers.
some kind of generator to provide the skeleton of the UI would seem like a reasonable tradeoff between rails doing too much UI, and rails not actually helping to solve the problem.
(show me the views and structure I need - and let me customise them myself)
