http://mysecretbase.com/AMPro2_screenshots.cfm will get you to a view of the two admin screens. More stuff linked on the menu at left.
I have been buried under some pretty well-paying work for months so I haven't had a chance to redo the Flash movie, or the tutorials or all of the screen shots devoted to v1.x, which had a very basic interface which matched up wiith the product's $29.95 price. I needed something a lot more intuitive and v2 was the result. Been using it for some time, and its been available to reg users for quite awhile. I need 3-5 days of free time to rewrite the docs and the pretty stuff, but anyone who understands the v1.0setup can get up to speed on v2 pretty fast (I think/hope). -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com On 1/7/06, Baz <[EMAIL PROTECTED]> wrote: > > Hey Matt, > > Where can we take a look at this product? > > Cheers, > Baz > > > -----Original Message----- > From: Matt Robertson [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 07, 2006 12:18 PM > To: CF-Talk > Subject: Re: User, Permission Management > > disclaimer: I'm describing a commercial product I sell. > > I have users, permissions, groups and profiles. > > Anything you want can be assigned a permission. This could be a whole > template, a single snippet of code or perhaps a number of snippets spread > out amongst a variety of templates. Depending on how you apply them they > could also be anti-permissions. > > What I call groups are something I am probably going to phase out with a > recent upgrade I did to the system, and will only keep for legacy support. > They were basically intended to serve the same role as permissions, except > a > given resource could belong to any number of groups, and a user could > belong > to any number of groups. If there was one match between them the user was > granted permission to the resource. Since now I can have a single > resource > allow access to more than one permission this takes away a lot of the need > for 'groups'. > > A profile is a collection of permissions and group memberships that can be > applied in bulk to a user. The profile can then be customized > individually. > > The user has their groups and permissions stored in memory after login. > Resources either have their permissions hardcoded into the code (if > protecting at the snippet level) or pulled from a database record (if > building into something like page access for a cms). > > I wrap permission management in with application security in general. Its > not just the assiggnment of permissions you have to worry about, but the > circumvention of those permissions as well. cross-site scripting, SQL > injection, proper storage of the user password, hint and answer, secure > method of self-service password reset... I really prefer to drop in a > complete security/permission system in toto. The trouble is clients > always > want to dumb the thing down so they don't need strong passwords etc. > > > > On 1/7/06, Dawson, Michael <[EMAIL PROTECTED]> wrote: > > > > Maybe I'm a bit daft, but I never really understood the logic of using > > CFC roles. > > > > Let's say I use CFLOGIN and I assign a user to a "normal" role, but not > > to an "admin" role. > > > > Then, I have a function with the roles attribute set to "admin". > > > > When the user calls a page that uses the function, it's going to throw > > an exception. > > > > So, I then need to wrap it in a CFTRY/CFCATCH block and then determine > > what to do when the exception occurs. > > > > If the "normal" user is not allowed to call an "admin" function, why > > would I just not use application logic to determine what functions a > > user can actually call? > > > > I have never really understood this functionality of CF: > > > > <cftry> > > <cfset result = myAdminFunc()> > > <cfcatch type="any"> > > <cfset result = myNormalFunc()> > > </cfcatch> > > </cftry> > > > > When I could do: > > > > <cfif myUser.roles contains "admin"> > > do admin stuff here > > <cfelse> > > do normal stuff here > > </cfif> > > > > Am I missing the actual reason for CFC roles? > > > > M!ke > > > > -----Original Message----- > > From: James Holmes [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 07, 2006 6:18 AM > > To: CF-Talk > > Subject: Re: User, Permission Management > > > > I use CFLOGIN with CFC roles. This provides for the user/admin/etc > > scenario and generally suffices for most of our security needs. The > > authentication is done via LDAP and everything is secured via SSL. > > Security checking for each page is done with IsUserInRole(), which > > therefore works with memory. > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:228740 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
