Re: Proper way to do permission checks
On 02/23/2013 04:45 PM, JoelJ wrote: private boolean userHasPermission(Permission permission) { ACL acl = Jenkins.getInstance().getACL(); return acl.hasPermission(Jenkins.getAuthentication(), permission); } Too much work. Usually you would just use something like: someBuild.checkPermission(Run.DELETE); and proceed, since this will throw an exception if the permission is not granted. Permission.READ Do you mean Jenkins.READ? -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proper way to do permission checks
Nope, I was using Permission.READ public static final Permission READ = new Permission(GROUP,GenericRead,null,HUDSON_ADMINISTER); Also, in this case I want the boolean value since I display different elements on the page depending on permission (don't show the delete button if they can't delete. Don't show the form if they don't have permission to write). However, that's good to know. I'll try using the Jenkins.READ/etc constants rather than the Permission class's. Thanks, -Joel On Monday, February 25, 2013 8:59:56 AM UTC-7, Jesse Glick wrote: On 02/23/2013 04:45 PM, JoelJ wrote: private boolean userHasPermission(Permission permission) { ACL acl = Jenkins.getInstance().getACL(); return acl.hasPermission(Jenkins.getAuthentication(), permission); } Too much work. Usually you would just use something like: someBuild.checkPermission(Run.DELETE); and proceed, since this will throw an exception if the permission is not granted. Permission.READ Do you mean Jenkins.READ? -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proper way to do permission checks
On 02/25/2013 11:32 AM, JoelJ wrote: I display different elements on the page depending on permission (don't show the delete button if they can't delete. Don't show the form if they don't have permission to write) l:permission -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proper way to do permission checks
On 02/25/2013 01:02 PM, Jesse Glick wrote: l:permission Sorry, I meant l:hasPermission. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Proper way to do permission checks
After searching around on Google and asking in IRC (it's saturday, I wasn't really expecting much activity ;) ), I've decided I should ask here. What's the proper way to check if a user has permissions to do something? Here's what I have: if(currentUser.hasPermission(Permission.DELETE)) { //procede with delete } So on my test Jenkins instance I set up Matrix security and a readonly user. Here's what it looks like: https://lh3.googleusercontent.com/-yap_H49l5ko/USkzxcn4CSI/CUM/zHJJvjz9kGE/s1600/Screen+Shot+2013-02-23+at+2.24.36+PM.png However, the above check always returns true. In fact, with a debugger I tried every different Permission and it always returns true. I'm writing a plugin that allows users to upload files to Jenkins and if you have access to delete, you see a little Delete button, but I obviously don't want just anyone to do that. It seems like I'm completely missing something here. Any ideas? Thanks, -Joel -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proper way to do permission checks
Ok, I found this (https://wiki.jenkins-ci.org/display/JENKINS/Making+your+plugin+behave+in+secured+Jenkins) right after I posted here (naturally). So I changed my check to look like this: private boolean userHasPermission(Permission permission) { ACL acl = Jenkins.getInstance().getACL(); return acl.hasPermission(Jenkins.getAuthentication(), permission); } Now I have the opposite problem: When logged in as the Readonly user, and I pass Permission.READ into that method, it returns false. However, the Admin user has access as expected. Any ideas? On Saturday, February 23, 2013 2:29:04 PM UTC-7, JoelJ wrote: After searching around on Google and asking in IRC (it's saturday, I wasn't really expecting much activity ;) ), I've decided I should ask here. What's the proper way to check if a user has permissions to do something? Here's what I have: if(currentUser.hasPermission(Permission.DELETE)) { //procede with delete } So on my test Jenkins instance I set up Matrix security and a readonly user. Here's what it looks like: https://lh3.googleusercontent.com/-yap_H49l5ko/USkzxcn4CSI/CUM/zHJJvjz9kGE/s1600/Screen+Shot+2013-02-23+at+2.24.36+PM.png However, the above check always returns true. In fact, with a debugger I tried every different Permission and it always returns true. I'm writing a plugin that allows users to upload files to Jenkins and if you have access to delete, you see a little Delete button, but I obviously don't want just anyone to do that. It seems like I'm completely missing something here. Any ideas? Thanks, -Joel -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.