Deeplink, where can I find it

Ignition 8.3 Early Access
1

Hi,
Is Deeplink launcher still in the roadmap of 8.3.0? I can’t find it, maybe I’m missing something.

Best regards

2

In the Linux launcher, there's an install script that sets it up.

1 Like
3

If you install the new launchers from an 8.3.0 build on Windows or MacOS they will automatically register with the OS as "protocol handlers" - then when you click a deep link (i.e. designer://host:port) from your web browser or other source, it will delegate to the OS and ask if you want to use 'Designer Launcher to open this URL'.

1 Like
4

Is there any other documentation to the URL parameters this deep link supports?

I.e., Does it handle passing JVM args?

2 Likes
5

Hey Keith,

All current argument supports are in our Documentation

We don’t support JVM arguments in Deep Links. We do plan to continue to add parameters as requested though.

6

One thing I would like to see added to the launchers is the ability to redirect the client cache via a shortcut or deeplink without having to create a redirect.txt file in the .ignition folder for each user.

The reason for this is we have a client who has a remote desktop server where random users can log in to the same server and launch the app. While we could probably have them set up group policy to push a redirect.txt file to all users on initial sign in, it would be much easier for us to modify the shortcut (v8.1+) or set up a deeplink (v8.3+) with the shared cache location, and it would be more transparent and easy to set up since I don’t have control over their AD/GPO settings.

1 Like
7

well, the only concern i have with this is that a deeplink (typically from the gateway webpage, but could be from anywhere) is essentially determining where files should be saved on a client machine which would sidestep common security boundaries typically employed for stuff like this. It should be up to the user to choose or at least allow where this stuff is saved.

maybe there is an option for deeplinks to provide a suggested location and the user confirms that on launch or something.

I would open a ticket on Ignition Features and Ideas | Inductive Automation

Edit: We are definitely open to adding deeplink parameters which are useful, so I definitely appreciate your request here, we just need to think through the security concerns on this one.

Thanks,
JJ Coffman

1 Like
8

Please consider adding everything to file associations. Those are already in the user's file system (or you could check that they are). I'm particularly interested in being able to include --add-opens JVM arguments.

9

im definitely looking at adding pretty much everything for file associations. thats a bit different than deeplinks

2 Likes
10

I guess what I was thinking that the shared cache location would have to exist with the cached files pre-existing to even work so it would require prior setup (launching the client and copying over the cache files to the shared location). This would allow fallback to the local profile folder if it didn’t exist. Is there any concern with multiple users running the client from the same local cache at the same time? Like if one accepts a project update from the gateway, will it break the other client? (I’m hoping not as this is the scenario I’m looking to use it for with multiple clients on a single remote desktop server)

11

well, there might be.
file permissions for the extracted cache could become a problem if you aren’t really on top of it. Also, there are potentially user settings and competing logs in clientlauncher-data as well as workstationUserData if you are using workstation.

Jars and resources from target gateways are fetched and extracted into the cache directory on every launch when needed (CRC checks) and there is a lock file in there that prevents clients from stepping on each others toes, but this mechanism isn’t built around multi-user support for a shared resource directly, its meant for multi-client support.

I think its doable, but would require some strict file permissions and probably symbolic linking the cache directory specifically and not just using the redirect.txt file approach maybe?

Someone else might have already tried this and pulled it off, maybe they could chime in if they come across this thread. otherwise you could probably reach out to our support department and they might have some best practices here.

12

Any plans to add support for the -Dautologin and -Dproject args?

13

Autologin via deeplink almost certainly doesn't pass the security sniff test. Just further impetus for us to better support automagic SSO.

14

deeplinks already support the project as the first path part. so designer://localhost:8088/project?insecure=true will work to target a specific project in 8.3+ gateways for the designer and 8.1 for vision/workstation.

I agree with Pauls comment on autologin

1 Like