CODEWITHSUNDEEP
securitypermissionsorchardcmsorchardcms-1.8
Shaun Luttin
Shaun Luttin

Reputation: 141512

Create a secure Orchard CMS page that authenticated user can access but anonyomous users cannot

We just spent two hours accomplishing the above goal. The hard part was allowing anonymous users, on the front end, to view the Menu Widget but not to see nor to access the new Secure Page Content Type.

Our solution does work.

What we are wondering is, "is there a better way?" and "What's up with needing to set permissions both at the level of the content type and the widget instance for the menu widget?"

First we created a new Secure Page content type. Then we set the following permissions.

Users > Roles (View & Access Permissions)

                               Anonymous               Authenticated
View page by others               y y                       n y 
View own page                     y y                       n y 
View projection by others         y y                       n y 
View own projection               y y                       n y 
View secure page by others        n n                       n y 
View own secure page              n n                       n y 
View all content                  n n                       y y 
View own content                  n n                       n y 
View content types                n n                       n n 
Access site front end             y y                       y y

We revoked View all/own content for the anonymous role, and then explicitly re-granted View permission to this role for both pages and projections; we did not re-grant View permission for secure pages. Further, we kept the default settings for the authenticated role, because the defaults include View all/own content, include the new Secure Page content type that we created.

The problem at this point was that revoking View all/own content for the anonymous role meant that this role could not see the Menu Widget on the front end. To fix that we added the Content Permission part to the Menu Widget and adjusted the settings.

Content Definition > Menu Widget > Parts Content Permissions

                               Anonymous               Authenticated
View any content                  n y                       y n 
View own content                  n n                       y n

Oddly, this was not enough. At the content item level, we also had to set the following permissions:

Widget > Specific Menu Widget > Enable content item access control

Disable this (i.e. unchecked it)
Otherwise it overrides what we already set.

At this point, the solution works perfectly.

Two questions: Why did we need to set the permissions for the Menu Widget at both the Content Type level and the Widget instance level. Further, is there a more appropriate way to accomplish our ultimate goal?

Upvotes: 4

Views: 1369

Answers (1)

ViRuSTriNiTy
ViRuSTriNiTy

Reputation: 5155

Why did we need to set the permissions for the Menu Widget at both the Content Type level and the Widget instance level?

Because each module provides it's own set of permissions (in this case e.g. the Orchard.Widgets module).

Further, is there a more appropriate way to accomplish our ultimate goal?

I would go with a custom part where you can select user roles that can access the content. I had a similar task with validity checks here.

Upvotes: 1

Related Questions