By Bill Cunnien - 2/4/2008
All I want to do is simply make something invisible...a navigation group on a DevExpress Navigation Bar Control. Here is my attempt after setting up roles and permissions, then DDT to deploy:if (SecurityBasics.CurrentUser.GetPermission("SystemMaintenance").Action == PermissionAction.Grant)
{
AdminNavBarGroup.Visible = true;
}
else
{
AdminNavBarGroup.Visible = false;
}I have a role called "Administration". A permission key was created for a category called Administration (not technically related). The key is use above and it is called "SystemMaintenance". The key is given grant rights for the "Administration" role. I removed myself from that role to test. The only thing that may be gumming up the works is the fact that my profile is marked as an administrator. Does the administrator bypass any and all permission sets? What would be nice is SecurityBasics.CurrentUser.IsInRole("Administration"). It would simply return a boolean value. It look like I have to create a dictionary list then walk the list to see if the user is in the role or not. Is that right? Thanks for your help,
Bill
|
By Greg McGuffey - 2/4/2008
If I understand you, you are logged in as a user that is a SF administrator (either the admin user setup in the initialize method in AppMain or a user who is marked as an administrator) and that user doesn't have some desired permission, yet is always passing this test?
This is correct. Users with SF admin status are automatically granted access to all permissions. The permission isn't even checked if they are an admin, it just returns true.
Sounds like a nice request (IsInRole), but I wonder about complications, such as what if the user has Deny on that role, vs. Grant? You might be better off to just check if the user is an admin:
if (SecurityBasics.CurrentUser.GetPermission("SystemMaintenance").Action == PermissionAction.Grant && !SecurityBasics.CurrentUser.IsAdministator)
{
AdminNavBarGroup.Visible = true;
}
else
{
AdminNavBarGroup.Visible = false;
}
|
By Bill Cunnien - 2/4/2008
Sooooo...my code above works, just not for those lively admins. The response will always be true for them. Got it. I'll see if I can test this elsewhere to determine accessibility.Thanks!
Bill
|
By Bill Cunnien - 2/4/2008
Nope. The code failed. The non-admin user was still able to access the group. Not good. How do I simply check if a user is in a specific role or not? Maybe that is the better question. I really don't see that in the docs.Thanks,
Bill
|
By Greg McGuffey - 2/4/2008
The code you posted should enable the AdminNavBarGroup when the user has Grant action for the SystemMaintenance permission. If it isn't then something else is going on. The first thing I'd do is put a break point on the if statement and make sure I know who the user is and if they have that permission, using the watch window. The next thing I'd do is make sure that the AdminNavBarGroup.Visible property is set correctly. This will tell you if you do in fact have the user setup correctly, e.g. a user without the SystemMaintenance permission set to something other than Grant. If your user is setup such that they don't have that permission assigned at all, then check out the InitApplication shared application event handler in AppMain (or whatever the C# equivalent is) and make sure that the SecurityBasics.DefaultPermissionInfo and DefaultPermissionAction are set to Deny. This is used when a user doesn't have the permission explicitly defined.
If the permission is fine and the visible is getting set correctly, then the next step is to figure out what else might be messing with the Visible property. Some other code that is putting back to visible.
These ideas come to mind because...well...I've done them before. 
|
By Bill Cunnien - 2/4/2008
Thanks a bunch, Greg! I'll work through these debugging tips tomorrow afternoon when I get back to the office. Talk to you then!Bill
|
By Trent L. Taylor - 2/5/2008
Good answers, Greg. 
|
By Bill Cunnien - 2/5/2008
Greg McGuffey (02/04/2008)
...make sure that the SecurityBasics.DefaultPermissionInfo and DefaultPermissionAction are set to Deny.The Action on DefaultPermissionInfo is Read-Only. I cannot set that in the InitApplication method of program.cs. Do you have syntax handy to show me how to set this? Thanks!
Bill
|
By Trent L. Taylor - 2/5/2008
Set it on the SecurityBasics shared property:MicroFour.StrataFrame.Security.SecurityBasics.DefaultPermissionInfo = New MicroFour.StrataFrame.Security.PermissionInfo(MicroFour.StrataFrame.Security.PermissionAction.Grant) |
By Bill Cunnien - 2/5/2008
Yup. That seems to work. I am getting ready to test the change, now. Should know something soon.
|
By Bill Cunnien - 2/5/2008
Well, if I do this:SecurityBasics .DefaultPermissionInfo = new PermissionInfo(PermissionAction.Grant);Then, I have to specifically deny people access to everything they should not have access to (the taking-away-the-keys-to-the-kingdom approach). I see more why Greg suggested deny as the default (the don't-let-them-have-the-keys-at-all approach). This will take a bit of time to setup. I see why you suggest waiting until the end of the development process; however, I may have been better served to consider some of this stuff up-front. Thanks for your help, gents!
Bill
|
By Trent L. Taylor - 2/5/2008
You got it...this is the same approach that we take and we have good roles and data setup so that our customers can implement their desired security permissions easily. But it is definitely best NOT to grant by default.
|
By Greg McGuffey - 2/6/2008
Any time Bill. It takes a while to really understand RBS, as it is pretty complex/full featured. It rocks though! 
|