[00:00] In this lesson we'll be taking a look at restricting access to individual components and windows in the Vision Module based on user roles. Vision gives us a handy interface for configuring this kind of security. So to see what I mean I've built a little testing interface here, and in this interface I've added four buttons that all just say Click me. On each button I'm going to be configuring a different kind of security restriction, and I'm going to be locking down the resource to specific users based on their role. Let's start with our first button. So I'm going to select my button, and then if I right-click on that button, I'm going to search down in this menu here until I find Security. So what that's done is it's opened up my Security interface on the left-hand side here, on top of where my Property Editor used to be. Now, I don't want just anyone to be able to click this button, and this interface gives us an easy way of configuring that. Currently I have this Inherit Permissions checkbox checked. What that means is that rather than using any of the security settings below, we'll simply defer our restrictions to those of the parent, which in this case is the root container of my window. But, if I uncheck that Inherit Permissions checkbox, now I can configure security restrictions for this component specifically. The way that this works is in the top half here I specify some number of restrictions I'd like to place on the component. I can choose between putting an action denied overlay over it, or I can simply disable the components, or I can hide it altogether. For now I'll leave this button's restrictions alone. Underneath that Restrictions box is an Exempt Roles box. This is where we configure which users should be able to circumvent the restrictions we've just placed. I don't want to disable my button for everyone, I want to make sure that administrators can still use my button. So I'm going to add Administrator as an exempt role here. So now if you're an administrator you'll be able to use the components, otherwise it will be disabled for you. One additional note, this disable events checkbox prevents any scripts on this button from firing. So if I had an actionPerformed event handler on this button it would not work. Let's play around with some of our other buttons here, now that I've configured this first one. So I'll click my second button here, and I left the Security panel up so it's already here where we left it. But now it's showing the security restrictions for my second button. So once more I'll uncheck Inherit Permissions, and this time, as per the notes that I've left above the button, I'm going to set my restrictions to Hide, and my exempt roles to Operator. So this will hide the button if you do not have the operator role. Next, I'll go ahead and click on my third button here, come back over to my Security panel, and uncheck Inherit Permissions, and then on this one, I'll put an Access Denied Overlay, and I'll put two exempt roles, both Administrator and Operator. What we're going to find when we test this out, is that the user only has to have one of these roles in order to access the button. So as long as the user is either an administrator or an operator, they'll be able to use the component just fine. Finally, I'll leave the fourth button alone, it'll be my control button, just to see what a standard button looks like. So now that I've set up some basic security restrictions on my buttons, I'm going to go ahead and save my project, and then let's go ahead and test this out in a client. So I'm going to go to Tools, Launch Project, and then Launch windowed. And I'll go ahead and drag over my client. And I'll start by logging in as an admin user. So I'll type admin, password. This is just a user that I've set up that has an administrator role. So for our first and third buttons nothing has happened because the administrator role is exempted, and that's a role that we currently have. For the fourth button nothing has happened because there are no restrictions on the button in the first place. But our second button is now invisible. Because I only exempted the operator role, this hide restriction is being enforced. It's worth noting that there is no hierarchy to our role structure in Vision. So even if it might seem that an administrator should be able to do everything that operators can do, you will have to give administrators the necessary permissions explicitly. So how about I sign out, and this time I'll log in as Bob. Bob is an operator. He does not have an administrator role but he does have that operator role. And this time when we look in here, the second, third, and fourth buttons are functioning normally because the operator role was explicitly granted, or there were no restrictions in the first place. But this time our first button is disabled. That means that I cannot click on the button, no matter how hard I try, and no events on that button will fire, since I do not have the administrator role. So finally I'll sign out again, and this time I'll sign in as guest who has no roles whatsoever. This time we'll be subject to all of the security restrictions in our window. Because we have no roles, the first button is disabled, just like it was for our operator. The second button is hidden, just like it was for our administrator. And the third button has an access denied overlay, which will restrict access to the component as well. One useful thing to note here, if you disable the component, or put an overlay on it, that will immediately let the user know that there is a resource present, but they don't have access to it, whereas using a hide restriction here, might keep a user from knowing about a feature at all, which might be problematic, if it's associated with a role they were supposed to have. So it's worth keeping that in mind, when you're designing security restrictions for your system. So now that we've played around a little bit with component restrictions, I'm going to go back into my Designer, and it's worth noting that different objects in Vision will have different available options in our Security interface. So I've been configuring security on components directly but if I select the dark gray background, that selects my window's Root Container, and we can see that that has security restrictions of its own. Finally, if I select the window itself in the Project Browser, so the security window in this case, I can even configure security on that. So we have this Do Not Open restriction. So if I wanted to, I could make it so only administrators could use this window. So effectively, this interface can be used for pretty much any object in Vision.