17452 Posts in 4473 Topics by 1971 members
|Go to End|
24 June 2008 at 2:45pm
I'm looking at deploying Silverstripe for our company intranet, but one of the big things that I need it to do is to allow the different teams of our company to be able to edit and add their own pages without making any other site-wide changes.
Eg there would be a 'HR' tree of pages, and the 'HR' manager would be able to edit that page and everything under it, and add/remove pages under that tree.
I've had a quick play with a default install, and whilst it looks like you can set access privileges on pages using user groups, it doesn't look like you can set multiple groups as being able to edit a page/section, nor does it look like changes actually propagate or cascade down to child objects?
Is this right, or am i doing something wrong?
25 June 2008 at 11:04am Last edited: 25 June 2008 11:04am
Also it seems as though i've discovered a bug in the security settings for editing pages:
Say i have 'UserA', who belongs to a group 'SectionAEditors' which only has permission to login and edit a page with a tree of pages underneath it, 'SectionA'.
'SectionAEditors' can't edit anything else, including the home page. In order for user them to be able to login to edit their section, they have been granted the permission in the security section 'Access to CMSMain in CMS'.
If UserA logs in and clicks on the homepage (which they don't have access to edit), they can see the page but can't edit it, and the buttons at the bottom of the Content view (Delete, unplublish, Save, etc.) aren't there. That's all good.
However, if UserA first clicks on a page that he can edit, and then clicks on a page he can't edit, then the buttons down the bottom of the content view still show on the page he isn't supposed to edit, AND if he clicks on them they do actually perform their function (e.g. Unpublish or delete!)!
I have tested this in both Firefox 3.0 and IE7.
Can anyone else confirm this? It seems to be a pretty big security issue...
27 June 2008 at 11:45am
Please, anyone confirm?
How do I submit it as a bug?
To be honest, the security in this CMS seems to be a bit half baked...
30 June 2008 at 11:19am
I'm disappointed that nobody from the development team has responded to this, especially regarding the security issue.
Onto another CMS i go...
Core Development Team
30 July 2008 at 2:49pm
Sorry about not responding faster, I've created a bug report for the security issue you raised and marked it as a blocker for our next release, so it should be sorted by the time 2.2.3 rolls around at the very least. We may look at patching 2.2.2 as well.
The bug report can be seen here: http://open.silverstripe.com/ticket/2701
31 July 2008 at 1:59pm
Hi Matt, thanks for the reply, and I hope you guys can sort those issues out.
I was really excited at silverstripe when researching for our company's intranet.
I loved the simplicity of the interface, and was almost exactly what I was after.
Just for the record, the following issues were all deal-breakers for our needs:
- The security bugs mentioned previously
- The fact that access permissions were not applied down trees of pages.
- That you can't add multiple security groups to the Access settings of pages.
- That one single user can't belong to multiple security groups (not 100% sure on that one)
- The unfriendly URLs (to me non-hierarchical URLs are only slightly more useful as having the old page.php?pageid=1234)
There were lots of other minor issues from our point of view, but those above were the real deal-breakers. Are any of those issues really that unreasonable to expect?
If silverstripe could satisfy those, i'd be using it in our business and i'd be recommending it to everybody.
4 November 2008 at 4:07am
With a bit of delay, most of your concerns have been addressed in the current trunk, and should find their way into the upcoming 2.3 release:
> However, if UserA first clicks on a page that he can edit, and then clicks on a page he can't edit, then the buttons down the bottom of the content view still show on the page he isn't supposed to edit, AND if he clicks on them they do actually perform their function (e.g. Unpublish or delete!)!
Just tested, opening an editable page followed by opening a readonly page hides the buttons. The permissions should be enforced regardless on the controller now. Can you confirm?
> The fact that access permissions were not applied down trees of pages.
Theres a new option "Inherit from parent page", which is then used in SiteTree->canView() and canEdit().
> That you can't add multiple security groups to the Access settings of pages.
Fixed, its now a many_many relationship
> That one single user can't belong to multiple security groups (not 100% sure on that one)
Hm, that was possible since 2.0 afaict.
> The unfriendly URLs (to me non-hierarchical URLs are only slightly more useful as having the old page.php?pageid=1234)
Thats being addressed in a feature branch at the moment: http://open.silverstripe.com/browser/modules/sapphire/branches/nestedurls
I'm just working on a migration script which will transfer data from the legacy columns like the ViewersGroup has_one relationship to the new schema.
The changes are mostly unit tested, but we might have missed some assumptions and controller actions where permissions aren't fully enforced, so any manual testing and feedback is welcome! FrostySonic, any chance you find some time for this?
6 November 2008 at 4:28am
I just discovered yesterday that there was no way to specify more than one security group for a page, and also there was no inheritance from parent. Two very must-have features for my clients.
Can we really expect to find those feature into the 2.3 release by the end of the month (according to the roadmap) ?
Thanks for your excellent work!
|Go to Top|