Tag Archive: web server

When configuring JNIORs, how you should configure them depends on what Series JNIOR you have. You’ll want to use the JNIOR Web Page for Series 4 JNIORs, and the Java Applet for Series 3 JNIORs.

JNIOR Web Page
Java Applet

The Java Applet is a local Java application that can be launched from the Support Tool for each Series 3 JNIOR, while the JNIOR Web Page is a browser accessible configuration for Series 4 JNIORs.  Series 3 JNIORs can’t open the JNIOR Web Page because they don’t support the necessary web files required to run the JNIOR Web Page from it. The Java Applet at one point was accessible from a browser, but due to security risks it was changed to be a separate application. Series 4 JNIORs do have the necessary files to open both the Java Applet and the JNIOR Web Page, but you should not use the Java Applet for Series 4 JNIORs. The applets cannot properly configure a Series 4 as the registry settings for many configuration settings are different than what the Series 3 used.

The JNIOR automation controller is a single board computing device supporting a variety of I/O. Once installed the product generally works tirelessly to perform its intended purpose. There is no need for routine user interfaces such as display, mouse and keyboard. When configuration, programming and maintenance tasks are required the user can access the device in a number of ways. One of those is the most general and capable. That is the WebServer User Interface or WebUI accessed through the network using a general purpose browser.

 

This WebUI is often referred to as our Dynamic Configuration Pages or DCP. The DCP acronym conflicts with other uses especially in the Cinema industry where it refers to the Digital Cinema Package that is used to deliver content (movies). So we now simply call it “The WebUI”.

This one ‘website’ allows you to completely manage your JNIOR. You can both control I/O and configure most of the system on various tabs here. This also provides a convenient means of moving files on and off of the unit. Even the Command Line Interface or Console is available, as one of the tabs provides a terminal simulation. The JNIOR must be wired to the network and assigned proper Internet Protocol (IP) addressing. You simply point the browser to it.

JANOS v2

The WebUI supplied with JANOS v2.0 appears much the same as it has throughout the Series 4. One big change is that you can now resize the display by dragging the lower right corner. That might be particularly useful if you are working in the Console tab or exploring Folders containing numerous files. It also has obvious value in viewing the Syslog or About tab content.

A somewhat less obvious enhancement is the VT-100 capability that the Console tab now has to support the new built-in simple text editor command EDIT. This feature offers a means to edit small files and scripts directly on the JNIOR avoiding the need to extract the file to your computer, editing it there and then replacing it on the unit. That’s a tedious process especially if you are trying different things and making repeated changes to files. The editor can also provide a means by which you can page through a lengthy file or log.

Relocation

A feature of the JNIOR WebServer is its ability to serve an entire website directly out of a single ZIP library file. This avoids a very common problem wherein the multiple files required by websites can easily get out of sync and cause page problems. On the JNIOR all of the files are in one package and stay there. All that is required to update the website including our WebUI is to replace one single file.

On Series 4 JNIORs running JANOS v1 the WebUI lives in the /flash/www.zip file. It is the default website offered by the unit. This works because the default WebServer root folder is /flash/www and the WebServer looks there first for requested files. If they are not found it then looks in any ZIP library file of the same name as the folder. So by default it would then look in www.zip.

You might think that if the JNIOR has a fully capable WebServer could you create a custom website for your specific application? Yes, you absolutely can. You likely wouldn’t want to lose the ability to access the configuration WebUI. Well that is easily accomplished by first moving the /flash/www.zip file to /flash/www/config.zip. Note the name change. Once this is done to access the Dynamic Configuration Pages you append the /config folder to the unit’s URL. The Webserver would look for the initial page in /flash/www/config and not finding it there then look in the config.zip file. This works even for sub-folders in the ZIP library file. Once you have done this you can now place your custom website in the root and it will become the default.

JANOS v2 now is supplied with the WebUI already relocated as described. By default the WebServer search path now includes the /flash/www/config folder. So if there is no custom default website defined the WebUI will automatically open.

The importance of this relocation relates to future updates. We need the ability to update the config.zip file. If you implement a custom website and want to take advantage of the single distribution file you would necessarily have to name it www.zip. You would likely not appreciate it if you overwrote your website in an update. So now we are proactively avoiding the issue. 

By the way, there are even more ingenious ways of setting up sets of custom websites on the JNIOR. If you are interested you can find out more through INTEG Support.

There is a chance you will see the following PHP error. For this to be seen you must have a Series 4 JNIOR that had JANOS version 1.6 or older and you just updated to a new JANOS version

Why did this happen?

The older JNIORs had a different web page than we have now. The main web page used to be served out of the flash/www folder. Now the DCP, the newer web page, is served out of the flash/www.zip file. If the flash/www/index.php file is still found then the web server will process it and serve it instead of the index.php in the www.zip file.

How do we fix it?

To fix this we need to remove the old flash/www/index.php file. This will allow JANOS to look in the flash/www.zip file. This should be a step in the All-In-One update project. You can do it manually with a Telnet connection like this…

The problem: You get the following screen when trying to go to the DCP or any web page on the JNIOR.

In this image we tried to go to the IP Address of the JNIOR.  This should present us with the DCP web page.  In this case we are presented with the “Page not found” response page.

This means that the file cannot be found in the filesystem for this page resource.

To troubleshoot this we need to look at the filesystem.  Since the DCP is not available we need to use FTP or a telnet session.

Using FTP

Open Windows Explorer. In the address bar type ftp://IP ADDRESS. You might see the message that Windows Explorer cannot access your folder.

Most likely this is because you need to provide credentials. To do that you need to right click in the white-space in the window and select Login As…

Once you log in navigate to the flash directory.

If the the DCP or default web page is missing then all of the following must be met:

  • www.zip is missing
  • public.zip is missing
  • www/ directory is missing or there is not an index.php file in the www/ directory
  • public/ directory is missing or there is not an index.php file in the public/ directory

Using Telnet

We can use Telnet to look at the filesystem as well. To do this, open your favorite Telnet application. Make a connection to the JNIOR. Log in. You will then use either the dir command or the ls command. Both commands are the same and will list the directory contents.

Use the command of your choice, whichever command is easier to remember, and add “flash” as a parameter. This wil cause the command to list the contents of the flash directory. If the the DCP or default web page is missing then all of the following must be met:

  • flash/www/config.zip
  • www.zip is missing
  • public.zip is missing
  • www/ directory is missing or there is not an index.php file in the www/ directory
  • public/ directory is missing or there is not an index.php file in the public/ directory

If you are having issues accessing your JNIOR’s webpage, please reach out to our support to get your setup working again.

We can take the Message Pump sample one step further. We can incorporate real-time web page communication. The web server supports WebSockets. WebSockets allow for real-time bidirectional communication. We can leverage this feature and have these messages put on the Message Pump so that our Java application can get them.

Our web page for the example looks like this.

In the code we have a button handler that will send the json formatted message to the web server.

            // register an onclick method so that we can post a message to get a random number from our 
            // sample java application.
            document.getElementById('random-number-button').onclick = function (e) {
                var getUpdates = {Message: "Post Message", Number: 2000, Content: "get-random-number"};
                _comm.sendJson(getUpdates);
            };

A full listing of the web page is as follows

<!DOCTYPE html>
<html lang="en">

    <head>
        <base href="/messagepumpsample/">

        <title>Message Pump Web Interface</title>

        <script src="comm.js" type="text/javascript"></script>
        <script src="md5.js" type="text/javascript"></script>

        <style>
            body { padding: 5px; }
        </style>

    </head>


    <body>

        <div>

            <h1>Message Pump Web Interface</h1>

            <button id="random-number-button">Get Random Number</button>
            <p style="width: 600px;">
                Clicking the button above will cause a message to get sent to the Web Server.  The Web Server 
                then places it in the System Message Pump.  Our sample Java application will then receive it and 
                for the sake of the sample will respond with a random number.  By placing the random number in a 
                message and back on to the System Message Pump with the same message type that it received, the 
                Operating System knows to send it back to the Web Server and in turn back to the sending Web 
                Socket connection.
            </p>

        </div>


        <script type="text/javascript">
            // our websocket communication object
            var _comm;
            var _loggedIn = false;

            // method called when the connection is successfully opened
            var onopen = function () {
                console.log("comm opened");
            };
            
            // method called when our websocket object receives a message from the web server
            var onmessage = function (evt) {
                var json = JSON.parse(evt.data);
                console.log(json);

                if (json.Message === "Monitor") {
                    if (!_loggedIn) {
                    }
                    _loggedIn = true;
                }

                //
                else if (json.Message === "Reply Message") {
                    if (2000 === json.Number) {
                        alert("Your Random Number is " + json.Content);
                    }
                }
            };
            
            // instantiate our websocket communications object and wire up some methods.  lastly call connect!
            _comm = new Comm();
            _comm.onopen = onopen;
            _comm.onmessage = onmessage;
            _comm.connect();


            
            // register an onclick method so that we can post a message to get a random number from our 
            // sample java application.
            document.getElementById('random-number-button').onclick = function (e) {
                var getUpdates = {Message: "Post Message", Number: 2000, Content: "get-random-number"};
                _comm.sendJson(getUpdates);
            };
        </script>
    </body>

</html>

To accomplish this we created a class to handle the get-random-number request. We could have handled this in our Main class but hey I like modularity.

package com.integpg.messagepumpsample;

import com.integpg.system.SystemMsg;
import java.util.Random;

public class RandomNumberMessageHandler implements MessagePumpListener {

    @Override
    public void messageReceived(SystemMsg systemMsg) {
        // this sample uses message type 2000
        if (2000 == systemMsg.type) {
            String content = new String(systemMsg.msg);
            System.out.println("content: " + content);
            
            Random rand = new Random();
            int randomNumber = rand.nextInt();
            
            SystemMsg responseMsg = new SystemMsg();
            responseMsg.type = 2000;
            responseMsg.msg = String.valueOf(randomNumber).getBytes();
            
            MessagePumpEngine.postMessage(responseMsg);
        }
    }

}

We also had to modify our init() method to attach our MessagePumpHandler.

package com.integpg.messagepumpsample;

import com.integpg.system.SystemMsg;
import java.util.Random;

public class RandomNumberMessageHandler implements MessagePumpListener {

    @Override
    public void messageReceived(SystemMsg systemMsg) {
        // this sample uses message type 2000
        if (2000 == systemMsg.type) {
            String content = new String(systemMsg.msg);
            System.out.println("content: " + content);
            
            // get a random number
            Random rand = new Random();
            int randomNumber = rand.nextInt();
            
            // build our response
            SystemMsg responseMsg = new SystemMsg();
            responseMsg.type = 2000;
            responseMsg.msg = String.valueOf(randomNumber).getBytes();
            MessagePumpEngine.postMessage(responseMsg);
        }
    }

}

Almost immediately upon clicking the button we get our response.

As you can see here the web page gives you an amazing ability to communicate with a Java application in real-time.

Since today you really need to keep the Login requirement enabled on your JNIORs, what if you want to serve some Web data publicly? You know, without having everyone use a password?

Well, you probably aren’t aware that in addition to the default WebServer root of /flash/www there is another called /flash/public. Yep. You can probably guess now that anything you put in /flash/public will be served by the WebServer without requiring that the client login/authenticate. Everything else remains secure and requires your login for access.

In fact that is how our HoneyPot unit that is sitting out directly on the Internet lets you access the following page:

http://honeypot.integpg.com/map.php

There you didn’t need to login and yet that JNIOR is secure and nothing else can be accessed or modified without securely logging in.

Pretty sweet, eh?

Oh and you could rename /flash/www.zip as /flash/public.zip and serve the DCP publicly. Wait! wouldn’t that be dangerous?

Well, not really. The DCP makes a secure Websockets connection back to the JNIOR. That Websockets interface requires a login (assuming you haven’t also disabled that). So when you open the public DCP you are again asked to login. You have to properly authenticate before you can really do anything.