Launch Client without Clent Launcher

Ignition Early Access
21

One thing we did was to put the launcher on a “public” company server, still internal but access for all employees available. Then we just installed the shortcuts on individual user’s computers

2 Likes
22

Is it possible to run Ignition 8.0 on a Windows embedded machine?
And if so, how?

The standard browser does not display the webpage correctly and the native launcher for Windows does not run. Error shows it is not compiled for Windows CE…

Any suggestions?

23

Are you trying to run the Ignition gateway or just a client? What version of CE/Embedded?

24

Hi Kevin,

I’m trying to run a client on a Simatic Mobile Panel :slight_smile:.
The windows version is: Windows Embedded Compact v8.00 (Build 6228 on Mar 15 2017)

25

Well… if you can get Java 11 installed on there somehow, you might be able to launch a client without the client launchers.

If you can get a modern browser installed on there you can use a Perspective project.

26

How do you launch the client without the launcher?

27

If you look at the clientlauncher.log file in ~/.ignition/clientlauncher-data you can see the line it uses to actually launch a client:

INFO  [ClientLauncherFrame           ] [09:09:13,441]: Starting Java with the following parameters:nohup java -classpath /home/kevin/.ignition/clientlauncher-data/launchclient.jar -Djavaws.sr.gateway.addr.0=localhost:8088/main -Djavaws.sr.scope=D -Djavaws.sr.launchts=1552406951131 -Djavaws.sr.main=com.inductiveautomation.ignition.designer.DesignerStartupHook -Xms64M -Xmx512M -XX:MaxPermSize=128m -Dsun.java2d.d3d=false com.inductiveautomation.ignition.client.launch.BootstrapSwing &

You can copy/paste that into a terminal to launch one just the same.

You’d need a cached copy of launchclient.jar already though…

2 Likes
28

Note that you will also want to add -Djavaws.sr.runtimeOverride=true to the arguments so that retrieval of the runtime from the gateway doesn’t occur and the client starts up on the JVM you are initially launching from. The same is true for designers as well.

Hope that helps,
Jonathan C

1 Like
29

https://docs.inductiveautomation.com/display/DOC80/Vision+Client+Launcher

It's good practice to download and install the Vision Client Launcher every time you install a new release of Ignition. The Vision Client Launcher is a separate application and is not part of an Ignition release, so it's important not to have an outdated Vision Client Launcher shortcut residing on your desktop. Each time you install a new version of Ignition, download and install the Vision Client Launcher, then let the install process create a new desktop shortcut for you automatically.

Having to download and install the vision client launcher on all machines that need to run Ignition applications every time we update/upgrade Ignition is going to get more and more annoying and difficult. Additionally, I don't like that users can now simply open the client launcher that is on their machine and launch any project on the gateway... Would be nice if you had to login to the client launcher and only certain roles could launch applications/create desktop shortcuts. I found and upvoted this idea here: https://ideas.inductiveautomation.com/ignition-features-and-ideas/p/native-client-launcher-restrict-project-view

30

It should be noted that it is recommended but not always required. Each release of the launcher provides bug fixes and enhancements but the churn is nowhere near as much as the Ignition platform. If this is a pain point you could check the release notes to see if new changes in the launchers would affect your situation specifically. Some customers have had success using bash scripts or other mechanisms for quickly deploying them as well.

As far as restricting the projects that are visible, This sounds easy on the face of it, however is very difficult. Now that projects can be saved that originate on any reachable gateway, how do you determine what projects your user has access to? how many times will they have to log in to ensure that all the projects in the launcher are accessible by them? Does each gateway have the same user source? What if they do not? Its not that this is something we wont implement, Im just trying to gauge the demand against how much work it would entail.
(ultimately if you have a great idea on the user experience for how you think this should work please add a comment to the idea post!)

Also, currently you can lock the configuration of the launcher in .ignition/clientlauncher-data/${LAUNCHER_NAME}.json by setting the key-value for lock-configuration to false. This will ensure that new applications cannot be easily added by users. Maybe that can help for the time being?

Hope that helps/clarifies things,
Jonathan C

31

Thanks Jonathan - having the ability to lock the configuration is a workaround at very least.

The idea much simpler than what you are thinking - making it such that opening the client launcher is the same as opening a designer. There should be a property in Gateway Settings for Client Launcher Role(s) and if you don’t have that role you cannot open the Client Launcher. Then give all our developers this role which they use on the client machines to create desktop shortcuts for end users.

As the idea I upvoted was posted April last year, it does not really pertain to V8. I posted my own idea here: https://ideas.inductiveautomation.com/ignition-features-and-ideas/p/role-based-access-to-client-launcher

32

I think im following what you are saying, however you can already add security to restrict Vision Client Logins based on roles. Even if they can launch a Vision Client they still wouldn’t be able to get past the login screen.

Adding this feature to the Launcher itself (which simply spins up a Vision Client) would only accomplish preventing them ever launching but they still would not be able to login to the client itself.

1 Like
33

As @jcoffman has pointed out, this is already true. You just have to turn on per project. I don't see how your request can be implemented and still have a launcher that works with multiple gateways. What do you do if one gateway says "anyone can use the launcher" and another gateway says "only so-and-so can use the launcher" ? You have to open the launcher to pick a gateway but you can't open the launcher.....

34

My biggest concern is that a user launches a project and operates a machine that they are not local to. I am just trying to eliminate this as a possibility (more of a probability in my opinion).

1 Like
35

Then build in the checks in the project to only permit operator functions on the appropriate machines. I personally like using the Mac ID(s) on the local machine as a key into a database of permitted operations. Use techniques like the following in a startup event script:

4 Likes
36

What about needing required roles to access the 'Add Application(s)' side of the client launcher?

37

But where would those ‘Required Client Roles’ be specified? The entire point of the Client and Designer launchers is that they’re not tied to a specific gateway - you use the one launcher application to launch clients and designers from any gateway.

38

I think an alternative to what you are trying to accomplish would be this:

  1. setup the application configuration however you like on some launcher. maybe this is on a dev machine or separate user account, whatever.
  2. set the lock.configuration property in the launchers json file (again, in .ignition/clientlauncher-data) to true
  3. replace the json file on the user machine that you want to lock the configuration of with the one that you configured.

You could do this on the launcher you want to configure itself and simply toggle the lock.configuration value as needed.

Coupling the privileges of a launcher to a specific gateway seems like a recipe for disaster. the lock.configuration property should be adequate to limit users from modifying the configuration of the launcher.

39

My apologies, I have not yet worked with multiple gateways so its taking me a little to wrap my head around what you are saying.

Okay well then what about needing required roles to access the ‘Select Applications’ side (which comes after a gateway is selected) of the client launcher?

40

I know it’s been a few years on this, just letting you know how I deal with this issue. for the user authentication by projects they can pick any project from the add application and open them but when they open it, if their username doesn’t match the name from some allowed list then it tells them they don’t have access to that project.

Another thing I’ve done was try to have one main project that everyone would open and from inside that project I would let them go to other projects, this will also give you a lot more wiggle room to manage who can access what project and not have to worry about having many applications to choose from in the Client Launcher.

1 Like