Hi guys,

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?

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...

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...

I'm disappointed that nobody from the development team has responded to this, especially regarding the security issue.

Onto another CMS i go...

Hi FrostySonic,

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

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.

Hey FrostySonic,

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

See http://open.silverstripe.com/ticket/2701#comment:4

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?

Great news!

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!