XYplorer Beta Club

TheQwerty wrote:At the same time I'm thinking maybe it would be better to put the effort toward making stepping through scripts better. As it is, I don't feel a user that doesn't know how to script would truly understand the information the dialog presents to them. It seems more like a debugger than a safety guide. Perhaps it could be improved to better explain the commands that are about to be executed and help users understand what the script is actually doing?

Yes, that would be a way. Not difficult, but a lot of work though. For a start I could add some icons in front of the commands (showing the danger factor of that command...).

admin wrote:

TheQwerty wrote:At the same time I'm thinking maybe it would be better to put the effort toward making stepping through scripts better. As it is, I don't feel a user that doesn't know how to script would truly understand the information the dialog presents to them. It seems more like a debugger than a safety guide. Perhaps it could be improved to better explain the commands that are about to be executed and help users understand what the script is actually doing?

Yes, that would be a way. Not difficult, but a lot of work though. For a start I could add some icons in front of the commands (showing the danger factor of that command...).

What scripting commands should get a "risky" icon?
- all commands changing files or folders
- hmmm, that's it?

admin wrote:

admin wrote:

TheQwerty wrote:At the same time I'm thinking maybe it would be better to put the effort toward making stepping through scripts better. As it is, I don't feel a user that doesn't know how to script would truly understand the information the dialog presents to them. It seems more like a debugger than a safety guide. Perhaps it could be improved to better explain the commands that are about to be executed and help users understand what the script is actually doing?

Yes, that would be a way. Not difficult, but a lot of work though. For a start I could add some icons in front of the commands (showing the danger factor of that command...).

What scripting commands should get a "risky" icon?
- all commands changing files or folders
- hmmm, that's it?

Um.. I'm not really sure.

I mean the only always risky command is Delete. The rest depend on context.
Load is okay, but Load of a remote or just Downloaded script is risky.
SetKey is okay, but SetKey in XY's current configuration could be risky.

I was thinking more along the lines of a one line description of what the command will do. That way you aren't assessing how risky something is, but just making sure it is clear to the user. While the majority of commands are named so that make perfect sense to script programmers, a beginner isn't going to know Get/SetKey work with INI files and by default access the current XY configuration.

TheQwerty wrote:

admin wrote:

admin wrote:

TheQwerty wrote:At the same time I'm thinking maybe it would be better to put the effort toward making stepping through scripts better. As it is, I don't feel a user that doesn't know how to script would truly understand the information the dialog presents to them. It seems more like a debugger than a safety guide. Perhaps it could be improved to better explain the commands that are about to be executed and help users understand what the script is actually doing?

Yes, that would be a way. Not difficult, but a lot of work though. For a start I could add some icons in front of the commands (showing the danger factor of that command...).

What scripting commands should get a "risky" icon?
- all commands changing files or folders
- hmmm, that's it?

Um.. I'm not really sure.

I mean the only always risky command is Delete. The rest depend on context.
Load is okay, but Load of a remote or just Downloaded script is risky.
SetKey is okay, but SetKey in XY's current configuration could be risky.

I was thinking more along the lines of a one line description of what the command will do. That way you aren't assessing how risky something is, but just making sure it is clear to the user. While the majority of commands are named so that make perfect sense to script programmers, a beginner isn't going to know Get/SetKey work with INI files and by default access the current XY configuration.

I meant potentially risky. After thinking about it again I see only the following:

Potential high risk class:
- all commands changing files or folders: delete, rename, copy, move, setkey, download...
- all commands opening programs (which themselves could then change files or folders): open...

Maybe in a potential medium risk class:
- copytext (changes the clipboard, which *might* interfere with other processes)

All other commands are clearly harmless:
- filter, focus... this is just display inside XYplorer
- set, input... just moving memory inside XYplorer

So I would just stick some symbol to the "high risk class" commands. Then when stepping through a script, you can quickly pass by the harmless commands, and keep an extra eye on the risky ones. It's just a little visual helper to make them stand out.

admin wrote: I meant potentially risky. After thinking about it again I see only the following:

Potential high risk class:
- all commands changing files or folders: delete, rename, copy, move, setkey, download...
- all commands opening programs (which themselves could then change files or folders): open...

Maybe in a potential medium risk class:
- copytext (changes the clipboard, which *might* interfere with other processes)

All other commands are clearly harmless:
- filter, focus... this is just display inside XYplorer
- set, input... just moving memory inside XYplorer

So I would just stick some symbol to the "high risk class" commands. Then when stepping through a script, you can quickly pass by the harmless commands, and keep an extra eye on the risky ones. It's just a little visual helper to make them stand out.

Generally I'm here with Don.
But when reading for example "set", I think there could be another additional(!) classification: "scripting-internal commands", like set substr, incr, input, text and others. They interfere with nothing but the local script(-variables). Later on, if they will be seen as commands, this applies to if, then, else, call, ..., too.

I think these commands, not interfering with something outside the script, like XY, clipboard, external variables (like system-vars) or whatever could be seen as an own class called "internal" or so, and be treated as "really secure".

admin wrote:

So I would just stick some symbol to the "high risk class" commands. Then when stepping through a script, you can quickly pass by the harmless commands, and keep an extra eye on the risky ones. It's just a little visual helper to make them stand out.

Not sure what some symbol is but could perhaps the command be colour coded according to potential risk - black- none, green - caution, red - severe

Well with this work being implemented, the fact that we kind of settled on greater functionality & user responsibility, and the fact that the white list for Load can be easily bypassed using Download;Load, are you planning on keeping the white list in 7.6?

TheQwerty wrote:Well with this work being implemented, the fact that we kind of settled on greater functionality & user responsibility, and the fact that the white list for Load can be easily bypassed using Download;Load, are you planning on keeping the white list in 7.6?

Not yet decided. Would it be interesting for you if I drop it?

admin wrote:

TheQwerty wrote:Well with this work being implemented, the fact that we kind of settled on greater functionality & user responsibility, and the fact that the white list for Load can be easily bypassed using Download;Load, are you planning on keeping the white list in 7.6?

Not yet decided. Would it be interesting for you if I drop it?

Well I can see some use for it, but I don't think I'd actually use it any time soon.

I was just curious since, as I said, it seemed we decided to forget about building the sandbox by instead educating the user better, and as such it seemed kind of pointless to still have a whitelist restriction.

TheQwerty wrote:

admin wrote:

TheQwerty wrote:Well with this work being implemented, the fact that we kind of settled on greater functionality & user responsibility, and the fact that the white list for Load can be easily bypassed using Download;Load, are you planning on keeping the white list in 7.6?

Not yet decided. Would it be interesting for you if I drop it?

Well I can see some use for it, but I don't think I'd actually use it any time soon.

I was just curious since, as I said, it seemed we decided to forget about building the sandbox by instead educating the user better, and as such it seemed kind of pointless to still have a whitelist restriction.

I kind of decided to "see what happens" (sounds stupid, but is often wise). I guess that only very few users will ever see the message about "xyplorer.com only". If I'm wrong and they start knocking at my door I can easily remove the restriction. Call it "researching the user base"...

Thread is years old but I found nothing newer on the matter ...

I use several custom scripts on different LANs, and I am trying to centralize scripts to my server rather than iterate the newest versions of the scripts across all the machines.

I ran into the "trusted domains" block, so I tried the Download;Load workaround, which still works (yay).

Is there any newer info on the subject? My Google Fu becomes weak in my old age.

(My 2 cents is, if a user is savvy enough to add a trusted domain to a config file, then he's savvy enough to take responsibility for the security. Caveat executor!)

giveMeUrMonies.xys LOL

christopherwood wrote:... on different LANs ...

... already figured how to load scripts across multiple machines on a single LAN.

... tried the Download;Load workaround, which still works ...

Hmm, now I am wondering if I could rig a single-click system to update all my scripts from the server to the LAN, and not have to worry about downloading the script every time I run it. (I wonder if I can download an entire directory at once? or a ZIP file and unzip it?)

... which would also answer the problem of using a custom server-based icon on the toolbar ...

Updated remote.xys to make the self() function actually work.