# Keeping perspective components hidden in session issue

**URL:** <https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372>\
**Category:** Ignition Early Access\
**Tags:** ignition80, perspective\
**Created:** [June 5, 2020, 10:39pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372 "2020-06-05T22:39:40Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\
**Post date:** [June 5, 2020, 10:39pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/1 "2020-06-05T22:39:40Z")

</div>

I recently discovered that hiding components in the designer will still let people go into their browsers developer tools and unhide any objects i have hidden.

I’ve tried:

1. setting the components `meta.visible` property to `false`
2. setting the components `position.display` property to `false`,
3. setting both `meta.visible` and `position.display` properties to `false`
4. Setting the access modifiers on `meta.visible` and `position.display` to `protected` which according to the manual, should not let users change the property values (at least that’s my understanding of it).

Is there something i’m missing, or is this not possible? Ideally i’d prefer hidden items to not show up in the browser at all.

---

<div class="post-metadata">

**Author:** ![jespinmartin1](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jespinmartin1/32/57175_2.png) [@jespinmartin1](https://forum.inductiveautomation.com/u/jespinmartin1)\
**Post date:** [June 6, 2020, 3:17am UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/2 "2020-06-06T03:17:08Z")

</div>

Nice observation, In fact, I could replicate this and is a big problem for security:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/0/08869e9c22d8f65b0b41ae52cefd45bcf3f4b0d7.png)  
just deleting the hidden property turn it visible…  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/c/c6f78263e86ec191a52e3c42256761d45c4b3306.png)

But remember you have IDPs, security zones and levels. You can restrict your clients to only use mobile device with perspective app.

---

<div class="post-metadata">

**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\
**Post date:** [June 8, 2020, 2:36pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/3 "2020-06-08T14:36:40Z")

</div>

I thought so as well. Hopefully it’s an oversight or something easily fixable.

I can definitely work around the issue. Ideally i wanted to have a screen usable for authenticated / non-authenticated users and simply hide what i didn’t want the non-authenticated users to see but sadly that doesn’t seem like the case.

---

<div class="post-metadata">

**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\
**Post date:** [June 8, 2020, 2:44pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/4 "2020-06-08T14:44:44Z")

</div>

> [@Matthew.gaitan](#):
>
> Ideally i wanted to have a screen usable for authenticated / non-authenticated users and simply hide what i didn’t want the non-authenticated users to see

Havent tested this but what about if you use view security and embedded views? That way the "non-authenticated" users dont have access to the physical files and the embedded view would not be able to load? I am not sure thats a great solution if it is one or two buttons, but if its a whole page worth of information it may be helpful.

---

<div class="post-metadata">

**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\
**Post date:** [June 8, 2020, 3:25pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/5 "2020-06-08T15:25:30Z")

</div>

Yeah that seems like the only option which will require a lot of rework i was trying to avoid.

Would be awesome to have component level security without going the embedded view route

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [June 8, 2020, 3:33pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/6 "2020-06-08T15:33:39Z")

</div>

There are a few things going on here, so I’ll do my best to address everything.

1. If you place a component into a View, it will absolutely be present in the DOM; `visible` and `display` properties only apply to whether or not it can be visually seen - not whether or not it exists. If you want something to not EXIST unless conditions are met, your only option is to use an Embedded View which has a path set depending on some logical condition.
2. Setting the permissions to `protected` prevents the user from modifying that property’s value on the Gateway. It does not prevent a user from directly modifying the DOM. There is no way to prevent a user from modifying the browser’s DOM.
3. For the previous reason, this is not a security concern - it is a mis-application of security tools based on a misunderstanding of how they work/

---

<div class="post-metadata">

**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\
**Post date:** [June 8, 2020, 3:56pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/7 "2020-06-08T15:56:50Z")

</div>

Thank you for your explanations.

I definitely feel like there should be a disclaimer on the `visible` and `display` properties because coming from developing in Vision and not having a background in web development I incorrectly assumed the components wouldn’t be sent to the web page or at the very least, couldn’t be made visible again by any users.

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [June 8, 2020, 4:25pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/8 "2020-06-08T16:25:48Z")

</div>

I’ll reach out to our documentation team so that we can look into clarifying our docs regarding this.

One further point of clarification:  
The property permissions apply to the data objects in the DOM, not the HTML/CSS properties used to build the page. Most users will never see or be aware of these data objects, but they are there and these permissions exist to provide security for them. Applied Perspective Style Class names as well as in-line Style values will ALWAYS be visible to users, so do not expect that setting the permission to private will prevent their values form being seen in the DOM as part of the HTML/CSS structure. Properties with permissions set to “Private” will NOT be visible through the browser in the actual data objects which drive the View.

---

<div class="post-metadata">

**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\
**Post date:** [June 8, 2020, 4:29pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/9 "2020-06-08T16:29:32Z")

</div>

I appreciate the clarification this will help going forward so i don’t make the same mistake twice!

---

<div class="post-metadata">

**Author:** ![FrankP](https://avatars.discourse-cdn.com/v4/letter/f/34f0e0/32.png) [@FrankP](https://forum.inductiveautomation.com/u/FrankP)\
**Post date:** [July 7, 2021, 2:36am UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/10 "2021-07-07T02:36:19Z")

</div>

Does this mean setting the “enabled” an input box or checkbox which write a tag is not safe to do based on roles either?

This was a common way I would implement generic input displays in Vision. I could have a vision template have an “enableOperate” parameter which would be linked to any user inputs, as well as a “basePath” for the tag structure. Is this a security risk in Perspective? If so, what’s the “right way”. I don’t see security options on components like in Vision.

Thanks!

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [July 7, 2021, 5:05am UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/11 "2021-07-07T05:05:58Z")

</div>

> [@FrankP](#):
>
> Does this mean setting the “enabled” an input box or checkbox which write a tag is not safe to do based on roles either?

For all intents and purposes, please think of each Perspective session as having two pieces: the front-end which is what a user is interacting with, and the back-end, which is the session as the Gateway knows it.

If you set `props.enabled` of an input component (button for this example) to `false`, then the back-end has all of these json properties and somewhere in that structure `enabled` is set to `false`. When a session is built, we pipe this structure through the websocket and use JavaScript to render the page based on the setting we provide and some CSS themes/styles/properties; this is what becomes the front-end session.

If a user manipulates the DOM by removing the `disabled` attribure from the `<button>` element, and they remove the `ia_button--primary--disabled` class from that same button element, the front-end session appears to be enabled - but that's ONLY the front-end _appearance_; the back-end session still recognizes that the component is disabled, and so even if a user clicks on this button which no longer appears to be disabled, the back-end takes no action because the back-end "source-of-truth" has not been changed.

**TLDR** : It's perfectly safe. A user can modify the front-end all they want, but it will not have any effect on the back-end.

> [@FrankP](#):
>
> I don’t see security options on components like in Vision.

Security options are set per-action, so that you may specify different security levels for different actions.

 ![Screen Shot 2021-07-06 at 9.59.14 PM](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/a/4a2f90a1f3c66a48b8be24a213bac001fccce99f.png)

I recommend binding the `enabled` property against whatever restrictions you deem necessary if you are binding _values_. If you are limiting restrictions for scripts, you should always place these scripts in the `onActionPerformed` Action, as `onClick` will execute even if `enabled` is set to `false`.

Here's why:  
Some users consider onClick to be analogous to "the user clicked the button so they have permission", but it is literally fired for every primary click - even if the user does not have permission. The onActionPerformed Action is only executed if the component (Button) is enabled and clicked.

---

<div class="post-metadata">

**Author:** ![FrankP](https://avatars.discourse-cdn.com/v4/letter/f/34f0e0/32.png) [@FrankP](https://forum.inductiveautomation.com/u/FrankP)\
**Post date:** [July 7, 2021, 12:39pm UTC](https://forum.inductiveautomation.com/t/keeping-perspective-components-hidden-in-session-issue/35372/12 "2021-07-07T12:39:51Z")

</div>

Thanks for the detailed response! I’m so relieved, I was worried we may have been setting up a minefield in our own backyard!

While I was aware of the need to use runAction, I have had to tell several of my coworkers to use it instead of onClick, so it’s good to mention here if anyone else has similar concerns about ensuring inputs are controlled. This is also very important for keyboard interactions with the UI, which are often overlooked today.

I did not notice any way to set security on input boxes, such as for numerical input. These do have an ‘onActionPerformed’, but it’s not clear to me if that would intercept the write if I put security on the script. In any case, it’s not flexible enough for a multi-purpose input template, so I’m glad passing an enabled flag works safely!