Verschiedene Lösungen für das Kompatibilitätsproblem von SiteKiosk unter Windows 7 mit Internet Explorer 10

The English version can be found here: http://devblog.provisio.com/post/2013/04/10/Solutions-to-Fix-the-Compatibility-Issue-with-SiteKiosk-and-IE10-on-Windows-7.aspx

Das Kompatibilitätsproblem, dass die SiteKiosk Versionen 7.1 bis 8.6 unter Windows 7 bei installiertem Internet Explorer 10 betrifft (Windows 8 Systeme sind nicht betroffen), ist ab der SiteKiosk Version 8.7 gelöst worden. Die empfohlene Problemlösung ist daher ein Update auf mindestens SiteKiosk 8.7 durchzuführen. Das Update ist kostenlos für alle Nutzer von vorhergehenden SiteKiosk 8 Versionen und für alle Kunden mit SiteKiosk 7.8, die ihre Lizenz seit August 2011 erworben haben.

Kunden, die kein Update auf mindestens SiteKiosk 8.7 durchführen können oder wollen, stehen die folgenden Lösungen zur Verfügung, um das Problem zu lösen:

  1. 1) Laden Sie diesen kleinen Fix herunter, den wir auf unserer Webseite anbieten und führen Sie die Exe-Datei aus.

    Sie können den Fix auch als Silent-Installation durchführen. Nutzen Sie dafür auf der Kommandozeile den Parameter /s (IE10patch.exe /s).

    HINWEIS: Nutzer mit einer SiteKiosk 7.1 Version auf Windows 7 64Bit Systemen müssen vor der Anwendung der Fix-Datei mindestens auf SiteKiosk 7.5 updaten.

  2. 2) Die zweite Lösung ist für alle Nutzer verfügbar, die www.siteremote.net für die Fernverwaltung Ihrer Kiosk Terminals nutzen oder einen eigenen SiteRemote Server betreiben.
    Wenn Sie sich in Ihr Team unter www.siteremote.net einloggen und zum Aufträge-Tab gehen, finden Sie dort eine Auftrags-Vorlage mit dem Namen Windows 7 IE 10 Fix. Weisen Sie diesen Auftrag Ihren Windows 7 Maschinen zu. Lesen Sie bitte zuvor die Ausführungen die in der Auftragsbeschreibung stehen.
    Das Nachfolgende gilt nur für Kunden, die Ihren eigenen SiteRemote Server betreiben. Kunden mit einem eigenen SiteRemote Server können die obige Auftrags-Vorlage selbst erstellen. In einem Team auf Ihrem SiteRemote Server gehen Sie bitte zum Aufträge-Tab und klicken dann unten auf der Seite auf Neue Vorlage. Wählen Sie einen Namen und eine Beschreibung und als Clienttyp SiteKiosk. Wählen Sie dann Datei hochladen als Aktionstyp und klicken Sie auf Hinzufügen. Laden Sie die Datei win7ie10fix.js aus diesem zip-Archiv zum SiteRemote Server hoch und nutzen Sie %SiteKioskPath%\ als Zielpfad. Stellen Sie sicher, dass Sie das Überschreiben von bestehenden Dateien auswählen. Jetzt selektieren Sie bitte Ausführbare Datei starten als Aktionstyp und klicken auf Hinzufügen, um einen zweiten Auftragsschritt zu erstellen. Nutzen Sie wscript.exe "%SiteKioskPath%\win7ie10fix.js" als Befehlszeile. Stellen Sie dann Sichtbare Ausführung mit Benutzerrechten ein. Als optionalen Schritt können Sie noch den Exit-Code auf einen Wert von 0 setzen und dies als erfolgreiche Ausführung markieren. Speichern Sie die neue Vorlage und weisen Sie diese Ihren Windows 7 Maschinen zu.

 

Falls Ihr Rechner bereits von dem Problem betroffen ist und sich in einer Startschleife befindet, können Sie die in diesem FAQ-Artikel aufgeführten Instruktionen verwenden, um das System zurückzusetzen: http://www.provisio.com/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=60.

Solutions to Fix the Compatibility Issue with SiteKiosk and IE10 on Windows 7

The compatibility issue that affected SiteKiosk versions 7.1 to 8.6 under Windows 7 systems with Internet Explorer 10 (Windows 8 systems are not affected) has been fixed in SiteKiosk version 8.7 and higher. The recommended solution to the problem is therefore to update SiteKiosk to at least version 8.7. This update is free for all users that already run a previous version 8 of SiteKiosk and for all customers with SiteKiosk 7.8 that have bought their license since August 2011.

Customers who cannot or do not want to update to SiteKiosk 8.7 or higher can use the following solutions to fix the problem:

  1. 1) Download the small fix we provide here on our website and then just run the executable.

    You can also run the fix silently via the command line if you use the /s parameter (IE10patch.exe /s).

    NOTE: User who are running SiteKiosk 7.1 under Windows 7 64Bit systems need to update to at least SiteKiosk 7.5 before applying the fix.

  2. 2) The second solution is available for all users who use www.siteremote.net to remotely manage their kiosks or use their own SiteRemote server. When you log in to your team on www.siteremote.net and go to the Jobs tab you will find a new system job template named Windows 7 IE 10 Fix. Apply this job to your Windows 7 terminals, make sure to read the job description first.
    The following only applies to customers who run their own SiteRemote server. Customers with their own SiteRemote server can create the above job template themselves. Under a team on the SiteRemote server go to the Jobs tab and at the bottom of the page click on the New Template button. Use a job name and description as desired and set the client type to SiteKiosk. Select File Upload as action type and click on Add. Upload the win7ie10fix.js from this zip archive and use %SiteKioskPath%\ as destination path. Make sure to select to overwrite existing files. Next select Run Executable as action type and click Add again to create a second job step. Use wscript.exe "%SiteKioskPath%\win7ie10fix.js" as the command line. Select Visible execution with user rights. As an optional step you can select Evaluate the process's exit code, set the value to 0 and use completed successfully. Save the job template and assign it your Windows 7 machines.

 

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

Compatibility Issue with SiteKiosk and IE10 on Windows 7 Resolved

We just released SiteKiosk 8.7 which fixes a bug that occurs when SiteKiosk is used on a Windows 7 system with Internet Explorer 10. Under the restricted SiteKiosk user the SiteKiosk browser may not be able to start properly because of problems with the new Webcache folder introduced by IE10.

You can download SiteKiosk 8.7 from here.

A list of all new features and bug fixes can be found here.

 

It is recommended to upgrade to SiteKiosk 8.7. Users who for whatever reason do not want to upgrade should not install Internet Explorer 10 on Windows 7 systems. Microsoft provides a toolkit to prevent systems from automatically receiving the IE10: http://www.microsoft.com/en-us/download/details.aspx?id=36512.

 

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

 

Please note that Windows 8 with IE10 was not affected.

Compatibility Issue with SiteKiosk and IE10 on Windows 7

We are currently investigating a SiteKiosk startup issue that occurs when SiteKiosk is used on a Windows 7 system with Internet Explorer 10. Under the restricted SiteKiosk user the SiteKiosk browser may not be able to start properly because of problems with the new Webcache folder introduced by IE10.

 

It is recommended to not upgrade to Internet Explorer 10 on Windows 7 systems. Microsoft provides a toolkit to prevent systems from automatically receiving the IE10: http://www.microsoft.com/en-us/download/details.aspx?id=36512.

 

We are working on this issue and try to resolve it as soon as possible.

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

 

Please note that Windows 8 with IE10 is not affected.

Changing the User Agent of the SiteKiosk Browser

The user agent string is used to identify the browser with which a client contacts a server. This information can be utilized to decide what kind of content is delivered to the client in return, to make sure the browser receives data that is optimized for exactly that type of browser. 

SiteKiosk uses the public WebBrowser control of the Microsoft Internet Explorer installed on the system. This means that SiteKiosk identifies itself with the same user agent string as the IE. When a standard configuration is used SiteKiosk will add SiteKiosk Version Number at the end of the user agent string, e.g. SiteKiosk 8.6.1251. A full user agent string under SiteKiosk will look like this:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SiteKiosk 8.6 Build 1251)

Adding SiteKiosk to the user agent can be used for example to let a server deliver SiteKiosk Object Model code to a client. You can deactivate this behaviour in the SiteKiosk configuration and you can also add your own identifiers. You can find more information on this topic here: http://www.provisio.com/helpconsole/SiteKiosk%20Help/en-US/default.htm?advanced_settings.htm#three.

Ideally the above means that your client browser receives the content it is supposed to display in the most suitable form. If a kiosk project is created from scratch, the content can be optimized to fit the kiosk. Even in projects where content has already been created, it will usually run without modifications on the kiosk, because the content has already been designed for usage in a standard browser like IE.

In some cases though, it might come in handy if your browser could pose as something completely different, for example in a kiosk project where touchscreens should be used. The web pages that should be displayed are already existing in a version for normal browsers and in a version for mobile phones. The mobile phone version would fit perfectly but the server dynamically delivers its content based on the user agent. This means on a normal Windows system you would get the version for standard desktop browsers and not the version for mobile phones. The solution is to completely change the user agent string to one of a mobile phone.

Microsoft already provides this option by means of editing the Windows registry using the registry editor (regedit.exe). Note that changing the registry is always done at your own risk. Making the browser pose as another may also cause script errors or corrupted page layouts. You should carefully experiment with the values described next before applying it to live systems.

The registry key we will have a look at is for the Internet Explorer, but as SiteKiosk is based on the Internet Explorer it also uses it. That means changing the key will change the behaviour for IE and SiteKiosk. A detailed article on the topic of the user agent string on Windows systems can be found here: http://msdn.microsoft.com/en-us/library/ms537503%28v=vs.85%29.aspx. The registry key can be found at two different locations in the Windows registry.

One location is under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Note: on a 64-Bit system the location is slightly different

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key changes the behaviour for all users on the system.

The other location is under

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key only changes the behaviour for the current user. This means to edit this key you must be logged in with the user you want to change the behaviour for.

On most systems the above key only contains the default value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Default). For the desired effect we need to add two additional string values (unless they are already there). One is called Platform and the other Version. As an example we will add the following data to Platform (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Platform)

Linux; U; Android 4.0.4;

and the following data to Version (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Version)

AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

These are values an Android smartphone uses. When the changes are done, we can see the effect by opening the SiteKiosk browser (or IE, as both are using that registry key) and going to www.nytimes.com. With the changes we will be directly transferred to the mobile version of the page. The SiteKiosk user string now looks like this:

Mozilla/5.0 (compatible; AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30; Linux; U; Android 4.0.4;; Trident/5.0; SiteKiosk 8.6 Build 1251)

If the above workaround is suitable for your project and you want to spare yourself the hassle of manually editing the registry on all your kiosk systems, you can use the SiteKiosk ProgramPatcher tool to automatically apply the registry changes.

Starting the SiteKiosk File Manager from a Link

The SiteKiosk file manager is usually started from the Start button in the task manager or the programs page. But it can be handy to start the file manager from a link or button link, especially when using the SiteKiosk Portal Startpage.

The file manager is built using HTML, but because of its capabilities it is hosted in a special dialog window. As a consequence just starting the selector.html, which is the base file for the file manager, is not an option. You can of course edit the code of the Portal Startpage, but there is a much simpler approach to it. We will just create a simple html page that will take care of opening the file manager. You can either put the file on the local machine (recommended location: ..\SiteKiosk\html\) or a web server and then create a new link in the settings of the Portal Startpage that uses this page.

Our example page will consist of two methods. The first one is not really required to start the file manager, but it will make the process more complete. It basically checks if SiteKiosk payment options are used and if they apply to starting the file manager. If that should be the case the process of opening the file manager will be aborted and the SiteKiosk payment information dialog shown. More information about this part of the code is available here. Now this is what the first method looks like:

function OpenMediaWindow()
{
	try
	{
		var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
		if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
		{
			OpenIntWindow();
		}
		else
		{
			SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
		}
	}
	catch (e)
	{
		OpenIntWindow();
	}
}

As you can see in the above code, it tries to open another method named OpenIntWindow once the prerequisites are met (or in case of an error, when it goes to the catch part). The OpenIntWindow method deals with opening the actual file manager window. It looks like this:

function OpenIntWindow()
{
	var WS_OVERLAPPED = 0x00000000;
	var WS_MAXIMIZEBOX = 0x00010000;
	var WS_MINIMIZEBOX = 0x00020000;
	var WS_THICKFRAME = 0x00040000;
	var WS_SYSMENU = 0x00080000;
	var WS_BORDER = 0x00800000;
	var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
	var WS_MAXIMIZE = 0x01000000;
	var WS_MINIMIZE = 0x20000000;
	var WS_POPUP = 0x80000000;
	var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
	var WS_EX_TOOLWINDOW = 0x00000080;

	var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
	mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
	mediabox.Styles = 13565952;
	mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
	mediabox.Width = screen.width > 800 ? 1024 : 800;
	mediabox.Height = screen.height > 600 ? 700 : 550;
	mediabox.ExStyles = 0;
	mediabox.Border = true;
	mediabox.Type = "FileManagerDlg";
	mediabox.TopMostWindow = false;
	mediabox.CloseOnInput = false;
	mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
	mediabox.ShowDialog();

	window.close();
}

The first part of the method sets the different window styles used for the file manager dialog. The second part creates an HTML dialog object (SiteKiosk.SiteKioskUI.CreateHTMLDialog();) and assigns window styles, height, width etc. to it. You can learn more about this part here in the SiteKiosk Object Model help. The last line of the method tries to close the window or html page is using now that it has done its purpose of opening the file manager. This will of course only work if the link opened in a new window, which is the default behaviour for the SiteKiosk Portal Startpage.

Now we just put the two methods together and place it in some simple HTML. This is what we get:

<html>
	<script type='text/JScript'>
		window.external.InitScriptInterface();

		function OpenMediaWindow()
		{
			try
			{
				var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
				if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
				{
					OpenIntWindow();
				}
				else
				{
					SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
				}
			}
			catch (e)
			{
				OpenIntWindow();
			}
		}

		function OpenIntWindow()
		{
			var WS_OVERLAPPED = 0x00000000;
			var WS_MAXIMIZEBOX = 0x00010000;
			var WS_MINIMIZEBOX = 0x00020000;
			var WS_THICKFRAME = 0x00040000;
			var WS_SYSMENU = 0x00080000;
			var WS_BORDER = 0x00800000;
			var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
			var WS_MAXIMIZE = 0x01000000;
			var WS_MINIMIZE = 0x20000000;
			var WS_POPUP = 0x80000000;
			var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
			var WS_EX_TOOLWINDOW = 0x00000080;

			var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
			mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
			mediabox.Styles = 13565952;
			mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
			mediabox.Width = screen.width > 800 ? 1024 : 800;
			mediabox.Height = screen.height > 600 ? 700 : 550;
			mediabox.ExStyles = 0;
			mediabox.Border = true;
			mediabox.Type = "FileManagerDlg";
			mediabox.TopMostWindow = false;
			mediabox.CloseOnInput = false;
			mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
			mediabox.ShowDialog();

			window.close();
		}
	</script>
	<body onload="OpenMediaWindow();">
	</body>
</html>

Note the extra line at the beginning of the script part (window.external.InitScriptInterface()). It tells SiteKiosk that SiteKiosk Object Model code follows. If you allowed this page to use such code, it will be executed. Once the page is loaded it calls the first method using onload. The script checks whether payment is required and then opens the file manager (or the payment information dialog).

That's it. The above should help in all cases, where you want to start the file manger from a link/button link. This includes the SiteKiosk Portal Startpage but could even used on any html page, including pages located on the Internet.

Please be aware, that you should activate the file manager in the configuration of SiteKiosk to make full use of this code example.

Manipulating the DOM with the SiteKiosk Object Model

Web pages that are used for a kiosk project are often ones that have been created before the kiosk project started and have not necessarily been created with kiosk usage in mind. In most cases this does not matter. But sometimes the requirements of a kiosk project may ask for special handling if a page is displayed on a kiosk (e.g. change button size). Ideally the web pages are then adapted, but this may not always be possible, e.g. because direct access to edit the pages is not possible.

With the help of the SiteKiosk Object Model pages displayed within the SiteKiosk browser (Internet Explorer engine, for the Chrome variant please have a look here) can be altered by directly editing the DOM of a page. For that you need to look at the source code of a page, e.g. by using the developer tools of IE, Chrome or Firefox, and find the appropriate places that need to be changed.

The following example demonstrates this by changing the Google page to show SiteKiosk as the search term and to use 'Search for SiteKiosk' as the caption of the search button. Copy the code example to Notepad and save it as a .js script file with whatever name you like, e.g. manipulatedom.js. Open the SiteKiosk configuration, go to Start Page & Browser or Browser Design (depending on the SiteKiosk version you are using), click on the Advanced button and add the script as an external script file. Save the configuration, start it with SiteKiosk and go to www.google.com to see the effect.

SiteKiosk.Logfile.OnMessage = OnMessage;
function OnMessage(seq, time, utcoff, awtype, awlevel, facility, text)
{
    if(text.indexOf("Navigation:") !== -1 && text.indexOf("google.") !== -1)
        evtid = SiteKiosk.Scheduler.AddDelayedEvent(1000, ManipulateDOM);
}
 
function ManipulateDOM()
{
    for (var i=1;i<=SiteKiosk.WindowList.Windows.Count;i++)
    {
        try
        {
            if(SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.LocationURL.indexOf("https://www.google.") !== -1)
            {
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('q').item(0).value = "SiteKiosk";
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('btnK').item(1).value = "Search for SiteKiosk";
            }
        }
        catch(e)
        {
            //SiteKiosk.Logfile.Notification("Editing the DOM failed for window: " + SiteKiosk.WindowList.Windows(i).ItemText); //Debug
        }
    }
}

The for part of the above code goes through all open windows to find the one that shows the Google page and apply the code.

Note that when using the above example you should make sure to take care of local laws, ownership rights, copyright etc. Also note that the above example only works as long as Google does not change the code of their page.

Securing the SiteKiosk browser with Microsoft EMET

SiteKiosk uses the browser engine of the installed Internet Explorer to render web pages. To minimize security risks you should therefore keep the Internet Explorer updated by using the automatic Windows Update feature that comes with the operating system.

Unfortunately there is the risk of so called zero day attacks. There was one just recently that affected the Internet Explorer and was covered extensively in the media. Because SiteKiosk uses the Internet Explorer engine it is also affected. While the security features of SiteKiosk do limit the attack options to a certain degree a possible risk remains.

It is also notable that one aspect of zero day attacks is, that even antivirus software does not help as a required signature update takes its time to become available.

This is where Microsoft EMET or Enhanced Mitigation Experience Toolkit comes in. The toolkit can be used to harden an application so that flaws cannot be used as easily and zero day attacks have no or a more limited effect. It is free to use and easy to configure.

When you install EMET make sure to select to install it for all users. After the installation is finished you can just add the SiteKiosk.exe and other applications you want to protect using EMET in the EMET configuration. That's it. You can keep on using SiteKiosk as you did berfore, but now with the extra protection that EMET provides.

How to Build a Script Watchdog for External Applications

The secure SiteKiosk browser offers an easy way to run external applications from within the restricted SiteKiosk context. You can just add the desired applications with the help of the SiteKiosk configuration. SiteKiosk will then provide means to start the applications through the SiteKiosk browser interface, it will also close these applications when the screensaver starts or a user logs out. The configuration of SiteKiosk even allows you to automatically start an application when SiteKiosk starts, the screensaver ends or after a user logout happend.

There can be situations where you may want to have even more control of the external application you want to run with SiteKiosk. For example you don't want to use the browser features of SiteKiosk but just want to use SiteKiosk to protect the operating system from being tampered with and your main goal is to permanently run a specific application.
The culprit is that this may be an existing application that for example allows to user to close it. This is where the SiteKiosk Object Model comes in. It is a proprietary Javascript extension that enables you to control nearly all aspects of SiteKiosk but also comes in very handy to create helpful custom scripts.

Let's summarize what we want to achieve with the script we are about to create. SiteKiosk should run in fullscreen mode in the background and on top of that an external application should always be visible.

The first step would be to create a blank page for SiteKiosk running in the background, alternatively you may of course as well use a page with a nice design. Here is the code for the blank page:

<html>
    <head>
    </head>
    <body>
    </body>
</html>

Save it as background.html (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Next is the Javascript that we use to control the application. The first step is to start the application. For that we are using the Run method of the ExternalApps collection. Because we do need that code later on again, we will put it in a function:

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\pathtomyapplication\\myapplication.exe", true);
}

The Run method basically expects the path to the application plus a boolean value that specifies if SiteKiosk is to check first if this application is already running. If it is already running, it will be maximized and focused. For the purposes of this script the boolean value should be true to ensure that no additional instances of the application are started.

SiteKiosk or the SiteKiosk Object Model cannot prevent the user from closing an application that provides the user with options to close it. Therefore we now need the code that monitors the application.

We will use the OnRemove event of the WindowList object. The OnRemove event fires whenever an application window (this means every Window that produces a tab in the Windows task bar) is removed. We assign a function to the OnRemove event, in this case also named OnRemove.

That function receives a parameter that is a WindowInfo object and includes information about the window that has just been closed. We use the ItemText property of that object to check if the window title of the window that has just been closed is from the monitored application. If that is the case our application has just been closed and we need to start it again, for that we call the function we already created that start our application. The code for all this looks as follows:

SiteKiosk.WindowList.OnRemove = OnRemove;

function OnRemove(skwin){
    if(skwin.ItemText === "WindowTitleOfApplicationToWatch"){
        StartMyApp();
    }
}

Depending on the speed of the process to start SiteKiosk and the application at the same time or the time the application needs to fully close, the application may not have the focus or start at all. To prevent this from happening we can add a slight delay to starting the application, you may need to test what the best timing is for your individual application. We add the AddDelayedEvent method of the Scheduler object to our controlapp.js script at all the places we want to start the application:

SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp);

We are done. When we put the parts together the complete code of our script looks like this:

SiteKiosk.WindowList.OnRemove = OnRemove; //fires if a window has been closed
SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp); //starts the desired application the first time after 5000 ms

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\windows\\notepad.exe", true);
}

function OnRemove(skwin){
    //checks if the application that should run has been closed
    if(skwin.ItemText === "Untitled - Editor"){
        //the application has been closed, restart it again
        SiteKiosk.Scheduler.AddDelayedEvent(500, StartMyApp); //starts the desired application the next time after 500 ms
    }
}

Save the code as controlapp.js (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Now open the SiteKiosk configuration tool and create a new configuration. Set a password, set the background.html file as your start page and then go to Browser Designs, click on Fullscreen and set SiteKiosk to use the permanent fullscreen mode. Still under Browser Designs click the Advanced button and add the conrolapp.js file as an external script (optional: on the same configuration page tick the option to 'Keep the SiteKiosk main window in the background').

Save the configuraion and test the script.

 

Another possibility is creating an external script that checks if the application EXE process is running in regular intervals.

For this you basically need the following methods:
- AddPeriodicEvent Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?scheduler_addperiodicevent_mth.htm
- IsProcessRunning Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_isprocessrunning_mth.htm
- Run Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_run_mth.htm

The following example script will check if the “notepad.exe” process is running every 30 seconds (30000 ms).
If it is not running it starts notepad.exe again.

evtid = SiteKiosk.Scheduler.AddPeriodicEvent(30000, checkExecution);

function checkExecution(eventID){
   if (SiteKiosk.ExternalApps.IsProcessRunning("notepad.exe") == false){
    SiteKiosk.ExternalApps.Run("C:/Windows/notepad.exe", true);
    SiteKiosk.Logfile.Notification('Application started');
    }
}