The PowerChart is awesome, and the component has many valuable features we would like to utilize in our perspective project. However, there is a section exposed in the Pen settings named “Data” that prevents us from utilizing this component in our project:
After inspecting the DOM, there is a specific id for the input field to the Tag Path section named ia_powerChartComponent__settings__addEditPen__dataSource.
I can implement a style rule for this id and set display: none, and have the section be “hidden”…
However, a client could easily remove or modify this style rule and gain access to this field. This is not ideal. The ideal situation would be to have the perspective component driving the DOM not include it at all, and not support any modifications to the source tag path for a pen once included in a chart.
Also, not ideal but perhaps more workable for you particular situation, you can inject the CSS through a style class in the designer. Ultimately if your client is already digging through the custom theme files then they probably have designer access as well, and if they are determined enough could also change this, or even the component setup anyway, but it is an option. (subject to change at IA’s whim)
Basically you can create a style class and then in one of the fields, say the background image field you surround your injection with a closing brace and end it with an opening brace.
There are many examples of this on the forum, here is one:
I don’t think leaving the option for users to manually change the tag path to display tags on any other projects that lives on the same server is more secure :X
It’s not perfect, and can easily be reversed by disabling the css prop in browser, but it’s all I have so far.
I did discuss this with support a while back, and the only solution they could give me was to entirely disable the settings, which is not something I want to do.
So, I’m left with fiddling with css to band-aid the issue. I do hope more control over this is implemented at some point.
I understand the issue, but how would allowing an operator to display historical data of a different project be a security risk?
This will only show historical data, it will not allow them to do anything malicious.
Would the operators even be able to get the correct tag path? I know my tag structure pretty well, but I don’t think I could just type it out and get it 100% correct by hand, pretty big ask for someone with little to no knowledge of the tag structure.
In the end the biggest, annoyance is that the chart doesn’t display the data you want to display.
There should definitely be an option which hides this, in fact if you turn off the tag browser then this should probably also be hidden, but I don’t think its a security risk. Perhaps there is something I’m missing.
Accessing other clients’ data is a security issue.
They wouldn’t have to figure out the whole tag structure, only the histprov and drv part, which, considering our naming scheme, wouldn’t proved too hard.
For the tag path, they can just use the same ones as they have, since the tag structure is the same for all those projects.
Now, there might be ways to safely segregate different projects, but I was dropped on existing projects when I got this job less than a year ago, with absolutely no experience of ignition or scada.
And support never mentioned anything of the sort when I asked them about it.
I’m just coming by add weight to the idea that a user being able to modify the tag path is a security flaw. We would love to let users control other aspects of the pen settings, but exposing that one allows them to see other customer’s data, which is a deal-breaker for us. We have multiple tenants on one Ignition instance, and this “feature” allows access to private user data.
IA, please flag this as a bug. We need to be able to remove the history tag path from the DOM. Just hiding it is not enough. (EDIT: Okay … Fine, it’s not really a “bug” since we can just not use the dangerous parts, but …)
To clarify, our “tenants” are all just different user accounts on a single project that we manage in-house. Customers do not get Designer access or custom projects. We manage our views and scripts such that each user account has certain devices assigned to them, and they can view and operate only those devices. We are an unusual use-case of Ignition in that regard.