We have what is becoming a rather large webapp using yesod/persistent but have been doing authorization in a rather ad-hoc way. I'm wondering if anyone else has dealt with this problem and has a smarter way to do it. Here's a summary of the issue. In persistent we have a User table and we pull UserIds from the maybeAuth or requireAuth functions in yesod.auth. We then have some other tables which might reference the userId directly or reference something else. Based on the userId, the user either should have no access, read access, or write access to that row. doesn't need to be a perfect or foolproof solution but something better than our current, completely ad-hoc approach would be an improvement. max
In the Rails world all the most popular authorization plugins have a
declarative dsl for setting up the logic of authorization. That logic can
then be integrated into the models, the handlers, and the views.
https://github.com/ryanb/cancan/wiki/Defining-Abilities
https://github.com/stffn/declarative_authorization
On Sat, Apr 23, 2011 at 3:47 AM, Max Cantor
We have what is becoming a rather large webapp using yesod/persistent but have been doing authorization in a rather ad-hoc way. I'm wondering if anyone else has dealt with this problem and has a smarter way to do it.
Here's a summary of the issue. In persistent we have a User table and we pull UserIds from the maybeAuth or requireAuth functions in yesod.auth. We then have some other tables which might reference the userId directly or reference something else. Based on the userId, the user either should have no access, read access, or write access to that row. doesn't need to be a perfect or foolproof solution but something better than our current, completely ad-hoc approach would be an improvement.
max
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
So far for my uses, isAuthorized has been sufficient, together with
some simple helper functions applied as necessary. However, I'd be
happy to try to flesh out a more complete system. Can you point out
specific issues that you're running into that seem like they could be
solved better?
Michael
On Sat, Apr 23, 2011 at 1:47 PM, Max Cantor
We have what is becoming a rather large webapp using yesod/persistent but have been doing authorization in a rather ad-hoc way. I'm wondering if anyone else has dealt with this problem and has a smarter way to do it.
Here's a summary of the issue. In persistent we have a User table and we pull UserIds from the maybeAuth or requireAuth functions in yesod.auth. We then have some other tables which might reference the userId directly or reference something else. Based on the userId, the user either should have no access, read access, or write access to that row. doesn't need to be a perfect or foolproof solution but something better than our current, completely ad-hoc approach would be an improvement.
max
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
What I've done in the past for a highly scalable (across many teams of
users) is employed a resource-requester model. Where you have a generic
accessor wrapper that behaves like a transaction, but when you construct the
transaction you pass in the userId. Every resource record will reference a
table of who is allowed to access it and with which access level. So the
queried tables inside of the authTransaction will implicitly join across
that permission table.
This approach is great because its hard to screw up. The interface simply
won't let you request a resource without supplying who is requesting it. The
downside is that its an extra join for every query.
Though I employed this technique with mongoDB and had no speed problems
because I put the access list directly into each table. :)
Apologies if this hard to follow, I'm sitting at a camp fire tapping on my
phone.
On Apr 23, 2011 1:24 PM, "Michael Snoyman"
We have what is becoming a rather large webapp using yesod/persistent but have been doing authoriz...
participants (4)
-
Greg Weber -
Max Cantor -
Michael Snoyman -
Rick Richardson