[00:00] In this lesson, we'll take a look at some ways to restrict Perspective component access. I have my designer open and I'm currently looking at a view I've created that contains a super important button that does some potentially scary things. I wanna ensure that not just anyone can use this button. The way to do this in Perspective is to manipulate one or more of the components properties. For example, many components will have an enabled property. If I set this property to false and go into my preview mode, I'll find that the button can't be pressed and it even changes the cursor to indicate that. You can find this enabled property on many of the input components in Perspective. Next, all Perspective components will have a visible property, which can be found in the meta section. Setting this to false will prevent the component from being drawn. If I toggle it, you'll see it disappear and then reappear. So if it doesn't get drawn, that's one way of preventing someone from clicking it and using it. There's one more property that's somewhat similar to visible, and that's the display property under position. This one's showing up because I'm using a flex container.

[01:06] If I go back and toggle the visible property, the component becomes invisible, but there's an empty space where it used to be. By comparison, If I set display to false, the component disappears, but there isn't an empty space anymore and it's as if the component doesn't exist. Something to keep in mind when you're using flex containers while designing a project. Now that we've covered the relevant component properties, let's see how we can utilize these and dynamically restrict access based on user permissions. Perspective security is managed through identity providers and security levels, which are configured in the gateway webpage. I'll take a look at my security levels by opening up the project properties and going to the Perspective Permissions window. I'll expand the levels so I can see the roles that I've configured. I wanna set up the restrictions on my button so that a user either has the administrators security level or the operator role. So seeing the path to these levels is going to come in handy. I'll close out of this window and go back to my view to implement one of the restrictions on my button. I want the buttons enabled property to change depending on the user's security levels, so the way I can do that is with a binding.

[02:08] Then I'll need to make this an expression binding. I'm going to need to use a specific expression function to help me in this scenario, and I can access the functions by clicking the sigma icon and going to the User section. The function I need is isAuthorized. Make sure to use this one and not the hasRole function as that one is for roles and user sources, which aren't used in Perspective. The first parameter of this function is a boolean, isAll, which you set the true if you want the user to have all of the given security levels, or you set to false, if the user must have at least one. I'll set this to false. Next, I can add any number of securityLevel parameters, which are string paths to security level nodes. I'll bring up the permissions page we looked at earlier to see how to build my paths. The first security level I want is Administrators. The path to that starts with the Authenticated node, and then I'll add a forward slash, and then Administrators is on the next level. The next one I want is the Operator role, and the path for that will be Authenticated slash Roles slash Operator.

[03:09] That's all I need for my expression, so I'll add the closing parentheses and click OK. Then I'll save my changes in the project. Now I can test out the functionality to make sure it works by launching a Perspective session. I'll start by logging in as a user that has administrator access. This user is able to use the button just like I want. Next, I'll switch to another user, which doesn't have either of the security levels I defined in the expression, and now the button is disabled.