There was a bit of discussion on how Geeklog 2 will handle security in the IRC channel. The discussion also touched briefly on using the Model View Control (MVC) pattern. For reference, A&A stands for authentication and authorization and ACL stands for access control lists. I apologize this isn't in less-techy format. Click read more to see the IRC log.
-->| YOU have joined #geeklog
=-= Topic for #geeklog is “http://www.geeklog.net/ | Geeklog 1.3.7sr2 is out - Upgrading is strongly recommended!”
=-= Topic for #geeklog was set by dhaun on Mon May 26 2003 16:52:47 GMT-0400 (Eastern Daylight Time)
vinny IA-Outdoors: hello?
IA-Outdoors vinny 'sup?
IA-Outdoors sorry, was at lunch
vinny No problem, I just got on myself. Have a couple minutes?
IA-Outdoors sure
vinny Two agenda items: MVC code and A&A code. I looked at both last night for a couple hours (my daughter went to sleep early, so I had some time)
vinny For MVC, I like the code that you wrote much better than phrame. I don't think hes made any changes since March, and the added security hes talking about in that document you sent seems to be at the application level rather than in the MVC code.
vinny We do need to do a little bit of work on the MVCnPHP code to get it up to the same standard. But it is a much more PHP native implementation than phrame, which just seems to want to be just like java.
vinny What do you think?
IA-Outdoors I don't know yet, I haven't had time to look into his revisions which is why I thought I would have you take a gander
IA-Outdoors I will try and look it over this weekend, though
IA-Outdoors A&A is broke right now
IA-Outdoors I'm refactoring it a bit so that if you are running A&A on localhost you don't need to make socket connections
vinny Where are his revisions? All I found was the same code that was released before you talked about the MVC on the list.
IA-Outdoors (i.e. it will call the service methods directly
IA-Outdoors vinny dunno, should have been in that sample code link in his PDF
vinny I missed the sample code link. I'll look for it tonight and see, maybe there were improvements that he didn't check into sf.
IA-Outdoors Yeah, that would be my guess
vinny A&A: I don't know if you're going to like my suggestion. But I think we should trash the client/server setup for default A&A. Instead go with two classes, one for Authentication and one for Access that can overridden and/or extended. That way a person can do something a bit more simple like geeklog has now, or if they'd prefer, do the client server model, PAM, LDAP, or whatever.
IA-Outdoors the current system would support PAM/LDAP/etc
IA-Outdoors that's what the providers are for
IA-Outdoors once the core A&A code is done, the client will talk natively to the serivce layer so all coders need to worry about is teh providers
IA-Outdoors one of the goals for teh A&A portion was to allow other apps to tie in to this system (even tif they areremote)
vinny Yeah, but I don't think there is a need to be as complicated as what you have now. I don't know what your rework will look like, but the current/previous code is going to end up with _tons_ of overhead for something that will have to be done on almost every connection to the GL2 site.
IA-Outdoors no, you are missing the point
IA-Outdoors once authenticated, you get a user object that is serializable to the PHP session
IA-Outdoors thus no more trips to the A&A server
vinny That makes sense for authentication, but what about access?
IA-Outdoors same thing
IA-Outdoors all priv's come back in user object
vinny Are you going to cache group memberships and access rights? Won't that cause problems if people have long lived sessions?
IA-Outdoors define long lived?
IA-Outdoors there is definitley some level of caching
vinny In geeklog now, you can set it so that your "session" lasts for a year. I don't want to keep logging into a site from home computer...
IA-Outdoors and yes, if you edit the priv's, it won't take immediate effect on existing sessions
IA-Outdoors no, no, no that's different
IA-Outdoors even when you say remember me for a year, you session will time out
IA-Outdoors so, for example, if the sessions in teh DB table last for 15 minutes
IA-Outdoors each time a session times out a trip to A&A server needs to be made to get new user object
IA-Outdoors make sense?
vinny OK, I understand what your doing now.
IA-Outdoors keep in mind that the A&A portion is a potential $$ maker
vinny The User object contains only userid and access information? Or will it include preferences, etc?
IA-Outdoors vinny the user object only has the ID and priv's
IA-Outdoors however, because we are using PHP4 sessions, you can still store preferences in teh session
vinny OK, I just think I misunderstood the scope of the A&A and how it will interact with the session handler.
IA-Outdoors np
IA-Outdoors but I agree, the current A&A code is complicated
vinny So we'll be using PHP4 session for things like preference information and "stuff", but the database extenstions to the PHP4 session handler for the A&A stuff?
IA-Outdoors I don't like the xml string implementation but I think it will make supporting multiple os's and php versions easier
IA-Outdoors I do plan on adding xml-rpc and SOAP access at some point
IA-Outdoors xml-rpc would be first in line
vinny I guess as long as we can get it to work fast its OK. I was only concerned about the potential overhead it may create. Personally, I'd like GL2 to be a lot faster than 1.3.x
IA-Outdoors nods
IA-Outdoors yeah, the work to A&A I'm doing now will definitely help the access to A&A be faster for localhost installations
IA-Outdoors with the PHP4 sessions the nice thing is you get all user data in one DB call
IA-Outdoors unlike now where you go to user, userindex, userpref, etc
vinny Now, can I talk you into doing ACL's for security rather than geeklog's one user/one group model?
IA-Outdoors k, I'm all ears
vinny Well, the way I understand the plan is: all GL2 "objects" (articles, links, events, etc) will share a common table and use a ID similar to the current geeklog id...
vinny Create an acl table that assigned either a group or a user to certain access to an object.
IA-Outdoors to your first point, right, all items will have a unique ID
vinny So for a story for instance, I could give myself all access (say level 5), give a group of editors edit access (say level 4), give a group of readers read access (say level 2), and then give specific other users read access as necessary.
IA-Outdoors where items can be articles, polls, etc
IA-Outdoors uh, what do those level's mean?
IA-Outdoors e.g. level 5
IA-Outdoors ?
vinny I just made that up. Basically we'd have to figure out what we would need. My first guess would be the followiing "levels" or "access rights" (whichever term works better for you): Administrative (can control access, superuser control of the item), edit, read
IA-Outdoors I guess I fail to understand the limitations in the current system you are trying to 'fix'
vinny Say you want one group to have edit permissions, and another group to have read permissions on one story (and say "none" for anonymous and regular members). You couldn't do that under the current system. Also you couldn't have multiple "owners" of an item.
vinny We could make a basic interfact for access rights that is the same as geeklog's current system, just this allow more flexibility if its desired.
IA-Outdoors well, first issue is does having multiple owners make sense?
IA-Outdoors IMHO, no
IA-Outdoors however, your first point, specifying access to groups on a per item basis is interesting
IA-Outdoors Oh, and FYI, I don't pretend to have all the answers
vinny multiple owners for a large site might make sense, or one that is being used for colaborative (sp?) development.
IA-Outdoors well, IMHO, two owners = one group
IA-Outdoors I still think ownership belongs to one person
IA-Outdoors now, I think to address your other issue is as part of the set up you assign groups to modules
vinny Which would work under most circumstances, but it seems silly to make a group for each new story (for lots of owner permutations)
IA-Outdoors then when you create an item you can specify th rights for only the groups assigned to the module
IA-Outdoors Well, I guess it just depends on how you use the system
IA-Outdoors is this something that happens 90% of the time or 10% of the time?
vinny Some more complicated acls get very specific in the level of rights (which we could implement if we wish). For instance AFS (andrew file system) uses the following rights on a per directory basis: read list insert delete write administer.
IA-Outdoors if 10% of the time we need to really decide if the effort is worth it (which I don't have an answer to now)
IA-Outdoors well, a good questions here is what are commercial CMS's doing?
vinny It is a 10% of the time thing. But it wouldn't take much work to implement and would go a long way to giving geeklog a lot of power under the hood.
IA-Outdoors so is there a specific ACL model you want to follow?
IA-Outdoors theorhetically we could have a strategy pattern that could implement *nix-style ACL and another for any other ACL
IA-Outdoors that way user could customize GL2 to do what ever they want
IA-Outdoors my worry is to make the ACL system flexible
vinny There are a couple I'm looking at out there, but ACL's aren't really implemented in PHP very often (or on websites for that matter).
IA-Outdoors You'd be suprised at how many GL users can't figure out the current system ;-)
IA-Outdoors so I think you have to support the current system at the very least
IA-Outdoors anything outside of that is pure gravey
vinny I admit we'd need to do some research to come up with a really slick GUI for this, and some good documentation.
IA-Outdoors in fact, you could argue that since w are talking 10% of the users and that most of these users are 'sophisticated' that they may pay for any ACL outside teh current system ;-)
vinny Fortunately ACL's can be viewed as a super set of the current geeklog implementation, so we could leave the GUI alone and just use ACL's on the back end until we figure something better out. :)
IA-Outdoors well, it's simple really
vinny (and then charge for the slick GUI) ;)
IA-Outdoors it's just understanding how the data structures change
IA-Outdoors *exactly*
IA-Outdoors if we could define a data structure for supporting any ACL we could build generic objects now to leverage any enhanced ACL system in the future
IA-Outdoors the key would be making sure the DB structures can do it generically
IA-Outdoors let's plan on doing that (not a trivial thing I might add)
vinny It's just adding one table and removing the user/group/anon/member access out of the item table.
vinny The code actually won't be too bad, the SQL queries will just be a bit more complicated (done right though, just as efficient in time and memory).
IA-Outdoors I'm talkign about making db structures to support multiple ACL's
vinny Yeah, you will only need one table. 3-4 columns...
IA-Outdoors I think when you save an item you need to cache the access priv's on the item table to reduce SQL load
vinny "item id, user id, group id, permission level" and maybe an additional column for a unique primary key. Item id matches up to your main item table, one of user id and group id is null, the other contains an approriate value and then fill in the correct permission.
vinny A slick join will make the operation relatively quick. Especially with database side caching.
IA-Outdoors permission_level?
vinny permission level == access level. read, write, etc.
IA-Outdoors for who?
vinny Sorry, maybe we should decided which terms to use so we don't confuse each other. The permission/access level is for which ever item and group or user that is in that database row.
IA-Outdoors I'm thinking moreore liek this:
|<-- SuD has left irc.freenode.net ("G-Lined (Uso de un sistema operativo no autorizado en la red "kvirc3.0.0-beta3" )")
IA-Outdoors group_:|group_:|owner_:
IA-Outdoors allt hat in one DB field
IA-Outdoors err all that
IA-Outdoors err, make that:
IA-Outdoors group_:|group_:|owner:
IA-Outdoors it's not pretty but allows for the multiple group diea
IA-Outdoors and let's you get rid of group_id column
IA-Outdoors you follow that?
vinny SELECT i.*, MAX(a.priv) FROM item_table as i, priv_table as a WHERE i.id = a.id AND (a.group IN (user group list) OR a.user == username) GROUP BY a.id;
vinny I'm just letting the database do the work, rather than have to do it in php (which I think will be slower)
vinny I understand you're idea, I just like pushing the processing to the DB. I think it will be faster.
vinny Also if we do alternative queries for DB's that support views, it could get even faster...
vinny (though that would be a support nightmare)
IA-Outdoors yeah, we can't count on that
vinny But it isn't necessary... Even without views I think using the DB is faster and cleaner.
IA-Outdoors well, I'm not convinced the structures you are giving as examples are abstract enough to handle multiple owners/groups
IA-Outdoors or other ACL implementations for taht matter
vinny Each owner group would have sepearte row in the acl table. It would support unlimited users and groups per item.
vinny errr... that should be "each owner and group"
vinny wonders if we're boring everyone else...
IA-Outdoors are you kidding me, this is the most talk in this room in weeks
IA-Outdoors I'm surprised dhaun hasn't piped in with suggestions
IA-Outdoors ...he may be afk, though
vinny Once we're done we should probably save this off and post it. It's good reference for what is going on with GL2 development (especially the earlier A&A talk)
IA-Outdoors hrm, you got a log?
IA-Outdoors not sure if my *censored*x session does
vinny I think I might be able to copy and paste.... *maybe*
vinny Yeah, I can copy and paste the out of here, it won't be pretty though, I might have to freshen it up a bit.
IA-Outdoors I'd email it to geeklog-develt o start
IA-Outdoors err, geeklog-devel
IA-Outdoors Then I can create Geeklog-2 topic on geeklog.net
vinny Do you want me to make up a sample database and some sample queries for the ACL structure I've been talking about?
vinny I could write up a nifty little white paper for that topic. :)
Comments (0)
Geeklog
http://www.geeklog.net/article.php/20030612150031585