[00:00] In this video we'll discuss some of the ways we can restrict access to individual components in Perspective. Like all other forms of Perspective security, component security is managed using identity providers and security levels. So, to get us started here, we have a view that I created, and on this view, I have a very important button that does very scary things. My goal is that when a user opens up this view, they'll only be able to click that button if they belong to a given subset of security levels on my gateway. Now, the way that we restrict access to components in Perspective is by manipulating one or more of the properties of the components. For example, many components, this button included, have an 'enabled' property. Here, I've set 'enabled' to 'false', and that means that if I go into 'preview' mode, my button cannot be pressed, and it shows a nice little cursor indicating as such. Many of our Perspective 'input' components will have this enabled property. In addition, at the very bottom here, under 'META', we do have a 'visible' property. If I set that to false, the component will go away. All Perspective components will have a 'visible' property available for us to use, and all it really does it prevent the component from being drawn at all. And then, finally, in this case, we have a 'display' property under 'POSITION'. This one we're seeing because we're using a flex container. See, if I just set the component to be invisible, there's still this empty space left behind in the view. But, if I set 'display' to 'false', now the flex container is effectively behaving as if the button doesn't exist at all. So, just a useful distinction to keep in mind when working with flex containers in particular. I'll go ahead and set 'display' back to 'true'. And I think the one I'd ultimately like to use for this example is the 'enabled' property, the one we discussed first. Now, it's of course not enough to just set 'enabled' to 'false', because we do want some users to be able to use the component. So, instead what we're going to be doing is binding that 'enabled' property to an expression. But, before we do that, let's take a quick look at the security levels on this gateway. So, I'm going to come to 'project properties' here, and then to 'perspective permissions'. And, again, these are just the security levels on this gateway, so if I expand 'authenticated', I'll say that you can press my very important button if you have the 'administrator' security level, or if you have the 'operator' role. I think that'll be good. But, if we wanted to, we could use any combination of the security levels in here, including the security zones. So, I'll go ahead and cancel out of this, and now, I'm ready to set up my binding. So, I'll find that 'enabled' property in the properties listing, and then click that chain link icon on the left. And, then, the binding type that I'll use here is 'expression'. So, I'll make my box just a little bit bigger. And I'll make the text a little bit bigger, too. And, in here, I'm going to be writing an expression that evaluates to either 'true' or 'false' based on whether the currently logged in user has the appropriate security levels. So, to do that, we are going to be taking advantage of a special expression function. So, I'm going to find that 'sigma' icon there, and then I'll find 'users', and then the function we'll be using here is 'isAuthorized'. It's important to keep in mind that the 'hasRole' expression function here will not work in Perspective, because Perspective does not use roles directly; it uses security levels. That's why we need the 'isAuthorized' expression function. So, with that function selected, there are a couple parameters that we have to pass. Effectively, the way that this function works is that we're passing in a whole bunch of security levels, and we have to decided whether the user matches all of them, or at least one. So, I'm going to start off my function call by saying 'false', 'comma'. And, what this 'false' is doing is it's saying that only one of the security levels that I specify has to be matched by the user. If I had said true, then all of the security levels must be matched. So, next, I'll start typing in my security levels. So, my first one is going to be, in quotes, "Authenticated", "slash", "Administrators". Important to keep in mind here, we're passing in the entire path to the security level, not just the name of the security level. So, I say "Authenticated/Administrators". So, next, I'll say "comma", and then, in quotes again, "Authenticated" "slash" "Roles" "slash" "Operator". So, this time we're matching the 'operator' level listed under the 'roles' security level. And I'll close that off with a close parenthesis. So, again, this expression will evaluate to 'true' if the currently logged in user has at least one of the two security levels I have typed out. If they have neither, the expression will evaluate to 'false', and the user not be able to click on my very important button. So, we're ready to see this in action. So, I'll go ahead and click 'OK', and then, I'll go ahead and save my project, and then, I'll go ahead and launch a session. So, I'll come to 'tools', 'launch perspective', 'launch session'. So, here, we're being prompted to sign in to our IDP, and I'll sign in as a user that I know has that 'administrator' security level. And there we go, I'm now signed in, and my button is available to me, I can click it. So, now, how about I sign in as a different user that does not have that security level. So, I'll come here, and then say 'sign out'. And, this time, I'll sign in as a guest user that has no special permissions to speak of. And, this time, we can see that our button is disabled, and cannot be clicked. So, this is just one of many of the applications of the 'isAuthorized' expression function. It can be used to allow or restrict access to many different parts of a Perspective session, and there is also a system.perspective.isAuthorized scripting function available for use across the Perspective platform as well.