In this installment of our Script Packaging series, we review the options for adding restrictions when running your packaged script.
Sometimes running an application on a platform that is not supported or under conditions that are not secure can do more harm than good. For example, a script to install Windows XP service packs should probably not run on Windows 7. Of course, one would hope the installer would catch that, but who knows?
When you package a script with the SAPIEN Script Packager, you have an assortment of options to prevent a packaged script from running under some conditions.
At the top of the Restrictions page is a selection of OS versions:
If checked, the application will only run on the OS versions you marked. You may ask why Windows 11 is not on that list. Technically, Windows 11 still represents itself as Windows 10, so the current mechanism would not catch this. You can expect an update to this in a future version.
Users, Devices, Environments
The second set of restrictions are fields where you can enter semicolon-separated lists of items that designate where the application is allowed to run:
For example, if only the users ‘Administrator’, ‘Caleb’ and ‘Lucy’ are allowed to run your application, you would enter this in the User name field:
You can apply the same use of semicolon-separated lists of items in the other fields: MAC address, Machine name, and Domain.
Instance, Script Block Logging, Script Block Transcripts
Allow only one instance is fairly self-explanatory; if your application is already running, you cannot start it again.
The last three boxes only apply to PowerShell. These options either prevent a launch with script block logging, or turn off script block logging and/or transcripts. Because script block logging and script block transcripts only exist for PowerShell, these options are not available for any other type of engine or scripting language.
These settings are commonly used for scripts which contain items you do not want the average user to see. If, for example, your script needs to connect to a legacy database on a server with an administrative user and password, you do not want the average user to be able to find these credentials in a log.
We have other ways to deal with that last scenario, so stay tuned for the next part of this blog series.
- Script Packaging Step-by-Step: Choosing a Script Engine
- Script Packaging Step-by-Step: Output Settings
- Script Packaging Step-by-Step: Adding icons to your application
- Script Packaging Step-by-Step: Embedding Credentials
- Script Packaging Step-by-Step: Version Information
- Script Packaging Step-by-Step: Custom Build Commands
Any comments or suggestions? Please post them in the comments below or in our support forums.