| # |
Feb 19th 2009, 14:51 |
AD7six |
and any other apps built going forwards |
| # |
Feb 19th 2009, 14:51 |
AD7six |
and any other apps that are built going forwards |
| # |
Feb 19th 2009, 14:50 |
AD7six |
the same user table is used in the book - the book's permissions are seperate and different |
| # |
Feb 19th 2009, 14:50 |
AD7six |
alkemann: you weren't here when I came in: something that I consider important is that the user data should be seperate from the apps data and logic |
| # |
Feb 19th 2009, 14:50 |
jperras |
AD7six: if Group hasMany User, where else would it be? |
| # |
Feb 19th 2009, 14:49 |
alkemann |
yes. important part of the solution |
| # |
Feb 19th 2009, 14:49 |
AD7six |
for one the group_id field is in the users table |
| # |
Feb 19th 2009, 14:49 |
AD7six |
oo don't like that so much ;) |
| # |
Feb 19th 2009, 14:48 |
jperras |
bottom of the wiki page, AD7six |
| # |
Feb 19th 2009, 14:48 |
alkemann |
http://thechaw.com/bakery/wiki/spec/users/Group_permissions |
| # |
Feb 19th 2009, 14:48 |
AD7six |
I see a description of permissions |
| # |
Feb 19th 2009, 14:47 |
AD7six |
I don't see where it says how you're going to store and query permissions? |
| # |
Feb 19th 2009, 14:47 |
alkemann |
the one* |
| # |
Feb 19th 2009, 14:47 |
alkemann |
AD7six: the we have specced already |
| # |
Feb 19th 2009, 14:46 |
AD7six |
alkemann: what solution would you suggest |
| # |
Feb 19th 2009, 14:46 |
jperras |
which the acl behavior supports (ini configuration instead of db config) |
| # |
Feb 19th 2009, 14:46 |
jperras |
with a static config file |
| # |
Feb 19th 2009, 14:46 |
jperras |
you're basically implementing a flat tree acl in that description |
| # |
Feb 19th 2009, 14:45 |
alkemann |
we dont need it. |
| # |
Feb 19th 2009, 14:45 |
jperras |
I don't see a reason to not use acl here |
| # |
Feb 19th 2009, 14:44 |
alkemann |
"point to a random" |
| # |
Feb 19th 2009, 14:44 |
alkemann |
as far as i am concerned, if you can find a reason to not use acl, take it. and the since we dont need to be able to point to give a random user a random right to a random asset, acl is overkill |
| # |
Feb 19th 2009, 14:44 |
jperras |
of course not. but it's already written, heavily tested, and included in the cake core |
| # |
Feb 19th 2009, 14:43 |
alkemann |
so acl is the only valid implementation of permissions? |
| # |
Feb 19th 2009, 14:43 |
jperras |
well, if it sounds like a duck, quacks like a duck, why not use a duck? |
| # |
Feb 19th 2009, 14:42 |
alkemann |
yes. permission implementations are bound to share descriptions :p |
| # |
Feb 19th 2009, 14:41 |
jperras |
control user permissions based on their group, and the controller action that they are attempting to use |
| # |
Feb 19th 2009, 14:41 |
jperras |
alkemann: that first paragraph sounds exactly like what acl does |
| # |
Feb 19th 2009, 14:40 |
alkemann |
jperras: http://thechaw.com/bakery/wiki/spec/users/Group_permissions |
| # |
Feb 19th 2009, 14:39 |
alkemann |
we arent useing acl though |
| # |
Feb 19th 2009, 14:36 |
jperras |
so if we're going all AI, great |
| # |
Feb 19th 2009, 14:35 |
jperras |
it's about mixing char(36) with int in cake's acl system |
| # |
Feb 19th 2009, 14:34 |
jperras |
it's not about being able to guess |
| # |
Feb 19th 2009, 14:34 |
alkemann |
jperras: given how we will implement permissions and that things are either public or not, i dont see any problem with "guessable" urls. ie we can just use AI for all ids |
| # |
Feb 19th 2009, 14:20 |
jperras |
as long as we're not mixing uuid and auto increments, I'm happy with that |
| # |
Feb 19th 2009, 14:18 |
alkemann |
dont see a problem using autoincrement for article id |
| # |
Feb 19th 2009, 14:18 |
AD7six |
id or a numeric sequence then. |
| # |
Feb 19th 2009, 14:17 |
markstory |
id/slug only works if you have numeric keys though. |
| # |
Feb 19th 2009, 14:17 |
AD7six |
excellenty |
| # |
Feb 19th 2009, 14:16 |
gwoo |
wfm |
| # |
Feb 19th 2009, 14:16 |
gwoo |
id/slug |