I’m having some issues with FC security in FC7. Before I create a bug in the issue tracker, I just want to make sure that it isn’t user error.
First, I create a new group and role. In the role I give limited permissions to edit a single page in the site tree):
Under “Site Permissions”, I give access to a buried item (just one)
Under Webtop Visibility" I select “Site”, then un-select everything but “Site Navigation”
Under “Content Type Security”, I activate all checkboxes for dmHTML and dmNavigation
Under “General Permissions”, I activate ObjectEditTab, ObjectOverviewTab (note: This should be activated by default or the user gets errors).
Under Webskin I use an asterisk (I also think this should be the default value)
I edit the user, assign them to the group/role, and set their default site tree to go to the nested item in the tree.
Problems:
The default site tree item I selected above doesn’t work (just shows me the whole tree and does not bring me to the selected item).
When the user logs in and tries to change their password, they receive a CF error. I’ve temporarily fixed this by editing core/webtop/index.cfm and on line 33 I add <cfif listGetAt(url.id, 1, ".") neq "dashboard"> (otherwise it forces url.sec to be the string “dashboard” which isn’t valid. It should be “site”).
But it gets worse (and this is where I’m wondering if it’s user error on my part or something).
I create another group/role where I want users to be able to manage content for a single custom type. I set all of the permissions (view, edit, etc), assign it to a user. Everything works perfectly. Now, I want to assign to a couple users both new roles I created (the one I described earlier with the site tree item and the new one with a single custom type). Things go very bad here. Now ALL types show as well as the site tree - including things like the site builder, etc. Neither role has permissions to view any of these items and if I assign just one role to a user it works. If I create an entirely new role and merge all of these desired settings (into just one role) and assign only that one group/role to a user, it works as expected.
If these security issues are too complicated to fix right now, just say so (it happens). I suppose I can start moving my clients back to FC 6.3 until all the security issues can be addressed in FC7 (it’s just way too buggy in 7 right now).
Assigning only * to webskin security is dangerous. Webskin security is the fundamental way of protecting against controller abuse.
A user that understands the URL convention the controller uses to execute views, and who is a member of a role with * as the webskin security entry could access any view on any object (including edit handlers). The app would then have to rely on project specific code in the edit handler to enforce security.
FarCry doesn’t enforce additional security on views beyond the webskin security layer (with few exceptions). For this reason we exclude access to views by default.
I also forgot to mention that whenever I check the checkbooks (I believe it was under “Content Type Security” I got an annoying alert box for every item I checked. It does not do this in p630.
That’s not a critical bug though like some of the others… it’s just very annoying and time consuming to get by.
Don’t remember which browser I was using at the time (I think it was Chrome). I just tested it now in Safari and got the alert. It says “Change unsuccessful. The page will be refreshed.” Then the modal window is refreshed and the change is saved successfully (even though the msg said it wouldn’t save). The version of p700 I am on is about a week or so behind.
