# Use custom session props to secure tags **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [February 4, 2025, 5:42pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854 "2025-02-04T17:42:38Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Nick\_H1](https://avatars.discourse-cdn.com/v4/letter/n/71e660/32.png) [@Nick\_H1](https://forum.inductiveautomation.com/u/Nick_H1)\ **Post date:** [February 4, 2025, 5:42pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/1 "2025-02-04T17:42:38Z")
self.session.custom.auth.isOperatorInCharge I have a custom session prop that is set to true when an operator signs in with an idp system and claims 1/2 operator seats available. A security level checks if they have the role as an operator in the organization. I have a with 2 seats. When the operator claims a seat, their username is in one of those seats. The username of the person signed into the page = 1 of the usernames on the tag, self.session.custom.auth.isOperatorInCharge is set to true. I would like to make it so that the tags can only be edited if this session props is true. Is there anyway to integrate custom session props into a security level? ---
**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:** [February 4, 2025, 6:05pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/2 "2025-02-04T18:05:54Z")
No. Security levels are established only on login and are constants thereafter. You probably want to use a location-based Security Zone in combination with your role-based level. ---
**Author:** ![Nick\_H1](https://avatars.discourse-cdn.com/v4/letter/n/71e660/32.png) [@Nick\_H1](https://forum.inductiveautomation.com/u/Nick_H1)\ **Post date:** [February 4, 2025, 7:27pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/3 "2025-02-04T19:27:18Z")
Copy. That was my fallback. I will do that + have the buttons enabled or disabled based off of the custom session prop. ---
**Author:** ![Nick\_H1](https://avatars.discourse-cdn.com/v4/letter/n/71e660/32.png) [@Nick\_H1](https://forum.inductiveautomation.com/u/Nick_H1)\ **Post date:** [February 4, 2025, 7:30pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/4 "2025-02-04T19:30:12Z")
Is there a property or easy way to enable / disable clicking on a screen. Instead of disabling all the buttons, it would be simpler if I could apply a “disable click” property on a screen and it would apply to all the embedded views. ---
**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:** [February 4, 2025, 7:35pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/5 "2025-02-04T19:35:57Z")
I'm not aware of any, no. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [February 4, 2025, 8:51pm UTC](https://forum.inductiveautomation.com/t/use-custom-session-props-to-secure-tags/101854/6 "2025-02-04T20:51:55Z")
Try to apply as much of the logic as possible to Security Levels, so that tag writes from the client may be rejected no matter how the request was initiated (accidental binding on button-enablement, etc.). Note that a Security Level Rule may reference the value of a tag (number of seats claimed)...might be worth exploring? As @pturmel mentioned, security levels are granted on login only. If this method is implemented, an otherwise-qualified operator would need to log in again in order to 'claim a seat' that was previously unavailable. If desired, an indicator stating that a seat is available should be easy enough to implement. If security level grants can be utilized, and tag security assigned appropriately, then a button's enablement can be bound to the `.CanWrite` property of the tag directly. A tooltip stating the reason why the button is disabled ("Insufficient Security Level", etc.) could be beneficial. If you are using several of these buttons throughout your project, an embedded view of a 'template button' with the tag path passed into the view might be worth pursuing.