Expert"Enable Test Script" UIv4 security experiences?
On our portal, I recently noticed the "Enable Test Script" option under the UIv4 security section, because UIv4 recommended I toggle it from Enabled to Disabled. I avoid UIv4 like the plague but as LM forces it on us more and more, I end up having to use it more and more. Maybe in this one case it was a good thing because I wasnt aware about the toggle.
I even reached out to LM and the person who helped me provided a lot of good information but had to look into it himself in terms of sharing documentation because apparently its just a small print mention in a table.
As I suspected when I asked them, switching this to disabled means you cant edit datasources or troubleshoot them in the temp editor window, so therefore you couldnt do anything malicious. I even checked (and so did he, the LM contact) to make sure you cant edit and hit play if you can view datasources when its enabled, you can only do it if you can Manage the Modules.
I verified we have no roles that have Manage except adminstrator, and our administrator list is pretty locked down. We might lock it down a bit more. But basically right now on our portal, only administrators can use the loophole that exists with this enabled, and only they can toggle the setting for the whole portal to disable it, but they can toggle it right back.
So all that being said, what experiences do you all have with this feature? Turning it off seems good, but on the other hand, I already know the administrators and they can toggle it back at any time.
Thoughts?
Modules toolbox has come a long way, but that's not saying much. It's got a long way to go.
My opinion: Actions that aren't associated with editing the module shouldn't be exclusively in the editor. LM has made the decision to have a "viewer" and an "editor". If they persist in this, they should put things like "show associated devices", "test appliesto", "test active discovery", and "test collection" in the viewer as well as the editor. They do not change the DS, so they don't need to be locked into the editor. That would solve the problem of modifying the script then using the test script button to run some malicious or untested code.
My 2nd opinion: they should do away with the module viewer. The editor should be the only way to view the details of a DS. It's where most of the pencils in the new UI take you anyway. Once there, I don't see any harm in having two levels of permissions: 1) read only and 2) read write. The read only users would be able to do anything except change the module. So they would be able to run any of the tests, see associated devices, etc. But the script fields would be locked down. They'd be able to read them, but not modify them. RW would obviously have everything.
I guess my point is that RO users should be able to test appliesto, discovery, and collection (same as poll now, really) because that doesn't involve a modification, even temporary, of the DS. Creating a new permission level just because you took the lazy route and only checked permissions when someone hits the save button is, well, lazy.
