I'm working on a site for a school district's adult ed program. They are requiring no less than 4 different "access" areas with multiple levels of control. After a little research I'm expanding upon a roles based security model that I originally read about on the MM site (CFC best practices: Component functions and function invocation by Anthony McClure, http://www.macromedia.com/desdev/mx/coldfusion/articles/cfc_practices.html). A very basic outline is given, and the sample includes (ohboy) an Access db, but with fairly minor modification it can be put together into a viable roles based security model.
Cutter Gyrus wrote: >Hi all, > >I'm planning an MX revamp to our bespoke CMS, and I'm wondering about >restructuring the way "people" are handled, using CFC's. > >In my current system there are "users" who can login to the admin functions. >This works fine, most of the time. Only, when you get "clients" who have >login accounts to access a client-only area, I've often found myself having >to create "client accounts" for "users", so they can login to the >client-only area as well to see the content they're managing. > >(BTW, this is all based on having a frontend and a backend, two separate CF >applications. Obviously this issue would be ironed out if there's one site >that can be administered "from within" - something I'm planning on trying.) > >It gets more complex when it comes to having company "contacts" - some of >whom will be "users" - and maybe a more general category of "people" (one >site I've built associated content items with one or more "people", if >there's an article about a specific person, or if the item is a review of an >album, it links to the "people" table to specify the artists). > >I'm wondering whether I should just have one top-level "people" table / >"person.cfc" that models and manages absolutely any types of people in the >site. Then you'd maybe have subset tables / subtype CFC's like >"administrators", "users", "contacts", etc. In some cases there might be >another level, e.g. person > administrator > developer, depending on whether >"developer"s would need much extra information about them storing. > >I'm only starting out with CFC's, so I'm just wondering whether this is a >valid, effective way to start thinking about remodelling my CMS. Would I >just end up with too many table joins accessing all those subset tables? Or >would the fact that this will be done in CFC's reduce this problem by only >having any less-than-easy SQL joins in one central place? > >Any comments/thoughts welcome, > >Gyrus >[EMAIL PROTECTED] >work: http://www.tengai.co.uk >play: http://norlonto.net >PGP key available > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
