Pretty self-explanatory I hope, but I have setup security zones but have no idea how to use them in my project for example to set certain controls on windows/views to read-only. I want to affect the enabled properties of individual components, I don’t want to set security on the tags themselves.
This topic is a duplicate of this (How to determine current Security Zone), but the answer doesn’t appear to be valid (and no-one is replying on that topic which is 4 years old:) )
Assuming you’re looking for a Perspective use, then Deon is correct; Security Zones should be applied to a Security Level, which you would then use in Perspective through either the expression already supplied or a transform which checks that a given security level name is in the list of security level names for the given user.
Ok, still an issue. You only get a Security Zone assigned when a user is logged in… I need to know in any auth state
Will have I have to use my dodgy session props again? Wait, no I can’t do that either, because the session.auth.host only gives me an ip address which for these clients isn’t fixed; I need to use the hostname…
New update.
I got back to this and tried with more time on my hands, and I got this working with my client’s IP address assigned in the Security Zone I created, but I couldn’t get it working for the hostname. I need to use hostnames… Is there any way to see what hostname Igntion is seeing for a connected client, as used by the security zones to apply them?
Also, can’t get a security zone for the gateway to apply at all, tried lots of different combinations: localhost, its IP, 127.0.0.1, its ipv6 address, fully qualified domain name… Nothing works
I know it has been a while since this was posted but I am trying to stop people who are not in a zone from accessing a perspective page. Does this script do that and where would it go? I have tried session and gateway startup scripts but it does not stop them. I am using IP ranges.
The expression Deon provided may not be used to derive permissions for a View because it is an expression which would be used as part of a binding. As @nminchin suggested, View security settings are the way to go if you don't want a View to be accessed outside of a certain Security Level (which is slightly different from a Security Zone).
How would you use zones to control access to an entire project. For instance if I have 4 areas in production and they all do different things but I don't want the areas to access anything but their own project. I have 46 plants which we are designating as zones for each based on IP ranges which are all unique. If you are in the plant the views will work but outside I want to control the users by the roles allowed for the viewing of the plant. Basically so the higher ups can monitor the production at each plant.
You're setting the PROJECT permissions. You need to right-click the individual View node you are setting restrictions on if you want to do the same thing at the View level.
Could I see how you defined your Supervisor Security Level? As was requested below, a verification of the Levels your user truly has would be helpful. The simplest explanation if you require a Security Level and are not given access is that you don't truly have the Security Level.
It would be useful to print the session prop holding the security props (e.g. session.props.security.roles and session.props.security.zones) to see what your user has been granted. I have a popup accessible from the navigation header that shows a bunch of the session props for diagnostics, such as these security props.
Okay, so you've made a Security Level - but who is it that you think has that Level? Inside the Identity Providers area of your Gateway's config panel, you need to either manually supply User Grants (map out what an individual User receives as Security Levels) or supply Security Level Rules (rules which apply a Security Level to anyone who meets some criteria).
In addition to Cody's reply, if Supervisor is in fact supposed to be a Role, then you need to add this into the Public/Authenticated/Roles instead of creating a new Security Level called "Supervisor". The Roles security levels are automatically granted using the roles configured in the user config. It's a little bit confusing at first when you set this up for the first time (or even the second time)
A new Security Level is useless and will never be granted to a user unless it has the rules/user grants configured
I am using the company IDP and do not have access to make changes but I can see the roles on the users in 'Manage Users' for that user source. I have code in the 'User List Filter' and 'Role Search Base' to weed out the users for each plant which is working and the roles show under the roles tab and on the users.