Is there any way to restrict access to a specific field on an item in Sitecore? We have a setup where an anonymous, non-authenticated user should be allowed to read one field ("FreeContent") and any authenticated user should see another field ("FullContent"). Setting Field Read / Item Read to deny in the template editor does not work, I'm guessing because the security then applies to that portion ("the field") of the template, not the content item itself.
We could, of course check if the user is authenticated and set the Field property of the control to "FreeContent" but we'd really like to be able to control from Sitecore which fields are open to all and which are not.
Is it possible at all, or do I need to implement this myself?
You were doing it right - Field read/write settings on the data template is how to set access to specific fields in items.
See p14.
You might need to republish the site and clear caches etc.
Otherwise check with the access viewer to make sure your various roles have correct access.
Related
I have an item with a certain template field. When a non-admin user login in the filed should remain read-only. But the same field in the item should be editable for users with a specific role. Please help me with this. I am stuck with this for more than 2 days.
In Sitecore below the Templates item where the field is defined, you can give
Field Write
rights on the Field item, deny right for roles you want read-only. but remember deny rights have more priority over access right.
See the the inheritance access right for creating an inheritance structure to explicitly give write access to each field by the roles.
Django 1.11.2
django-registration-redux==1.6
I'm building an intranet website. And I'd like to control myself whether users are active or not. In Django admin there is such a possibility. But "Active" attribute is set to True automatically when a newly registered user confirms his/her email.
In other words what I'd like to do:
1) Let users register and reset passwords.
2) Admin of the site assigns the new user to a group. Users with the minimum permissions can only view. Special permissions allow edit, delete etc. But the user must be unable even to view anything without approval by the admin.
Now I'm planning to organize can_view permission for every model. The two above conditions will be performed by assigning the user to a group.
Well, this seems to be rather cumbersome. That "Active" attribute in admin is much more elegant. But "Active" is automatically set to True when the user confirms his/her email.
Could you give me a piece of advice here?
While it's tempting, never use is_active to deny permissions. The flag is meant to be equivalent to "deleting a user". That also means the user cannot login (with default authentication backend). So it's not an authorization guard, but an authentication guard.
That said, if you don't grant permissions, users don't have them. So if you implement can_view and set it to guard the relevant models and views, then the user can log in, but cannot see anything you don't want them to (it's convenient for a user to see that she successfully logged in though :) ).
Follow-up question from comments
It's fine to use one global permission that is checked per view. When using class based views, I recommend extending LoginRequiredMixin, tuck a few other goodies in a IntranetCommonMixin and have each view combine it with one of the generic base views. See also my answer here.
The only reason you don't want to do it, is that it's tough to code exceptions on the rule, because the first "object" that says "yes", wins.
What I would like to do is to set view permissions of certain parts of the site depending on the user (that is easy using permissions and guardian).
I have a set of buttons across the top of the page. For one or two buttons I want to set permissions for only a few users or groups to be able to see that button. That part is fine (using guardian).
Each button is related to a model instance. The model has a view_button permission. Is there a way to have the view_button permission be default to True if the permissions is empty? Or, is there a way of saying has_perm be True for all users?
Maybe I could just create a static method within the model that does that check for me. Is there a better way to do it?
So as of right now I just have a page that I use locally to change objects. How can I go about creating a page that is only visible to the admin user. Using roles you can restrict access to certain objects but Im not sure the best way to include a page in your application that is only visible to certain users. Thanks for any help
Create an AccessRole (or similar) class that you can use for this, then show or hide the link/button (from menu or whatever) to open that page. Users who are not members of the Admin role does not see the button/link/menu option.
In the AccessRole class, you have a "users" column where you store an array of users that are members of the role, and a "name" column for the role name (Admin, Editor, Reader etc).
When your application starts, you check if the user is a member of the Admin role (which should be temporarily stored locally).
I have created a custom user profile in Sitecore 6.4.1, and am trying to add a basic droplist to the users profile. It seems that no matter which type of field I add to the user profile, it renders out in the Edit User dialog as a plain text field. Is there a restriction to the user profile, or some other method I need to use to allow content editors to pick an item to associate with a user profile?
The user manager cannot properly render all fields types. You should stick to single line text values if possible and avoid the user manager interface to edit the info itself. Use it more as a custom data store.
Edit: for reference, I've used this feature and extended profiles with simple fields for a login-based system with Sitecore. Our site allows users to register an account, which creates extranet users with an "extended profile" in the Core DB. When these users access thier profile page on the front-end site when they're logged into the front-end, they can edit basic data, like name, address, etc. I store these basic data points in the custom profile SLT fields, so its used merely as a data store. No one actually edits the content from the Sitecore shell's user manager.