# Security on User Actions (e.g. Buttons) in Perspective

**URL:** <https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204>\
**Category:** Ignition\
**Tags:** ignition81, perspective\
**Created:** [November 21, 2023, 3:32pm UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204 "2023-11-21T15:32:41Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peter\_G](https://avatars.discourse-cdn.com/v4/letter/p/c67d28/32.png) [@Peter\_G](https://forum.inductiveautomation.com/u/Peter_G)\
**Post date:** [November 21, 2023, 3:32pm UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204/1 "2023-11-21T15:32:41Z")

</div>

The Ignition Manual describes using Security Settings on a Script in the Event Actions, and using Component Bindings to Check Authorisation as two ways to restrict functionality to authorised users. Is there any difference in using these two methods? For us, it has been easy to use Component Bindings to disable a button, for instance, and then let the Button Style indicate this function is disabled. I'd be interested to hear if there are any drawbacks to this approach?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [November 21, 2023, 3:59pm UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204/2 "2023-11-21T15:59:40Z")

</div>

One is frontend, the other backend. Frontend security is subject to manipulation by developers (and hackers) with browser dev tools. But front-end security is visible and intuitive for your users.

Use _ **both** _.

---

<div class="post-metadata">

**Author:** ![Peter\_G](https://avatars.discourse-cdn.com/v4/letter/p/c67d28/32.png) [@Peter\_G](https://forum.inductiveautomation.com/u/Peter_G)\
**Post date:** [November 22, 2023, 8:55am UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204/3 "2023-11-22T08:55:10Z")

</div>

Thanks for that. Would I be right in thinking that backend security cannot be configured at runtime, e.g. where we use a faceplate to control a motor but need to provide permissions based on the use case, any backend permissions would be fixed, however we can still adjust the frontend permissions via bindings?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [November 22, 2023, 12:58pm UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204/5 "2023-11-22T12:58:12Z")

</div>

Scripted backend security checks can be entirely dynamic.

---

<div class="post-metadata">

**Author:** ![Peter\_G](https://avatars.discourse-cdn.com/v4/letter/p/c67d28/32.png) [@Peter\_G](https://forum.inductiveautomation.com/u/Peter_G)\
**Post date:** [November 22, 2023, 1:34pm UTC](https://forum.inductiveautomation.com/t/security-on-user-actions-e-g-buttons-in-perspective/82204/6 "2023-11-22T13:34:43Z")

</div>

Got it. I was looking at the Event Security Settings, which appear to be set and forget.

Thanks @Anna_Smith and @pturmel.