[00:00] In Ignition version 7.9.4, we introduced a new type of security called Client Permissions. These can be found by going up to the properties, and going to the permission section under "client". Here we have a list of actions that can be done from the client that interact with the gateway in some way. Because they can interact with the gateway, they can be seen as harmful to the security of your system. If the check box next to the action is not checked, then this permission is disabled. What this means is that a user will not be able to do this particular action within the client. So for example, the tag editing permission allows us to add, remove, and modify a tags when we're in the client. One of the most important things to understand about these permissions is that by default, all of them will be disabled in a new project. This means that when making a new project in Ignition 7.9.4, certain things that you're used to doing on a regular basis might not be allowed until you come into this window and enable the security permissions. However, the exception is that if you already have a project created on your gateway, and then you upgrade your gateway to Ignition 7.9.4, then all of these permissions will be enabled, to allow the full functionality that you have expected from your project before. You do however have the option to go back into these permissions and disable them for an old project if you would like. Now, in addition to enabling one of these actions, you can also set up required client roles here in the text field next to the action. Leaving the field blank will allow anyone to perform that specific action, or I can start entering in one of my user roles, and selecting it from the drop-down here. The user must have this role to be able to perform this action. In addition to listing user roles, I can also list a user role and pair it with a security zone using the syntax "user role name, at, and the security zone name." If I needed to, I can also select multiple user role and security zone combinations, by separating each one with a comma. This allows you to fine-tune exactly how this security in your client is going to work for these particular actions. Let's take a look at an example of how we might use the legacy data base access permission. The legacy data base access allows you to run standard SQL queries for both binding and scripting. While it's disabled, the only SQL queries that are allowed to run are those from transaction groups and those that use named queries. I'm going to leave it disabled for now, and go ahead and cancel out of here, and open up the window that I have created here. You'll notice I have a table here, and if I go down to the binding, on the data property, we'll see that it's using just a standard SQL query. Now even though legacy database access was disabled, it still works here in the designer, because those permissions only affect of the client, not the designer. This allows you to set the security properly and still work freely within the designer. If I close this and go over to my client, and I log into my client, you'll notice that when you take a look at the table, it'll have a red overlay. This lets us know that we don't have permission to actually run that type of SQL query. This is because with legacy database access disabled, nobody is allowed to use legacy database access of standard SQL query bindings from a client. However, if I were to go back into my designer, and go into the project properties again, and enable legacy database access, and then I need to save and publish my project, I can come back to my client, and update it, and you'll notice that now the SQL query binding works as intended. These client permissions allow you to finely tune what actions users can do from the client that affect the gateway, giving you more control over the security of your system.