It’s been brought to our attention by users of Bolt UXP enabling the UXP Hybrid feature that admin access is now required for their users to install the UXP Hybrid plugins which in the case for many users creates an issue for teams that don’t have admin access.
I’ve reached out to the UXP Hybrid team about this, and @jsbache has confirmed that this is by design, and since UXP Hybrid plugins load DLLs, binary code that can do “anything”, this should only be allowed under admin access.
While this permission separation makes sense, the big problem persists that tool developers wanting to port the CEP Extensions to UXP with common features like:
CLI Access
OAuth Workflows
WS Servers
HTTP/S Servers
etc
Are now forced to use UXP Hybrid plugins to do these functions as no UXP equivalent exists and how have to ship plugins that can’t be installed my many users who don’t have admin access on their machines.
I’m seeing 2 potential solutions:
IDEAL: Add these common APIs to UXP so users only need Hybrid Plugins for special cases
LESS IDEAL: Have an option to sandbox Hybrid Plugins to some extent so they don’t have free reign and can be installed without admin access
Ideally #1 makes the most sense. All of these common functions users could do in CEP without the need for ExternalObject or any other lower level access, and would allow developers to port from CEP to UXP without needing Hybrid Plugins except in special cases.
Many of these have popular requests but they’ve been mainly shelved in the past. Re-posting the issues for reference:
Also it would help if the permission settings in manifest would have actually some meaning in user UI. Now, when you install plugin dialog is always same even though permission might not be required. This needs to change.
That will cause lots of support tickets raised, especially at the coorporate side. Customers might wait weeks until their request will be processed by admins (I’ve seen that many times). It would be great to continue having an access to Node.js as it was in CEP without unnecessary restrictions.
IMO, permission separation doesn’t really make sence as usually, the updates are scanned by sec team before they arrive to user machines. Of course not all companies have such a workflow but at the same time, as far as I know, there was no registered/famous cases about malware shipped in CEP panels.
On the otherhand if I wanted succefully install CEP panel I created custom .exe installer and it could do a lot to your system. Or you had to instruct people to where they should unzip files.
You probably shouldn’t rely on these statistics .
Statistics for my free Watermark 3 UXP plugin.
Unfortunately, the following years weren’t as strong as these ones.
Reminds me another difference to point out is unlike CEP / Script UI, there’s no non-admin folder you can drop your UXP extensions to, the only ones are admin-required. Also, with UXP you need to register the plugin, not just copy files.
I want to echo Justin’s request - we also face the same challenge.
We are trying to implement a solution that would allow users to securely consume APIs from UXP.
In order to authenticate users, we wish to spin up a local web server to handle OAuth workflow redirects.
The fact that we cannot boot up a local webserver from standard UXP plugins made us look at UXP hybrid plugins, which seemed very promising at first.
However, users of such plugins would not have admin rights to their corporate machines. This prevents us entirely from tapping into the potential of hybrid plugins, and is leading us to think about very limiting and hacky workarounds. This results in us considering shifting functionality away from UXP and InDesign altogether.
Either one of the solutions described in the opening post would work for us.
I’m very interested in hearing about other people experiencing similar challenges, and potential workarounds.
.
And those requiring to register plugin is no-go to me.