For a long time in 7 vision, we used client tags to store state within our app. We want to do the same in 8 perspective. In 7, we would write to these state tags with scripting or bindings and many of our Templates would refresh data based on those changes. We felt pretty confident trusting those tags as how would someone modify them without going through our UI, which used various security controls.
We thought the session would be safe to use in the same way in 8 perspective. All was going well until we had more than one window open and realized the session was shared across windows. So, changing state in one window would change it in the other. To solve this we moved most of our state props to the page level in a custom map.
My question is, can we trust these page level props to only be changed by our scripting and messaging on views? I'm not sure if these props are managed similarly to the session or if they are handled all in the frontend. I'm concerned there might be a way for a bad actor to access and change these properties manually. For example, to look at data they typically wouldn't be allowed to. I'm wondering if we should treat all the event scripts and bindings refreshing data as a traditional web backend, and double check the user has access to the data they are requesting.
If you right click the properties, you should have an option to set the access level. Public is sent to the client and can be adjusted externally (dev console), protected is sent to the client and cannot be edited externally, and private is not sent to the client.
That makes sense, I think we'd only do this with our custom props.
This is perfect for session props and component props. But, the page.props.custom we read/write to doesn't exist in the designer so I'm not immediately sure how to set the access level for those. Same with props added dynamically to the session. Some testing to do for sure.
Do you know of anywhere in the docs that shows how to read/write those props from the browser console so I can test my changes are working?
Unfortunately not aware of any, though it will probably vary a little based on the browser. I don't ever touch data via the dev console. Maybe someone more savvy will weigh in here.
I'm not aware of any way to do this on demand. Might have to have a dummy property that is set to private and then load everything into that.
Yeah, i'm leaning that we will need to move everything back to the session mapped by page. Have a higher level prop like "pages" and make sure that has the right access level. Thanks for the help
Perspective session properties, are from a scripting point of view, exactly the same for Perspective as Client Tags are for Vision. Bindable and readable and writable across the entire client (browser tabs and all inner views in Perspective, all windows/templates in Vision).
Perspective doesn't expose any mechanism to manage page.props. That you can create new keys there via script is essentially accidental. It is not a documented/supported feature, and might break entirely in the future. You cannot make bindings that write to them.
Consider using the pageVarMap() functions from my Integration Toolkit to track per-page values, and pull them into your various views.
Another point to consider:
session custom properties might seem a convenient place to put things, but be very careful not to make a mess. It's hard to figure out what can write to these props, and where they're used, so it can quickly become a maintenance nightmare.
Does anyone know if setting the access to private on an object type session custom property protects all children of that object?
Poking around with the __client object on the dev console and trying to figure out if I can write to the session props from there.
edit: seems like something like __client.page.sessionCustom.root.value.value.get('public').value and __client.page.sessionCustom.root.value.value.set('public', 'newValue')