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:
setting the components meta.visible property to false
setting the components position.display property to false,
setting both meta.visible and position.display properties to false
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.
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.
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.
There are a few things going on here, so I’ll do my best to address everything.
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.
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.
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/
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.
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.
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.
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.
Security options are set per-action, so that you may specify different security levels for different actions.
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.
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!
