Jump to:

17452 Posts in 4473 Topics by 1971 members

Archive

SilverStripe Forums » Archive » Page security

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Page: 1 2
Go to End
Author Topic: 5601 Views
  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Page security Link to this post

    The next days I'll focus on the page security stuff. I'll implement it as follows:

    The "Access" tab will look at it does now:

    Who can view this page on my site?
    - Anyone
    - Logged-in users
    - Only these people (choose a group in the provided list)

    Who can edit this inside the CMS?
    Anyone who can log-in to the CMS
    Only these people (choose a group in the provided list)

    This works already, so what I'll add next is inheritance:

    Page A
    |-Page B (child of A)

    If view/edit of A is set to a specific group, page B requires also that group. If set to logged in users, B requires a logged in user or a specific group and if set to anyone page B can be restricted to logged in users or a specific group.

    Do you think it makes sense to implement something so that it is possible to select more than one group? Something like "This is visible only by" ... "the specified groups:" and then something like a list box where one can select the groups?

    What about creating two pseudo-groups, namely "Anyone" and "Authenticated Users"?

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: Page security Link to this post

    ++ Update ++

    I'll change the interface of the "Access" tab which currently looks as follows:

    to an interface like:

    Has someone a better idea how to label the two list boxes ("Available groups", "Selected groups")?

    See also this thread

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: Page security Link to this post

    This looks good. I would recommend implementing the group selector as a subclass of FormField that is designed to save to any many-many join. This is what we've done with TreeMultiselectField and CheckboxSetField and it makes the code nice really reusable. It will also mean that you could easily switch between the control you've presented and CSField / TMField.

    Saving to a many-many join is pretty straight forward: treat the form field name as the name of a method on the associated data object, and call setByIdList() on the ComponentSet that gets returned

    See this piece of CheckboxSet for a sample.

  • Tim
    Avatar
    Core Development Team
    201 Posts

    Re: Page security Link to this post

    Hi Markus

    Please see my note here re the interface for this - we are going to need to use the matrix style interface for this.

  • Whizzle
    Avatar
    7 Posts

    Re: Page security Link to this post

    One thing not sure if you've touched on this... Could you have an option to show only to Non-Logged in users.... This would be great for having a home page for Anonymous users and then one specific for logged in users...
    Also can you add the access tab to all items (Redirects, etc...) I know there are a couple that don't have it...

    BWT I'm a SS noob and this stuff rocks I have my site up and running and so far it's gone great!... Please keep it coming...

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: Page security Link to this post

    I’m currently implementing the new permissions system but I encounter a lot of problems

    The first one is that I’m really unsure if the permissions should be inherited in the way as described above? Just think of a website for a company that has different departments. All pages of a department are subpages of the department homepage. Normally only the department manager (or his secretary) should have the right to change the department homepage, but the subpages should be changeable for all employees in the department.

    So I think the best would be to inherit the permissions only on page creation - if at all.

    My next question is about how the permissions should work. I’ll create the permission “Edit page” and in the security tab you can then assign this right to the various groups. So what happens now on the access tab of a specific page? Let’s assume group A has the “Edit page” permission and group B not.

    Is A now allowed to edit all pages or just pages where I defined the Edit page permission with that specific page ID? Should it be possible to grant B the right to one specific page without the “global edit page” permission?

    And finally the last question is how I can implement Tim’s matrix style to display/edit the permissions (maybe a transposed version - which means groups as columns and permissions as rows).

    I played with MemberTableField but I had no success

    I wanted to create a component to which I can pass a parameter that specifies which permissions (and maybe with which labels) should be shown, so that for example the page access tab shows only “View this page” and “Edit this page” whereas the matrix in the security tab shows all permissions.

    Please look also into sapphire/security/Permission.php. Hayden created permission groups that allow the grouping of permissions so that they can be displayed quite nice.

  • Hayden
    Avatar
    Core Development Team
    19 Posts

    Re: Page security Link to this post

    The option to inherit page permissions is evaluated each time that the page is accessed, not just when it is created.

    When set to 'inherit', the page should instead evaluate the permissions of the current user against the settings of the parent page. You can always change this setting for child pages.

    To use the department homepage example: yes, the managers should be the only ones with permission to change the homepage, but you can still set other permissions on the child pages:

    Homepage: editable by managers, visible to all
    -Department: visible to department members
    --Department page 1: visible to department members
    ---Nested department page: visible to department managers

    In this case, the department page would have specific permissions, and department page would inherit from that. The nested page would then have different permissions.

  • Hayden
    Avatar
    Core Development Team
    19 Posts

    Re: Page security Link to this post

    The MemberTableField probably isn't the best way to go about it, as adding more columns as the number of groups increases might be a pain.

    You might need to create a FormField from scratch.

    5601 Views
Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.