Kentico 8.2 Media Library permissions - permissions

I have set up a user and assigned him to a role. While I am able to permit or deny access to different pages in the site, assigning access restrictions in Media Library -> Security seems to have no effect. Any idea what I'm missing?

You have to assign them to a role. Configure both 'Permissions' and 'UI personalization' like you can see in the screenshot below.
David

Please check to make sure you do not have any global or higher level permissions set on those users that would override your specific security settings. For instance is a user was set to a role but also has Global Admin rights, the global admin would override all the permissions.
Also have you tested if the users can actually edit those libraries? (add, edit, remove items) or can they just see the media items in there?

I had a similar issue. Disabling the "Manage" permission while leaving "Read" enabled via the Role's Permissions -> Media libraries (Module) resolved it. See my response here: https://devnet.kentico.com/questions/limit-access-to-media-libraries

Related

How to define Watches in Artifactory for LDAP Users

Artifactory allows to set Watches on specific repositories to get notification when changes happen.
When you define an internal user, this works properly.
For LDAP Users, there is no option to set a watch on a repository.
Are special settings needed to enable this feature for LDAP Users or is it imposible without any workarounds?
Thanks a lot!
The issue you are describing is not related to the LDAP users but due to one of the below options:
You are not creating the LDAP users locally on Artifactory, meaning that you are validating the user vs the LDAP server on the fly and not creating the user on Artifactory. If this is the case then the reason for you not to be able to set a watcher is that from Artifactory perspective it doesn't have a user with details (email as an example).
If #1 is not the case and you do create the LDAP users (automatically or not ) in Artifactory then check if those users have email defined upon creation in Artifactory.

Manage permissions for quintagroup seoptimizer

I have added the SEOptimizer add-on to my site, and need to restrict who can access the SEO tab. I'm not sure how to manage permissions for this.
Default add-on permission use the "Modify portal content" permission, so users able to edit the content will see the tab: https://github.com/quintagroup/quintagroup.seoptimizer/blob/5d0ee147f2b094ea8a05849f1d77161a8329bb44/quintagroup/seoptimizer/profiles/default/actions.xml#L14
You can change this behavior by changing the permission related to this action and the permission in the ZCML: https://github.com/quintagroup/quintagroup.seoptimizer/blob/f55624284a7daa6c225801990e6b2e9801b9eeac/quintagroup/seoptimizer/browser/configure.zcml#L95
Change the permission used by the action is simple (you can do it also TTW accessing ZMI and portal_action tool).
Changing the ZCML permission needs a registration of a new ZCML that will override the old registration: See http://docs.plone.org/develop/addons/components/zcml.html#overrides
You probably need to register a new permission, to be given to your "SEO" role.
BTW: this can be a really good change for the original product too: think about open an issue.

How to set Authentication in apache bloodhound?

I've just installed Apache Bloodhound in my server. It's working fine. But with the default settings, anyone can view the list of tickets. I want to change this so that only logged in users are able to view the tickets.
Is it possible? How can I do this?
Default Trac ticket permissions are TICKET_VIEW for 'anonymous' sessions (everyone) and editing for 'authenticated' users, yes.
You'll want to remove TICKET_VIEW, so only authenticated users will see (and modify) tickets. To accomplish that, any user with PERMISSION_REVOKE (inherited by TRAC_ADMIN and PERMISSION_ADMIN as well) is allowed to navigate to the permission web admin page, can check and submit the 'remove' action. Alternatively you could use the trac-admin command:
trac-admin <path_to_trac_env> permission remove anonymous TICKET_VIEW
where you need to replace the path with you real one, like /var/www/trac_env/myTrac.

Creating permissions with laravel authorty

I want to integerate Laravel Authority bundle in my laravel application.
How can i implement ACL for it?
My approach is like every controller will define permissions associated with the controller. Then I will map those permissions with roles. The Authority initialization will load the permissions available for the session user and pass them to authority. Permissions can be later on checked normally with Authority::can().
Now my question is how can I load all the permissions available in the controllers at some page which will allow me to set permissions to roles.
Is it the right way to define permissions?
Please help.
As noted in the comments bundles do not work with laravel 4 but Matt Machugas Authority package for laravel-4 seems to suit your needs exactly. It allows you create roles with certain prividleges and then add individual permissions to on top or instead of those roles if you want, I find it very easy to use.

Can we isolate a user from the mod_authz authentication?

Can we isolate a subversion user using the mod_authz authentication such that they will only be authenticated to a single subversion repository? Right now we are hosting multiple repositories via apache, and our access_file is global across all repositories. This means if we use the *=r option, then all users will have read access. We would like to introduce a user into that environment so they will only have access to a single repo, and they will not be included in other repository access via the *=r option. Is this type of configuration available?
Thanks,
Suresh
You can use the NOT modifier on global scope of the authz file:
[/]
*=
~single_repo_user=r
[single_repo:/]
*=
single_repo_user=r
This reads:
for all repositories, nobody has any permission, except he is not user named single_repo_user, than user has read permission
for repository "single_repo" nobody has access except single_repo_user who has read access
So only single_user_repo has no permission. everybody else has read permission.
You can of course just delete the user name out of the htpasswd file..
See more infos here:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz