Kentico Permissions - Page requiring authentication not considered a secure area - kentico

I'm setting up a secure area of a site and I'm curious about how Kentico (version 11) checks permissions. According to the documentation -
Check page permissions
Indicates if the website should check the user permission settings of pages and apply them.
The following values are possible:
All pages - permissions will be checked for all pages on the website.
No page - permissions will not be checked for any pages.
Secured areas - permissions will be checked only for pages that are configured to require authentication.
This seems to indicate that if a page is set to require authentication, the page permissions will be checked. However, if my site is set with Settings -> Security & Membership and set Check page permissions to Secured areas, members in Groups that don't have permissions are able to access the page.
If we edit the settings to Settings -> Security & Membership and set Check page permissions to All pages, the users are appropriately denied access.
We would prefer not to check page permissions on every page for performance reasons. I can create a control to check the permissions of the page but I was curious if there was some reason why setting the page to require authentication and checking permissions for secured areas doesn't work the way the documentation indicates it would.

I can guarantee you from a performance standpoint you won't notice a difference. If you want it to check permissions, you WILL NEED to have that site/global setting checked, there is no way around it.
If you have that global setting checked and it's denying access to everyone, then you don't have your permissions set properly at the root level. At the root level, there should be no permissions set. Then at your /members-only page, add the role "Authentiated users" and below that box, then check the Read box under the Allow column. This is the simplest setup for permissions you can have for a test case.

Related

In Liferay 7, How do I configure the User role to NOT inherit Guest permissions?

I am building a site on Liferay 7. By default, all the authenticated users inherit the Guest permissions (anonymous users).
There is even a label in the permissions section:
"Under the current configuration, all users automatically inherit permissions from the Guest role."
Why do I need this?
I would like to display X content only for anonymous users and when the user logs in, then I would like to display different content.
This is how my content permissions for anonymous users are configured:
Although I agree with people that say this is not the best path, yes you can do it - just to address the question at hands.
Set this to true if resources should assume that all users have the Guest role. Set this to false if resources will not assume that all users have the Guest role and, thus, do not automatically inherit permissions that belong to the Guest role.
Setting this property to false may require users to grant permissions to roles like Site Member and User.
Defaults:
permissions.check.guest.enabled=true
Why do I need this?
Permissions are not the catch-all for showing different content. If a guest is not allowed to see something, but needs to log in - that's fine. It's authenticated content, and you'll need to sign in.
If an authenticated user has no permission to see certain content, but just needs to log out in order to see it: What kind of permission is that? Let me answer that for you: It's not permission. It's rather targeted content and while it might be mimicked with permissions, this mimicry is nothing more than mimicry.
One way to implement such a requirement is through structured Web Content (you sound as if you want to show different Web Content articles). The template has access to the full API and can check if the current user is signed in or not - and show different content based on this fact.
If you want to achieve role permission using code level as like in xxxlocalserviceImpl class.You can use below code for allow permission for the guest user.
In case of document and media allow permission to guest and registerUser in Liferay 7 using rest webservice you can use this code for allow permission to upload and download the document using this code.
ResourcePermissionLocalServiceUtil.setResourcePermissions(companyId,
DLFileEntry.class.getName(), ResourceConstants.SCOPE_INDIVIDUAL,
String.valueOf(dlFileEntry.getFileEntryId()), guestRole.getRoleId(),
new String[] { ActionKeys.VIEW });
To answer your question - you can not configure that per specific asset! By default an authenticated user can not have less permissions than an unauthenticated one. You can change that behavior for all assets using permissions.check.guest.enabled=false as #Victor correctly pointed out!

Zope browser page permission

I have a browser:page setup in Zope, and I have:
permission="zope2.Public"
My question is what should I change this to in order to allow only Plone administrators access, and/or logged in (non-administrators) access to this page?
On Zope, you control access to views via permissions, but to permit someone to access a given permission, you must grant such permissions to a role.
Anyone in the Plone administrators group has been granted the Manager role (on Plone 4.2 that'll change to the SiteAdmin role) generally have access to most permissions. There is also the automatic Authenticated role, which is given to anyone that has been authenticated (has logged in). The latter doesn't have many default permissions though.
Permissions are generally named after the action you want to permit. If your view's goal is to manage some aspect of your Plone portal, then the cmf.ManagePortal permission is probably what you want. You can check the full list of default permissions if you need another one.
There is some excellent documentation on how security works in Plone, which includes information on how to define new permissions too, and how to assign existing permissions to roles.
permission="cmf.ManagePortal"
This setting is about permissions not about roles.

Enterprise Portal Web Parts not showing in Sharepoint for anonymous users

We have an enterprise portal site based on sharepoint, and we want to open it up for anonymous access.
However, dynamics ax web parts do not display when logging in as anonymous user, even though the Guest account has been set up, and correctly configured.
Other web parts (e.g. an image slideshow) appear correctly for anonymous users. Yet, the Quicklaunch web part doesn't work. The Guest account was given full admin access for testing purposes, and also shows as being Online when anonymous users are viewing the site.
No audience was set for any of the web parts.
Any ideas, please?
Are you sure your anonymous user has enough permission to use / get the desired rendering for the web part ? I don't know these "dynamics ax web parts" but the empty rendering might be the result of an exception (permissions) which prevent the webpart from being rendered properly.
Also, didn't you set any audience on the webpart(s) ? Check in the tool pane, at the bottom, if the webpart is not configured to be displayed to specific groups / audiences only.
Kindly.
Are they blank or do you get access denied? If blank, do you use security trimmed controls in your master page. If access denied, are you using a cache? If you do IISReset, and make sure that the anonymous user is the first to connect to the page, does the web part work? If you're using impersonation, and Guest doesn't have access to the file system, perhaps it cannot read from the cache directory.
Is the ViewFormPagesLockDown feature disabled?
The issue has been resolved, there was another setting we had overlooked.
We forgot to enable Anonymous access in Enterprise Portal.
Thanks for your answers.

Anonymous access to a SharePoint site root

I have configured anonymous access on a SharePoint site for "Lists and Libraries". I then enable anonymous access to the individual lists/libraries as per my requirements.
This works great, but I cannot access the root site URL where I expect to be redirected to the welcome page:
Access to http://servername fails with Access Denied
Access to http://servername/Pages/Default.aspx succeeds
If I set the web permissions to "Entire Web Site", I can access the root URL, but I don't want to do this.
I am provisioning my site with a site definition and modifying the site through the object model during feature activation e.g.
web.AnonymousPermMask64 = SPBasePermissions.Open;
web.AnonymousState = SPWeb.WebAnonymousState.Enabled;
web.Update();
... this is the code I'm already using with success.
Does anyone know how to allow anonymous access to http://servername?
It turns out you need to grant the following permission mask on the web object:
web.AnonymousState = SPWeb.WebAnonymousState.Enabled;
web.AnonymousPermMask64 = SPBasePermissions.Open | SPBasePermissions.ViewPages;
web.Update();
Simple really! Anonymous users can now navigate to http://servername and get redirected to the welcome page.
Note: the order of these two properties being set is important. Setting the AnonymousState property to Enabled, sets the permission mask to SPBasePermissions.Open only. This would remove the SPBasePermissions.ViewPages flag if you switched the order of the two properties as shown above.
You need to enable Anonymous access on the Pages library so that you have access to the default.aspx page.

What are the best practices for permissions on a publishing site within MOSS 2007 Standard?

Here's the scenareio:
I have a single site collection, with the publishing infrastucture feature activated. Seveal levels below this I have a publishing site with the publishing features turned on. I also have unique permissions for this site.
The problem is that no one except site collection administrators can "Create Page". I have given the individuals everything including full control, and they still can not create pages. They can edit pages, but not create.
Am I doing something wrong? What is the proper way to set up the taxonomy of a site? I am trying to create a hierarcy to match my organization and mostly am using unique permissions on each site/subsite. This is working ok, until i needed a publishing site, but I don't want him to be a site collection admin. I would appreciate any help or ideas with how to make the publishing site work as I have it, or guide me on the proper way to lay out the site.
The fact that you are using Publishing features shouldn't have an effect on permissions. Publishing (for the most part) really has more of an effect on how edits are handled - i.e. immediately deployed or checked in and published at a later point. That's oversimplifying it - but back to your question.
Most likely - what is happening is that you have not given the user permission to the library where the template is that they need access to in order to create the page. I'm 99% sure that is what is happening here. Makes sense - they have the rights to the site - and permissions to edit the pages that exist - but creating a page requires them to access a new file - in a different library. If they don't have permissions to that template library - you get the access denied error.
When your user tries to create a page, they get an access denied error page correct? Copy the URL of that page, and examine it closely. It should reveal the location of the template folder they are trying to access but don't have permissions for. Read-only access to that template library should get your user the access they need.
One other recommendation - check out the access checker web part in Codeplex. http://accesschecker.codeplex.com/. This web part is loaded as a solution and allows you to display a hierarchical list of the sites that a specific user has permissions to. VERY helpful in confirming that you have given the permissions you thought you had.
Finally - in terms of permissions best practices - I think you are doing fine. You've gotten a little frustrated because you took a different path on a site (i.e. publishing) and it's behaving differently. But nothing is wrong. I've been there:) You really have two options w/ SP permissions - SP based groups (visitors, members, owners etc) or pulling in AD groups. Either way, you'll be making the same decision regarding unique or inherited permissions. You either use the same permissions as the parent site - or use unique permissions. HTH

Resources