Cybele Software, Inc. announces the release of ThinRDP 2.0, the industry-leading tool for secure, high-performance, remote access to desktop sessions and terminal services using any modern Web browser. ThinRDP 2.0 enables mission-critical business continuity by providing remote users the most flexible technology to remotely access their programs, documents, files, and network resources.

With ThinRDP 2.0, users can choose any access device they prefer, including iPhones, iPads, Android tablets and devices, ChromeBooks, PCs, Macs, Linux desktops, RIM playbooks, and even locked-down workstations. Regardless of the end-point device, ThinRDP provides secure access and a consistent, intuitive user experience.

In addition to supporting the widest variety of devices in the industry, ThinRDP 2.0 works with every major Web browser, including Chrome, Safari, Internet Explorer, Firefox, and all other browsers that support HTML5 and WebSockets. ThinRDP 2.0 has built-in intelligence to switch automatically to HTTPS if WebSockets are not available, for example in Android native browsers and Microsoft IE9.

ThinRDP 2.0 runs wholly inside the browser: there is never any need to install or configure Flash, Java, ActiveX, Silverlight, or any other software on the end-point device. ThinRDP 2.0 is fully integrated with SSL VPN: no SSL VPN client is needed. ThinRDP 2.0 enables pure Web access to all Windows applications and desktops running Microsoft RDS/Terminal Services and VDI platforms, including Microsoft Hyper-V and other Hyper versions. ThinRDP 2.0 is also integrated with the leading enterprise portals as well as custom portals.

ThinRDP 2.0 sets a new standard for RDP client performance, delivering content dramatically faster than any other Web-based RDP client while generating 25% less network traffic than Microsoft’s own Remote Desktop.

New Features in ThinRPD 2.0:
• Sound: Users of Chrome and Firefox browsers can listen to the sound playing on the remote machine in real-time.
• File transfer: Users can map remote drives to easily exchange files between the remote machine and their portable device.
• Ppdated user interface: The redesigned Start page allows users to quickly assign pre-designed icons to remote computers and/or applications, making ThinRDP more intuitive to use. The connection toolbar simplifies navigation to the remote machine.
• Remote printing: Users can print from the remote host to the handheld device.
• Extended usability: Touchscreen users can use familiar finger gestures to easily page through presentations, quickly scroll through documents, and complete standard navigation tasks.

Visit the ThinRDP Server v2.0 demo.
Read more at: HTML5 Remote Desktop

The post ThinRDP 2.0 Improves Virtual Experience for Remote Users while Providing Industry-Leading Flexibility and Security appeared first on Cybele Software.

We’re getting very close to the official release of a series of new products and we thought that it would be a good time to update everyone on where Cybele Software, Inc. is heading and what you can expect next.

It’s been over 4 years since we introduced the first member in our line of Thin products and we must now recognize what an amazing journey it’s been! We’ve still got a long way to go in our vision of providing the best remote desktop access technologies, but we’re making steady progress towards that goal.

During these years our team and expertise have grown to deliver upon our users’ evolving requirements in advanced remoting and integration technologies. We have striven to provide our customers with the very best products and support we could possible offer.

Today we would like to announce our new product brand: Thinfinity^®. This new identity preserves all of the existing values of what our original one stands for, while simultaneously moving the brand forward. It’s an exciting time for us at Cybele Software, Inc. and we hope you enjoy the new changes coming your way.

The decision to renew ThinRDP, ThinVNC and WebFMX products was brought about by some major changes that have taken place within the company over the last few years. These changes have included new goals, new strategies and new technological breakthroughs, as well as an increase in effective cooperation with other players in the market.

We pride ourselves on developing some of the most innovative, cutting-edge technologies in the markets we serve and this rebranding will mark the beginning of a new phase for us. We believe this change demonstrates the global innovative community our ongoing commitment to provide the most effective remoting, integration and emulation solutions.

Stay tuned for some other exciting announcements coming shortly a well. In the coming months we will be announcing new and exciting products that will continue delivering the simplest implementation pathways possible, while safeguarding the integrity and security of your existing environments. Your feedback is more than welcome!

  Mauro C. Amor, Business Director, Cybele Software, Inc.

About Cybele Software, Inc.

Cybele Software is a leading provider of software solutions that enable companies to extend their existing technology foundation by integrating with trend-setting technology innovations. Since 2002, Cybele Software, Inc. has enabled companies to bridge the gap between cutting-edge technologies and proven client/server and mainframe systems. Its team of experienced developers strives to deliver flexible software solutions that increase the efficiency and portability of remote desktop access and legacy systems.

More information about Cybele Software, Inc. is available at http://www.cybelesoft.com/

The post Coming soon… Thinfinity® appeared first on Cybele Software.

The New Thinfinity® Remote Desktop Brings Unparalleled Performance to HTML5-based Clientless Remote Access to Windows Desktops -Cross-browser, Cross-device.

For Immediate Release

WILMINGTON, DE, October 28, 2014—Cybele Software, Inc., the leading innovator of web-based remote access software solutions, announced today the release of Thinfinity® Remote Desktop, its latest solution to remote Windows desktop access.

Thinfinity® Remote Desktop delivers dramatic improvements in productivity, technology and user experience innovations. This new product offers a seamless, over 20% faster performance than its two predecessors, ThinRDP and ThinVNC.

Among other exciting new features and improvements, Thinfinity® Remote Desktop now provides support for Microsoft® RemoteFX™, enabling a fast and enhanced visual experience of the Windows desktop. It also offers multi-touch input redirection, which allows users to send the input of up to ten simultaneous fingers to be interpreted in the remote OS.

Also new in this release, is the possibility to record remote desktop sessions for later playback from within the Thinfinity® Remote Desktop web interface.

Now, every configured connection can have its own URL, allowing for the creation of shortcuts for rapid and simplified end-user’s access to remote desktops and apps.

Thinfinity® Remote Desktop is available in two versions: Server and Workstation, each one of them aimed at users’ specific needs.

New features and enhancements

Over 20% faster than previous versions (ThinRDP / ThinVNC)

Support for Microsoft® RemoteFX™, enabling fast, enhanced visual experience of the Windows desktop

Multi-touch input redirection. Send the input of up to ten simultaneous fingers to be interpreted in the remote OS

Specific to Server edition:

 Record Remote Desktop (RDP) sessions and play them back from within the Thinfinity® Remote Desktop web interface

 Create shortcuts to any configured connection

Integrate the Thinfinity® RDP authentication with the RADIUS system

Populate Microsoft RD Web Access links

Store Analytics data in MS-SQL database

Specific to Workstation edition:

 Remote Desktop (RDP), Screen Sharing and File Transfer

 “Automatic” mode, that chooses between Remote Desktop and Screen Sharing taking into account the presence of a user on the remote machine

 Persistent configuration on per user basis

Check out the full Feature list. For Architecture and Specifications, please check here

Contact

For more information about Thinfinity® Remote Desktop contact Cybele Software, Inc.

3422 Old Capitol Trail, Suite 1125,

Wilmington, DE – 19808, USA.

Phone: (302) 892-9625 or (866) 462-9768

Email: info@cybelesoft.com

Website: www.cybelesoft.com

The post [Press Release] Cybele Software Inc. unveils its new Thinfinity® Remote Desktop -available in Server and Workstation editions appeared first on Cybele Software.

Application integration in a web environment could require several instances of authentication, which sometimes can lead to annoying gaffes and mix-ups. Fortunately, the Single Sign On method will help us achieve the unified authentication of these users in a very simple and straightforward way. Let’s see how to implement it in Thinfinity® Remote Desktop.

What is CAS?

Central Authentication Service (“CAS”) is an authentication protocol, originally written at Yale University, created to provide a trusted Single Sign On (SSO) method for a web application to validate a user. Its purpose is to permit a user to access multiple applications while providing their credentials (such as user name, password, etc.) just a single time. Once the user is authenticated by an SSO, he/she doesn’t need to render his/her security credentials again.

The CASAuth demo

The CASAuth demo, which gets distributed in the product installation, is a simple example you can use to test your CAS authentication environment with Thinfinity® Remote Desktop. You can easily locate it from a shortcut in the Start menu, inside Thinfinity/Remote Desktop Server/Thinfinity Remote Desktop Server Demos. There are some simple but important things you should note along the way, so make sure to follow each step carefully. Let’s start!

In login.aspx.cs you have to replace the CASHOST with the URL of your CAS server. In a testing environment, for example, this might be:

 private const string CASHOST = "https://localhost:8081/cas-server-webapp-4.0.0/";

Make sure you are using a valid certificate so ASP.NET doesn’t reject it. If you don’t have a valid certificate, you can replace the certificate validation function with the following code:

 bool MyServerCertificateValidationCallback(object sender,
      X509Certificate certificate, X509Chain chain,
      System.Net.Security.SslPolicyErrors sslPolicyErrors)
 {
      return true;
 }

and then assign this function to the ServicePointManager.ServerCertificateValidationCallback:

 ServicePointManager.ServerCertificateValidationCallback = MyServerCertificateValidationCallback;

If everything went as planned, these changes would ensure your CAS server is reached and, in case you are not already logged in, you would be redirected to this server to validate the user.

We now need to make some changes in the Default.aspx.cs page. At this point you have to replace the value of APIKey variable with the appropriate one from your environment. This variable is in the server ini configuration file. (Note: for information on how to find it please refer to: http://www.cybelesoft.com/helps/thinfinity/remote-desktop/server/apikey.html).

Also, you will notice that the dhc.Init method is being called. You have to replace the value passed to this function with the URL needed to reach your Thinfinity Remote Desktop server. Be careful! You need to make this change in the Default.aspx page too:

<iframe src="http://localhost:8443/asp/?*<%=encQuery%>" width="300" height="150"></iframe>

replacing http://localhost:8443 with the actual URL of your Thinfinity Remote Desktop Server.

Finally, there is a very important setting in this example that needs to be addressed. In Thinfinity Remote Desktop users can get access by using some methods related with the Single Sign On (SSO) feature. Currently, two SSO methods are implemented: Google’s OAuth authentication and Radius authentication. An alternative option is to authenticate directly through Active Directory or using the Windows user authentication.

One of the last lines in Default.aspx.cs states

encQuery = HttpUtility.UrlEncode(dhc.EncodeStr("_userid=" + Userid + "&_apikey=" + APIKey + "&_ssologin=1"));

On that line you have a very important setting: _ssologin. The use cases for this parameter are:

(More info at http://www.cybelesoft.com/helps/thinfinity/remote-desktop/server/single-sign-on.html)

With all these settings correctly established, you will be able to use CAS as the authentication method for your Thinfinity Remote Desktop-enabled solution.

The post Implementing Single Sign-On authentication: How to use CAS with Thinfinity® Remote Desktop appeared first on Cybele Software.

Thinfinity Remote Desktop Workstation vulnerability: Summary

Thinfinity Remote Desktop Workstation v3.0.0.3 includes the following vulnerability:

A generic directory traversal flaw was found. After testing both Thinfinity Remote Desktop Workstation version 3.0.0.0 and version 3.0.0.3, the flaw is only present in the later version.

Successful exploitation of this vulnerability could result in the possibility of downloading a file off the remote Windows host (i.e. via the default port 8081 or whichever other port it is configured to use). The flaw was present whether or not “File Transfer” was enabled -regardless of the security mode in use (i.e. None, Digest or Windows Logon).

Note: This vulnerability does not affect Thinfinity Remote Desktop Server.

We thank Matt Byrne, from Perspective Risk for identifying this issue.

Software Versions and Fixes

Cybele Software has released a free software update (v3.0.0.4) that addresses this vulnerability. The update is available at the following links:

32-bit: http://www.cybelesoft.com/downloads/Thinfinity_Remote_Desktop_Workstation_Setup_x86.exe

64-bit: http://www.cybelesoft.com/downloads/Thinfinity_Remote_Desktop_Workstation_Setup_x64.exe

Make sure to uninstall the previous version before installing the new one.

Policy Statement on Information Provided in Patch Updates and Security Alerts

When Cybele Software publishes a Security Bulletin, the company intends to provide vulnerability information in a socially responsible way. Cybele Software does not intend to issue vulnerability details that could enable someone to craft an exploit.

As a matter of policy, Cybele Software will not provide additional information about the specifics of vulnerabilities beyond what is provided in the Patch Update or Security Alert notification, the readme files, and FAQs. Cybele Software provides all customers with the same information in order to protect all customers equally. Cybele Software will not provide advance notification or “insider information” on Patch Update or Security Alerts to individual customers.

If you have any questions, you can reach us at security@cybelesoft.com.

The post Cybele Software, Inc. Security Bulletin appeared first on Cybele Software.

A basic rule in Web security holds that there is no direct javascript access between different windows loaded in a browser unless these windows are not from the same origin. This means that the windows must share protocol, host and port or it will not be possible to access a value or object on another page from the JavaScript code, or to add content. So, how can we establish and maintain the communication between different pages loaded in a cross-domain environment?

Fortunately, benefiting from the window.postMessage API, the windows can send non intrusive messages to each other via javascript in a cross-domain environment. These messages can be text, or an object in JSON format (JavaScript Object Notation) —something already available in most of modern web browsers.

In this article we will show how to apply this API to send cross-domain messages using Javascript in a secure way.

The window.postMessage API

In order to send a message to another window, one must invoke a postMessage() method, introduced below:

1

targetWindow.postMessage(message, targetDomain, [extra])

where:

But if a tree falls in a forest and nobody’s around to hear it, does it make a sound? In other words, it is useless to send the message if no one is prepared to listen to it. In order to be heard, the event message must be attended. Although most modern web browsers employ the addEventListener() method to add the treatment of the event, old IE versions makes use of its own; so we will cover both alternatives:

1
2
3
4
5

if (window.addEventListener){
    addEventListener("message", listenerFunction, false)
} else {
    attachEvent("onmessage", listenerFunction)
}

Where listenerFunction will be used to process the message coming from another window. This function will receive the message in the data attribute of the event received:

1
2
3
4
5
6
7

function listenerFunction(e) {
    if (typeof e.data == "string") {
        console.log(“The message is a text: ” +  e.data);
    } else {
        console.log(“The message is a JSON object:” + JSON.stringify(e.data));
    }
}

Some considerations regarding security

Cross-window messaging security model is two-sided. In the event of knowing the domains of the both parties involved —which is usually the case—, and in order to make the exchange of information between different domains safer, it is recommended to check, both when sending and receiving, the domains that participate in the messaging exchange. The sender ensures that the receiving domain is targetDomain. If the sender tries to send a message to a domain different to targetDomain, an error will occur.

The receiver can check the origin attribute of the received message event object to make sure that this came from a valid origin. Therefore, if the domain of origin does not match a valid domain, it can be ignored.

Let’s do it!

The following example implements cross-domain communication between two pages: one loaded in the localhost domain, and the other one in IP 127.0.0.1. To handle the exchange of messages we will create two javascript classes (MessageSender and MessageReceiver).

The MessageSender class has a single published method (sendMessage) and, during its creation, it will receive the window to where the message should be sent (targetWindow, mandatory) and the domain to which the message should be directed (targetDomain, optional), which if not received will be replaced by “*”. Both arguments are sent within a JSON object.

1
2
3
4
5
6
7
8
9
10
11
12

var MessageSender = function(args) {
    args = args || {};
    var targetWindow = args.targetWindow;
    var targetDomain = args.targetDomain || "*";
    var ready = false;
    var sendMessage = function(message) {
        targetWindow.postMessage(message, targetDomain);
    }
    return {
        "sendMessage": sendMessage
    }
}

The MessageReceiver class has two published methods. The start method initiates the listening of the message, while the stop method ends it. Both methods could receive a callback function to do an additional processing in the start/stop messaging. This class, when instantiated, is capable of receiving a JSON object with a pair of attributes, both optional. The first is a callback function to process the message; the other, a validOrigin string that indicates the domain from which it would be valid to receive messages. Should any of these parameters is not sent, the first one will be replaced by a default message processor , while the other, by the same page’s domain (i.e., it will not be cross-domain and will only receive messages from its own domain). In case you do not want to control the origin of the message, the validOrigin attribute must explicitly assert “*”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

var MessageReceiver = function (args) {
    args = args || {};
    var started = false;
    var validOrigin = args.validOrigin || window.location.origin;
    var defaultMsgProcessor = function (e) {
        if (typeof e.data == "string") {
            alert("The message is test:\n'" + e.data + "'");
        } else {
            alert("The message is a JSON object:\n" + JSON.stringify(e.data));
        }
    }
 
    var msgProcessor = args.callback || defaultMsgProcessor;
    var processMessage = function (e) {
        if (validOrigin == "*" || validOrigin == e.origin) {
            msgProcessor(e);
        }
    };
    var startListening = function (onStartCallback) {
        if (!started) {
            if (window.addEventListener) {
                window.addEventListener("message", processMessage, false);
            } else {
                attachEvent("onmessage", processMessage);
            }
            started = true;
            if (onStartCallback) onStartCallback();
        }
    }
    var stopListening = function (onStopCallback) {
        if (started) {
            if (window.removeEventListener) {
                window.removeEventListener("message", processMessage);
            } else {
                window.detachEvent("onmessage", processMessage);
            }
            started = false;
            if (onStopCallback) onStopCallback();
        }
    }
    return {
        "start": startListening,
        "stop": stopListening
    };
};

Both classes will be included in the same javascript file, which we will call crossDomainMessenger.js.

In order to use these classes, we will create two html pages. The first one, crossDomainSource.html, includes the crossDomainMessenger.js file and displays, on the top part, a line containing a text field (where the messages to be sent will be added) and some buttons to send messages. At the bottom of this page, the second page will load in an iframe, which would receive the messages.

From javascript, it will create both a MessageSender and a MessageReceiver; the first one to send messages triggered by the buttons to the page loaded in the iframe; and the last one to address messages that could be sent to the internal page.

This second page will also create a MessageSender and MessageReceiver, with the difference that in this case, the important work that will done by the latter.

The page also has buttons to toggle the message listener; a button to clear the list of messages received; and, a last button to send a message to the other page, which would close the communication circuit between the two windows.

Below you will find the code for the two pages of the example:

crossDomainSource.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Cross domain message example - Sender</title>
    <style>
        html, body { height: 100%; margin: 0px; padding: 0px; }
        #divmsg { height: 50px; line-height: 50px; vertical-align: middle; padding-left: 10px; padding-right: 10px; }
        #divtarget, #targetWindow {display: block; position: absolute; }
        #divtarget { top: 51px; bottom: 5px; left: 5px; right: 5px; border: solid 1px; box-sizing: border-box; }
        #targetWindow { width: 100%; height: 100%; border: none; }
    </style>
    <script type="text/javascript" src="crossDomainMessenger.js"></script>
    <script type="text/javascript">
        var msgSender = null;
        var msg = null;
 
        function init() {
            var targetDomain = window.location.protocol + "//127.0.0.1:" + window.location.port;
            var tw = document.getElementById("targetWindow");
            tw.src = targetDomain + "/crossDomainTarget.html";
            msgSender = new MessageSender({ "targetWindow": window.frames["target"], "targetDomain": targetDomain });            msg = document.getElementById("txtmsg");
 
            // Creates a MessageReceiver that accepts messages from targetDomain only
            new MessageReceiver({ "validOrigin": targetDomain }).start();        }
 
        function sendText() {
            msgSender.sendMessage(msg.value);
        }
 
        function sendObject() {
            msgSender.sendMessage({ "message": msg.value, "currentDate": new Date().toJSON() });
        }
 
        function sendClear() {
            msgSender.sendMessage({ "cmd": "CLEAR" });
        }
    </script>
</head>
<body onload="init()">
    <div id="divmsg">
        <label for="txtmsg">Message:</label>
        <input type="text" id="txtmsg" size="30" />
        <input type="button" value="send text" onclick="sendText()"/>
        <input type="button" value="send object" onclick="sendObject()"/>
        <input type="button" value="send clear" onclick="sendClear()"/>
    </div>
    <div id="divtarget">
        <iframe id="targetWindow" name="target"></iframe>
    </div>
</body>
</html>

crossDomainTarget.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Cross domain message example - Receiver</title>
    <style>
        html, body { height: 100%; margin: 0px; padding: 0px; }
        #msgPanel > div { border-bottom: dashed 1px #808080; }
    </style>
    <script type="text/javascript" src="crossDomainMessenger.js"></script>
    <script type="text/javascript">
        var msgSender = null;
        var msgReceiver = null;
        var msgPanel = null;
        function init() {
            msgPanel = document.getElementById("msgPanel");
            // This MessageReceiver accepts messages from localhost only.
            msgReceiver = new MessageReceiver({                "validOrigin": window.location.protocol + "//localhost:" + window.location.port,                "callback": function (e) {                    if (typeof e.data.cmd != "undefined" && e.data.cmd == "CLEAR") {                        clearMsgs();                    } else {                        addMessage("The message is " +                            ((typeof e.data == "string") ?                                "test:\n'" + e.data + "'" :                                "a JSON object:\n" + JSON.stringify(e.data)));                    }                }            });            start();
            msgSender = new MessageSender({ "targetWindow": window.parent });        }
 
        function start() {
            msgReceiver.start(function () { addMessage("*** msgReceiver was started!") });
        }
 
        function stop() {
            msgReceiver.stop(function () { addMessage("*** msgReceiver was stopped!"); });
        }
 
        function clearMsgs() {
            msgPanel.innerHTML = "";
        }
 
        function sendHellow() {
            msgSender.sendMessage(window.location.origin + " says Hello!");
        }
 
        function addMessage(message) {
            var newmsg = document.createElement("div");
            newmsg.innerHTML = message;
            msgPanel.appendChild(newmsg);
        }
    </script>
</head>
<body onload="init()">
    <div>
        <input type="button" value="start" onclick="start()"/>
        <input type="button" value="stop" onclick="stop()"/>
        <input type="button" value="clear" onclick="clearMsgs()"/>
        <input type="button" value="send msg to opener window" onclick="sendHellow()" />
    </div>
    <div id="msgPanel"></div>
</body>
</html>

This is enough to understand how the messaging between windows works, even when they are in different domains. In upcoming posts we will demonstrate how to use this technique to establish a smooth communication between Thinfinity VirtualUI or Thinfinity Remote Desktop with other applications to which they are integrated.

The post How to send cross-domain messages using Javascript appeared first on Cybele Software.

Besides being a powerful cross-device, cross-browser remote access tool, Thinfinity Remote Desktop Server also excels in its integration capabilities and its flexible and easy customization.

A little known fact for those working with Thinfinity Remote Desktop is the existence of customSettings.js. This file provides a way to easily define some global parameters for all remote access connections, regardless of the selected profile. This file, located in the webrdp folder of the installation directory, is an editable javascript that contains a global variable called customSettings.

The customSettings variable uses the JSON format to define a collection of attribute/value pairs with special parameters that are not available in the profile settings:

This collection can be extended with any other attribute of the connect JSON parameter, except for those that are relative to the connection —user, password and computer—. When extending the collection, the overrideDefault attribute must be set to true, as specified in the Thinfinity Remote Desktop connect method reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// GetThinRDP(serverURL, runRemote)
//   Creates a new ThinRDP instance
//      serverURL:  substitute with the ThinRDP server URL (http[s]://[URL - IP]:port/)
//      runRemote:  use to set ThinRDP mode
//          -- false-> local (renders into this page)
//          -- true->  remote (posts connection data to postPage ("connection.html" as default)
  mythinrdp = GetThinRDP("", true);
  mythinrdp.connect({
    targetWindow: "rdpwindow",
    centered: true,
    overrideDefaults: true,    ...
    ...
    ...
  }

When starting a connection, Thinfinity Remote Desktop merges this parameter list with the profile settings, overriding the profile attributes with the customSettings variable values. This is a powerful tool that needs to be used carefully. Therefore, it is recommended to use customSettings.js exclusively to set these special parameters, or when you need a centralized configuration to be shared among the totality of countless profiles. Remember: defining the configuration in each profile is always safer, as well as clearer.

In conclusion, the customSettings global variable offers a way to quickly apply general custom settings that will affect all the connections. More details about this, such as how to customize the toolbar, will be explored in depth in a future post.

The post Applying general custom settings to Thinfinity® Remote Desktop appeared first on Cybele Software.

When we use the term “Integration”, we are not just referring to Thinfinity Remote Desktop’s ability to embed a remote display within a Web application. There are additional integration needs, like those related to resource management. The Thinfinity Remote Desktop Web Services API permits third party applications to access and manipulate historical data, thereby remotely configuring Thinfinity Remote Desktop Server. This API consists of two Web services modules: Access Profiles —for account management— and Analytics —for statistical and analytical evaluation purposes.

The Web Services API

The API uses the SOAP protocol and the integration has to be done at a programming level. In order to consume the web services, the developer will need to develop or modify an application which will act as the Web Service requester by implementing the Thinfinity® Remote Desktop Server Web Service interface, available as a WSDL file.

Access Profiles Web Service

The Access Profiles Web Service allows the developer to manage Thinfinity Remote Desktop Server Profiles, and is valid for Thinfinity Remote Desktop Server installations that use Access Profiles as the authentication mode. This Web Service enables external applications to:

• Retrieve any information about the configured profiles in Thinfinity Remote Desktop Server.
• Create new profiles.
• Modify any information of an existing profile.
• Delete existing profiles.

The Web Service Transaction Manager enables third party applications to execute a series of operations as a single unit of work. By using the commit and rollback transaction statements, the Web Service Transaction Manager will guarantee that the series of operations are either jointly executed, or, alternatively, canceled altogether.

Analytics Web Service

The Analytics Web Service allows external applications to access historical data related to  Thinfinity® Remote Desktop Server logins, sessions, connections and used browsers. This will facilitate the acquisition and analysis of information regarding resources consumption, access modalities and device types.

The Thinfinity Web Services includes demos to show how consume it, and it has its own installation package. Additional information can be obtained by accessing to its reference at the Thinfinity Remote Desktop Server Documentation.

The post Web Services for Thinfinity® Remote Desktop Server appeared first on Cybele Software.

In the previous post we discussed the Thinfinity Remote Desktop Web service modules. In this article, we will show you how to set up the ThinRDPWS-Query web service demo for .Net.

The ThinRDPWS-Query demo

The ThinRDPWS-Query demo was developed in C# to present the many integration possibilities the Analytics Web Service provides you. This application shows Thinfinity Remote Desktop Server activity information concerning logins, sessions, connections and browsers used to access remote computers in several time intervals.

Checking the Web service status and port

Before running the application, please check the Services system dialog to see if the Thinfinity Remote Desktop WebService Admin Tool service is started.

Open the Thinfinity Remote Desktop WebService Admin Tool and verify the port the web service is listening on. In this case, the port is 8499. Also, you can see the service status message at the General tab bottom line.

Setting up the application

Look for the ThinRDPWS-Query solution in the Thinfinity Remote Desktop WebService Demos in the Windows Start menu.

Select the QuerySvc item from the Service References folder at the Solution Explorer and then select the Configure Service Reference… option from the contextual menu.

Please check the client address in the Service Reference Settings dialog, using the ip address (or the hostname) and port the web service is listening on.

Press OK to save the settings.

You are now ready to run the application and look into the statistical information provided by the web service.

Select one of time span options presented in the upper radio buttons to filter the statistic records. Click on any of the available tabs —Logins, Sessions, Connections or Browsers— and press the Refresh button. The analytics data will be displayed on the tab grid.

In a future post we will discuss the Profiles Web Service, completing the web services overview.

The post Using the Analytics Remote Desktop Web Service appeared first on Cybele Software.

Among the wide range of valid resolutions that both Thinfinity Remote Desktop and Thinfinity VirtualUI offer, the most commonly used —because of its flexibility and simplicity— is “Fit to Browser”.

This configuration allows you to adjust the remote desktop / remote application to the available browser size. However, when it comes to accessing a desktop from different devices, the sometimes huge differences between screen sizes and resolutions (i.e. iPhone 4 vs a 27 inch iMac Retina Display) make it impossible to have a simple rule to determine the best remote size. Even when the application is adjusting properly to the available size, the screen rendered might still look tiny or disproportionate, making the user experience not as satisfactory as expected.

Tailoring “fit to browser”

Now, using a new configurable browser detection ruleset, we can tailor the way we want to see of the remote desktop/application on every device. This ruleset allows you to specify rules that will detect the web browser, device and display characteristics, and set the parameters to adjust the remote desktop/application resolution according to your own taste.

The main characteristics that are taken into account are:

• The browser User Agent, that tells about the web browser and device
• The device pixel ratio, that tells about the real display resolution
• The device display size
• The display orientation (landscape or portrait)

The browser detection ruleset is stored in a file with entries that contain specifications (rules) that match general or specific devices. Each entry (model) can inherit matching parameters (properties) from a more general model. For example, you can define an iOS model and an iPhone4 can inherit the iOS model properties.

A default ruleset file named BrowserRules.ini is installed in the corresponding Thinfinity’s program folder. Then, if it doesn’t exist there yet, it is copied to “\programData\Cybele Software\Thinfinity\{product}\” and renamed as Thinfinity.{product}.BrowserRules.ini. (where {product} is either RemoteDesktop or VirtualUI). You can safely customize this file as it won’t be overridden with a program update.

The structure of this file is as follow:

1
2
3
4
5
6
7
8
9
10

[default]
min-width = 640
min-height = 480
max-width = 2560
max-height = 1600
max-device-pixel-ratio = 1
 
[mobile]
parent-model = default
match-mobile = true

Model Inheritance

A section defines a model, and each model contains a set of properties divided in two groups: matching properties and applying properties.

Models are organized in an inheritance tree, The relationship between models is defined by a special property rule called parent-model, present in all models except [default], which is the tree’s root node and includes some base properties.

Every other model must directly or indirectly inherit from the [default] model. Also, each model contains its own rules and inherits all specifications from its ancestors.

When more than one criteria is met for a device, a scoring system is used to resolve this conflict.

Property reference

Properties can be divided in two groups: matching properties and applying properties.

Matching properties are those used to test the browser and device properties (such as the browser user agent, the device pixel ratio, the display orientation width and height, etc.) in order to choose the best model for each case.

Applying properties are those used to determine the final size and resolution.

Use the parent-model property to set the parent model:

The following properties deal with the display resolution:

The following properties deal with the screen size of the remote desktop, in pixels. You can determine it by setting the actual height and width, or by establishing maximum and minimum values for these properties.

The following properties allow you to specify device screen areas that will never be used for displaying the remote connection, such as when a browser or device bar cannot be hidden and uses up screen space. These margins will be excluded for screen size calculations.

Miscellaneous properties (only available to Thinfinity Remote Desktop):

The calculation process

In order to choose a model from the ruleset, Thinfinity uses the client device type, dimensions, resolution, orientation and browser:

1. If match-mobile exists, it tests if device is a mobile.
2. If match-user-agent exists, it tests the browser’s User Agent.
3. If match-device-pixel-ratio exists, it tests the device’s pixel ratio.
4. If match-orientation exists, it tests the device’s orientation.
5. If match-screen-width-range and match-screen-height-range exist, it tests to see if the screen size is in range.
6. If match-screen-width and match-screen-height exist, it tests the exact screen size.

Once the model is selected, the parameters are applied in this way:

1. If the width and height properties exist, then it applies them.
2. If the browser width is less than the min-width, it applies min-width.
3. If the browser height is less than the min-height, it applies min-height.
4. If the browser width is greater than the max-width, it applies max-width.
5. If the browser height is greater than the max-height, it applies max-height.
6. If a specific device-pixel-ratio was specified, it applies it.
7. If a max-device-ratio was specified, it takes the minimum of the real device pixel ratio and max-device-ratio property and applies it.

This example shows a possible ruleset and how it will affect different devices.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[default]
min-width = 640
min-height = 480
max-width = 2560
max-height = 1600
max-device-pixel-ratio = 1
 
[mobile]
parent-model = default
match-mobile = true
max-device-pixel-ratio = 2
 
[ipad]
parent-model = mobile
match-user-agent = ipad
 
[iphone4]
parent-model = mobile
match-user-agent = iphone
match-screen-width = 480
match-screen-height = 320
device-pixel-ratio = 1.5

In this case, when connecting with an ipad, the following models will be matched:

[default]: This model applies to all devices.

[mobile]: The ipad will match the match-mobile property.

[ipad]: The ipad will match the user agent keyword ‘ipad’ specified in the match-user-agent property.

The resulting properties for this device will be:

1
2
3
4
5

min-width = 640
min-height = 480
max-width = 2560
max-height = 1600
max-device-pixel-ratio = 2

Using the same ruleset, when connecting with an iphone4, the following models will be matched:

[default]: This model applies to all devices.

[mobile]: The iphone will match the match-mobile property.

[iphone4]: The ipad will match the user agent keyword ‘iphone’ specified in the match-user-agent property, together with the match-screen-width and match-screen-height properties. An iphone6, with a screen width of 667px, and a screen height of 375px, would match the ‘iphone’ user agent keyword, but not the size.

The resulting properties for this device will be:

1
2
3
4
5
6

min-width = 640
min-height = 480
max-width = 2560
max-height = 1600
max-device-pixel-ratio = 2
device-pixel-ratio = 1.5

Try it yourself to find the best fit for your end-users.

The post Enhanced Browser and Device DPI support appeared first on Cybele Software.

In a previous post we discussed how to apply general custom settings to Thinfinity Remote Desktop Server. Today, we will learn how to customize the Thinfinity Remote Desktop Server toolbar in depth.
By default, the toolbar displays the wider range of options within reach for the end users. But, as an administrator or integrator, you might want to restrict the end user from accessing some of these options, or all of them. Thinfinity Remote Desktop has a method for applying settings to the toolbar so you can tweak it according to your preferences. These settings will be applied before the connection occurs and will affect all users and all connections in the Thinfinity Remote Desktop server installation.

General toolbar customization parameters

The customSettings global variable has two parameters that affect the complete toolbar:

The createToolbar parameter enables the Thinfinity Remote Desktop Toolbar creation. Setting it to false will result in a Thinfinity® Remote Desktop Server connection with no toolbar at all. This might be useful if you want to restrict the user from all the options in the toolbar.

The toolbarVisible parameter defines the initial toolbar visibility. When toolbarVisible is true, the toolbar will appear expanded upon establishing the connection; and when toolbarVisible is false, the toolbar will start collapsed.

Hiding toolbar components

But this is not a black and white world. Maybe you want hide only some of the toolbar options. For example, when connecting to an application you might want to restrict the user to access the task manager by sending the [CTRL]+[SHIFT]+[ESC] keys. Or, perhaps, you might want to enable file transfer for downloading files without providing access to the file manager.

For all of these cases, you have a way to programmatically define the exact toolbar options that will be excluded.

The toolbarRestrictions customSettings property is an array that contains the full name of all the toolbar options you might want to restrict.

The table below shows the complete option name list:

The following example shows how to create the toolbar so that it starts collapsed and without the “File Manager” menu button, the “Image Quality” submenu, the “Share Session” option or the “[Ctrl]+[ALT]+[DEL]” keystroke option:

var customSettings = {
      "createToolbar": true,
      "toolbarVisible": false,
      "toolbarRestrictions": [
            “fileMenuBtn”,
            “optionsMenuBtn.imgQualityBtn",
            “actionsMenuBtn.ssnShareBtn”,
            "actionsMenuBtn.sendKeysBtn.ctrlAltDelBtn"
      ]
}

So far we’ve shown you a centralized way to restrict the toolbar options for all connections and profiles. But what about a dynamic way to apply the toolbar settings?
A dynamic tweaking of the toolbar is also possible. By using the Thinfinity Remote Desktop Javascript API, you can restrict the toolbar options depending on the user that is accessing.
We will learn how to do this in an upcoming post.

The post Customize the Thinfinity Remote Desktop Toolbar appeared first on Cybele Software.

Have you ever wished you could easily review a remote desktop session? Or perhaps you want to show your remote users how to use —or troubleshoot— an application?

Thinfinity Remote Desktop Server helps you to do all this things —and more— allowing you to record and save rdp sessions.

Saving remote desktop sessions

The recording of the session is a profile property. Enable it in the ‘Advanced’ tab of an access profile.

After checking this option, all connections to this profile will be recorded in the server, transparently for the remote user. These recorded sessions will then be available in the Saved Sessions page.

Accessing recorded sessions

Access to the recorded sessions can be granted for users and/or user groups. You can enable users to play saved sessions from the Thinfinity Remote Desktop Server Manager, in the ‘Permissions’ tab. Users can be allowed to play all sessions, or only those recorded by themselves.

A user that has been granted permission to play session recordings will see an extra Saved Sessions icon in the Thinfinity Remote Desktop Server web interface.

When you select this item, you will access the Saved Sessions page.

Playing recorded sessions

In the Saved Sessions page you will see all the recordings that are available according to your permissions. These session recordings can be filtered, deleted and played from the browser.

Press the green ‘play’ icon on the left side of each row to visualize a previously saved session. Recordings that are not closed will show a different recording status and will not be be available for playing.

The image below shows a remote desktop session recording being reproduced. On the top of the screen you can see the recording player. Use the play/pause button to pause visualization, if you want to see a special detail, and then resume it.

The post Remote Desktop session recording with Thinfinity Remote Desktop Server appeared first on Cybele Software.

Cybele Software has been providing web-based remoting solutions since the first HTML5-cabable browsers appeared in the market. The newly launched Thinfinity Remote Desktop Workstation now reunites the VNC-like desktop sharing features of the well known ThinVNC and the powerful RDP capabilities of the old ThinRDP Workstation on a single tool.

Thinfinity Remote Desktop Workstation is the anwser you’ve been looking for. It not only provides web VNC & and web RDP with a smooth performance, it’s FREE!

– FREE web RDP and VNC-like client
– Remote desktop control and screen sharing, all in one
– Remarkably simple to set up

You should definitely adopt our our new free web RDP client. The setup is easy a a pie. The configuration has no big secrets, and we provide a step-by-step guide for non tech users.

Select the RDP mode to enjoy full remote desktop access to your Windows programs, documents and network resources. Or, select the VNC mode and start a desktop sharing session. Invite your mates to join in the remote session. They can even control your mouse and keyboard. The possibility of sharing a remote session makes the Workstation ideal for remote support and collaborative activities.

Web-based Screen Sharing and HTML5 Remote Desktop Technical Highlights

– It does not require ANY other setup on the end-user side (web browser)
– Works with all HTML5-compliant web browser
– Supported by Internet Explorer 9, Firefox, Chrome, Safari and others
– Remote Printing
– Remote Audio
– File Transfer
– High-performance, firewall-friendly
– Compatible with 32-bit/64-bit versions editions of Windows

Thinfinity Remote Desktop Workstation it’s a great cross-browser, cross-platform access tool. All major browsers support HTML5 technology nowadays. Any Windows, Mac OS X, Linux, Android or iOS user can connect remotely into their Windows desktops through their favorite browser.

Meet the best web based remote access solution…

Quick to install, easy to use, free to enjoy!

Try our software today!

Product page: http://www.cybelesoft.com/thinfinity/remote-desktop/workstation/
Form to request a free license (it’s a serial key generated automaticaly, sent by email): http://www.cybelesoft.com/thinfinity/remote-desktop/workstation/free-license.aspx
Download the User Guide: http://www.cybelesoft.com/docs/Thinfinity_Remote_Desktop_Workstation_Guide.pdf
Download link: http://www.cybelesoft.com/downloads/Thinfinity_Remote_Desktop_Workstation_Setup_x86.exe 

Already a user? Feel free to share your feedback with us!

The post Need web-based Screen Sharing and Remote Desktop? appeared first on Cybele Software.

After upgrading to the new Windows 10, some Thinfinity Remote Desktop Workstation users reported that our HTML5 RDP solution shows a “License could not be loaded” status.

Why does this happen?

Old Thinfinity Remote Desktop Workstation versions implemented a license system that uses some local hardware and software values to create a digital fingerprint. Since this is uncritical but unrepeatable information, it is ideal to be used for identification purposes when attached to the final license data.

Windows 10 installation changes some of the original PC values, causing the mentioned error when Thinfinity Remote Desktop Workstation tries to verify its license information.

From version 3.0.0.11 and up this is no longer an issue, so we recommend to upgrade your Thinfinity Remote Desktop Workstation version to the latest one. If you are using versions 3.0.0.10 or earlier, here is how to avoid having this problem and what to do if it already happened to you.

If you do not have upgraded to Windows 10 yet

In order to perform your Windows 10 upgrade without losing your Thinfinity Remote Desktop Workstation license, follow these steps:

• Locate your license information: email and serial. You will need to enter it again after the Windows 10 upgrade. If you lost this information, write to support@cybelsoft.com including your personal or company name.

• Go to the ‘License’ tab of the Thinfinity Remote Desktop Workstation Manager:

• Press the ‘Deactivate’ button to deactivate your license.
• Proceed to install the Windows 10 upgrade.
• Enter your license information again.

If you already upgraded to Windows 10

If you’ve already upgraded to Windows 10 only to find the Thinfinity Remote Desktop Workstation license showing a “License could not be loaded” status, please follow these steps:

• Send us an email to support@cybelesoft.com explaining this situation. Make sure you include the personal or company name under which you registered for your license.
• We will deactivate your license so you can activate it again and let you know by email.
• Once your license is ready, activate it again.

How to activate your License after a Windows 10 upgrade

If you deactivated your license for the Windows 10 upgrade, or if you had the support team deactivate it after an error, you will need to enter your license information again. In order to do so, go to the ‘License’ tab of the Thinfinity Remote Desktop Workstation Manager, press the ‘Register’ button and enter your license information again:

And Voila! You are now ready to connect to your new Windows 10 remotely from any device.

The post Thinfinity Remote Desktop Workstation License Handling for Windows 10 Upgrade appeared first on Cybele Software.

We know how much you value remote access to your resources, specially if this access is available securely from any location, and without the need for any software installation on the client device, regardless of the device type. This is how we conceived the Thinfinity Remote Desktop product line: to provide seamless web access for the widest range of scenarios.

We’ve always been confident in our products’ power and ability to integrate, but it’s much more gratifying when it is our users who share and show with enthusiasm different solutions that make use of Thinfinity Remote Desktop.

Carsten Lemm, Microsoft Azure specialist from Germany, wrote an excellent tutorial where he gives a step by step explanation on how to prepare a Microsoft Azure VM installation to be accessed from the web using Thinfinity Remote Desktop Workstation. The article explains in detail how this solution avoids common firewall blocking issues, unnecessary browser extensions or client software installations, while also simplifying networking configuration.

Moreover, Carsten shows us how to prepare this Microsoft Azure VM installation in a completely automated way. For this purpose, he uses PowerShell with an Azure Resource Manager template and a custom script extension. After running the script, the vm is installed and web access is enabled via Thinfinity Remote Desktop.

You can read Carsten’s tutorial here:

Access your Azure VMs through a Web Browser with ThinRDP

By sharing this successful solution example, we hope to inspire our users to find new ways of taking advantage of the many features Thinfinity Remote Desktop has to offer.
Thank you, Carsten!

The post Web access for Azure VMs with Thinfinity Remote Desktop appeared first on Cybele Software.

Would you like to integrate a remote desktop within a Web application and access it from any device?

Previously, we let you know about support for an improved authentication method system that will be available in an upcoming Thinfinity VirtualUI release, and surely in Thinfinity Remote Desktop, too, in the close future.

Today, we want to share with you a quick insight about our new powered and extended SDK. This SDK was created to accomplish a better integration between Thinfinity Remote Desktop and external applications.

With this extended and improved SDK we seek a stronger remote desktop integration with those web solutions that require embedded RDP access from any place and device. Some typical examples of this kind of remote desktop integration are: support, education and training.

The main additions of this SDK extension are aimed at achieving greater flexibility and more customization possibilities. The most important improvement, however, is a new internal structure and a new cross-window messaging system that contemplates cross-domain and cross-platform scenarios.

Better remote desktop integration with cross-window messaging

The new Thinfinity Remote Desktop SDK will include a cross-window messaging system. Standard HTML5 postMessage-based, this feature will provide you with fine-tuned control of the Remote Desktop states, events and actions. With this new version of our integration API, you will be able to control the connection status more precisely.

Enhanced Customization

Our integration users requested for a way to customize the Remote Desktop Toolbar and popups. We collected their suggestions and added more options to increase the versatility of these complementary HTML elements. Also, you will be able to add new toolbar options, specially new keyboard shortcuts.

Moreover, the new SDK structure enables the creation and independent management of multiple and simultaneous remote desktop connections, including pure file transfer sessions and one-time url connections.

This and other new features will be released by the Q1 2016.

Stay tuned!

The post Preview: HTML5 Remote Desktop Integration, revisited appeared first on Cybele Software.

A new year has begun, and soon we will publish new releases of the Thinfinity product line.

We’ve been announcing in our latest blog entries some of the enhancements that will be introduced by the end of this quarter. However, we don’t want to wait that long to make new versions available.

We’ve already generated new versions of all the Thinfinity product line. Among the most outstanding features is an enhanced Gateway, available for both Thinfinity VirtualUI and Thinfinity Remote Desktop Server. Other improvements concern particular products.

We’ve added some improvements and fixes that will benefit those who integrate Thinfinity Remote Desktop to their cloud solutions. These will also be substantially enhanced when we release —in the close future and surely within this year’s first trimester— a new SDK with the ability to send and receive messages in cross-window/cross-frame environments; a capability requested by several of our clients.

Another technical improvement is the remote detection of the available keyboards where Thinfinity Remote Desktop is running. Up until today, these had to be chosen from a preset list.

One time connections —OTURL or One-Time URL connections— are used by many of our users in integrated solution. We improved its process so that it now prevents the loss of the session upon involuntary disconnection, which can be caused, for example, by a page reload.

We also included technical enhancements in Thinfinity VirtualUI that will allow you to reach a much better performance while consuming less resources. This is important in terms of enabling the execution of more simultaneous processes. Together with the Gateway improvements, VirtualUI is now a more stable and powerful web-enabling solution.

These are just some of the first improvements and fixes that we’ve already started to distribute among our clients.

Each week we will publish those ideas that we are, little by little, making come true. We are very interested in sharing them with you, even when they are not finished. We know how productive the exchange with our users can be.

And, of course, we will also write in detail about features that are already available for general use.

A new year has started. With it, we renew our commitment to make the Thinfinity product family a standard in application and remote environments HTML5 integrations.
Stay tuned!

The post A New Year, New Thinfinity Releases appeared first on Cybele Software.

A basic rule in Web security holds that there is no direct javascript access between different windows loaded in a browser unless these windows are from the same origin. This means that the windows must share protocol, host and port or it will not be possible to access a value or object on another page from the JavaScript code, or to add content. So, how can we establish and maintain the communication between different pages loaded in a cross-domain environment?

Fortunately, benefiting from the window.postMessage API, the windows can send non intrusive messages to each other via javascript in a cross-domain environment. These messages can be text, or an object in JSON format (JavaScript Object Notation) —something already available in most of modern web browsers.

In this article we will show how to apply this API to send cross-domain messages using Javascript in a secure way.

The window.postMessage API

In order to send a message to another window, one must invoke a postMessage() method, introduced below:

1

targetWindow.postMessage(message, targetDomain, [extra])

where:

But if a tree falls in a forest and nobody’s around to hear it, does it make a sound? In other words, it is useless to send the message if no one is prepared to listen to it. In order to be heard, the event message must be attended. Although most modern web browsers employ the addEventListener() method to add the treatment of the event, old IE versions makes use of its own; so we will cover both alternatives:

1
2
3
4
5

if (window.addEventListener){
    addEventListener("message", listenerFunction, false)
} else {
    attachEvent("onmessage", listenerFunction)
}

Where listenerFunction will be used to process the message coming from another window. This function will receive the message in the data attribute of the event received:

1
2
3
4
5
6
7

function listenerFunction(e) {
    if (typeof e.data == "string") {
        console.log(“The message is a text: ” +  e.data);
    } else {
        console.log(“The message is a JSON object:” + JSON.stringify(e.data));
    }
}

Some considerations regarding security

Cross-window messaging security model is two-sided. In the event of knowing the domains of the both parties involved —which is usually the case—, and in order to make the exchange of information between different domains safer, it is recommended to check, both when sending and receiving, the domains that participate in the messaging exchange. The sender ensures that the receiving domain is targetDomain. If the sender tries to send a message to a domain different to targetDomain, an error will occur.

The receiver can check the origin attribute of the received message event object to make sure that this came from a valid origin. Therefore, if the domain of origin does not match a valid domain, it can be ignored.

Let’s do it!

The following example implements cross-domain communication between two pages: one loaded in the localhost domain, and the other one in IP 127.0.0.1. To handle the exchange of messages we will create two javascript classes (MessageSender and MessageReceiver).

The MessageSender class has a single published method (sendMessage) and, during its creation, it will receive the window to where the message should be sent (targetWindow, mandatory) and the domain to which the message should be directed (targetDomain, optional), which if not received will be replaced by “*”. Both arguments are sent within a JSON object.

1
2
3
4
5
6
7
8
9
10
11
12

var MessageSender = function(args) {
    args = args || {};
    var targetWindow = args.targetWindow;
    var targetDomain = args.targetDomain || "*";
    var ready = false;
    var sendMessage = function(message) {
        targetWindow.postMessage(message, targetDomain);
    }
    return {
        "sendMessage": sendMessage
    }
}

The MessageReceiver class has two published methods. The start method initiates the listening of the message, while the stop method ends it. Both methods could receive a callback function to do an additional processing in the start/stop messaging. This class, when instantiated, is capable of receiving a JSON object with a pair of attributes, both optional. The first is a callback function to process the message; the other, a validOrigin string that indicates the domain from which it would be valid to receive messages. Should any of these parameters is not sent, the first one will be replaced by a default message processor , while the other, by the same page’s domain (i.e., it will not be cross-domain and will only receive messages from its own domain). In case you do not want to control the origin of the message, the validOrigin attribute must explicitly assert “*”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

var MessageReceiver = function (args) {
    args = args || {};
    var started = false;
    var validOrigin = args.validOrigin || window.location.origin;
    var defaultMsgProcessor = function (e) {
        if (typeof e.data == "string") {
            alert("The message is test:\n'" + e.data + "'");
        } else {
            alert("The message is a JSON object:\n" + JSON.stringify(e.data));
        }
    }
 
    var msgProcessor = args.callback || defaultMsgProcessor;
    var processMessage = function (e) {
        if (validOrigin == "*" || validOrigin == e.origin) {
            msgProcessor(e);
        }
    };
    var startListening = function (onStartCallback) {
        if (!started) {
            if (window.addEventListener) {
                window.addEventListener("message", processMessage, false);
            } else {
                attachEvent("onmessage", processMessage);
            }
            started = true;
            if (onStartCallback) onStartCallback();
        }
    }
    var stopListening = function (onStopCallback) {
        if (started) {
            if (window.removeEventListener) {
                window.removeEventListener("message", processMessage);
            } else {
                window.detachEvent("onmessage", processMessage);
            }
            started = false;
            if (onStopCallback) onStopCallback();
        }
    }
    return {
        "start": startListening,
        "stop": stopListening
    };
};

Both classes will be included in the same javascript file, which we will call crossDomainMessenger.js.

In order to use these classes, we will create two html pages. The first one, crossDomainSource.html, includes the crossDomainMessenger.js file and displays, on the top part, a line containing a text field (where the messages to be sent will be added) and some buttons to send messages. At the bottom of this page, the second page will load in an iframe, which would receive the messages.

From javascript, it will create both a MessageSender and a MessageReceiver; the first one to send messages triggered by the buttons to the page loaded in the iframe; and the last one to address messages that could be sent to the internal page.

This second page will also create a MessageSender and MessageReceiver, with the difference that in this case, the important work that will done by the latter.

The page also has buttons to toggle the message listener; a button to clear the list of messages received; and, a last button to send a message to the other page, which would close the communication circuit between the two windows.

Below you will find the code for the two pages of the example:

crossDomainSource.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Cross domain message example - Sender</title>
    <style>
        html, body { height: 100%; margin: 0px; padding: 0px; }
        #divmsg { height: 50px; line-height: 50px; vertical-align: middle; padding-left: 10px; padding-right: 10px; }
        #divtarget, #targetWindow {display: block; position: absolute; }
        #divtarget { top: 51px; bottom: 5px; left: 5px; right: 5px; border: solid 1px; box-sizing: border-box; }
        #targetWindow { width: 100%; height: 100%; border: none; }
    </style>
    <script type="text/javascript" src="crossDomainMessenger.js"></script>
    <script type="text/javascript">
        var msgSender = null;
        var msg = null;
 
        function init() {
            var targetDomain = window.location.protocol + "//127.0.0.1:" + window.location.port;
            var tw = document.getElementById("targetWindow");
            tw.src = targetDomain + "/crossDomainTarget.html";
            msgSender = new MessageSender({ "targetWindow": window.frames["target"], "targetDomain": targetDomain });            msg = document.getElementById("txtmsg");
 
            // Creates a MessageReceiver that accepts messages from targetDomain only
            new MessageReceiver({ "validOrigin": targetDomain }).start();        }
 
        function sendText() {
            msgSender.sendMessage(msg.value);
        }
 
        function sendObject() {
            msgSender.sendMessage({ "message": msg.value, "currentDate": new Date().toJSON() });
        }
 
        function sendClear() {
            msgSender.sendMessage({ "cmd": "CLEAR" });
        }
    </script>
</head>
<body onload="init()">
    <div id="divmsg">
        <label for="txtmsg">Message:</label>
        <input type="text" id="txtmsg" size="30" />
        <input type="button" value="send text" onclick="sendText()"/>
        <input type="button" value="send object" onclick="sendObject()"/>
        <input type="button" value="send clear" onclick="sendClear()"/>
    </div>
    <div id="divtarget">
        <iframe id="targetWindow" name="target"></iframe>
    </div>
</body>
</html>

crossDomainTarget.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Cross domain message example - Receiver</title>
    <style>
        html, body { height: 100%; margin: 0px; padding: 0px; }
        #msgPanel > div { border-bottom: dashed 1px #808080; }
    </style>
    <script type="text/javascript" src="crossDomainMessenger.js"></script>
    <script type="text/javascript">
        var msgSender = null;
        var msgReceiver = null;
        var msgPanel = null;
        function init() {
            msgPanel = document.getElementById("msgPanel");
            // This MessageReceiver accepts messages from localhost only.
            msgReceiver = new MessageReceiver({                "validOrigin": window.location.protocol + "//localhost:" + window.location.port,                "callback": function (e) {                    if (typeof e.data.cmd != "undefined" && e.data.cmd == "CLEAR") {                        clearMsgs();                    } else {                        addMessage("The message is " +                            ((typeof e.data == "string") ?                                "test:\n'" + e.data + "'" :                                "a JSON object:\n" + JSON.stringify(e.data)));                    }                }            });            start();
            msgSender = new MessageSender({ "targetWindow": window.parent });        }
 
        function start() {
            msgReceiver.start(function () { addMessage("*** msgReceiver was started!") });
        }
 
        function stop() {
            msgReceiver.stop(function () { addMessage("*** msgReceiver was stopped!"); });
        }
 
        function clearMsgs() {
            msgPanel.innerHTML = "";
        }
 
        function sendHellow() {
            msgSender.sendMessage(window.location.origin + " says Hello!");
        }
 
        function addMessage(message) {
            var newmsg = document.createElement("div");
            newmsg.innerHTML = message;
            msgPanel.appendChild(newmsg);
        }
    </script>
</head>
<body onload="init()">
    <div>
        <input type="button" value="start" onclick="start()"/>
        <input type="button" value="stop" onclick="stop()"/>
        <input type="button" value="clear" onclick="clearMsgs()"/>
        <input type="button" value="send msg to opener window" onclick="sendHellow()" />
    </div>
    <div id="msgPanel"></div>
</body>
</html>

This is enough to understand how the messaging between windows works, even when they are in different domains. In upcoming posts we will demonstrate how to use this technique to establish a smooth communication between Thinfinity VirtualUI or Thinfinity Remote Desktop with other applications to which they are integrated.

The post How to send cross-domain messages using Javascript appeared first on Cybele Software.

There are many reasons why you should choose Thinfinity Remote Desktop Server as the main remote access portal for your company. Today we’d like to tell you about a simple yet powerful feature that can make a difference on your everyday duties: the ability to share your remote desktop session.

Are you working remotely on a computer and need your IT department to help you out? Or maybe you want to show a coworker how to use a program, or collaborate with them in a task? Thinfinity Remote Desktop Server allows you to share the current remote desktop session instantly.

This little known capability is accessible as a web toolbar button. You will find the ‘Share Session’ option in the ‘Actions’ menu. If the web toolbar is collapsed, you can expand it by clicking on the down arrow.

One click to start it, and easy to join in! A pop up will provide you with a link and a password that you can distribute among the people you want to share the session with.

The session is truly shared: those who access the session through this link will be allowed to control the remote desktop too, using the mouse and keyboard. File transfer, however, will be restricted for these users. When the user who sent the invitation disconnects, the shared session ends for everybody. A guest that joined a shared session may nonetheless leave at any time by disconnecting and will not affect the other users.

This remote access functionality comes in handy in several situations. Most of our clients use Thinfinity Remote Desktop Server to telecommute to work. Remote workers cannot call for an IT person to come sit beside them and explain a new program, or fix an error on the screen. Many companies then resort to solutions that require one or both of the parties to install a desktop application so that they can be connected.

When using Thinfinity Remote Desktop, none of this is necessary: both the user and the Help Desk agent can be working in a shared session using only their regular browsers. In the same way, somebody working on a remote machine may release their findings with a colleague, or simply dole out the machine to work on a remote collaboration.

Need a more complex real-time collaboration solution?
Maybe an online presentation tool?

Then you should try Thinfinity Remote Desktop Workstation! It includes a Presentation Mode to raise an online meeting with up to 16 participants.

Stay tuned to learn about other amazing things you can accomplish with our products.

The post Share your remote desktop session with Thinfinity Remote Desktop Server appeared first on Cybele Software.

The Thinfinity Remote Desktop‘s toolbar allows users to perform some of the actions which are essential for a complete remote user experience, such as sharing the current sessions, accessing the file transfer manager, changing option settings, etc. In a previous post we discussed how to remove toolbar options. In this opportunity we will show you how to extend the Remote Desktop’s toolbar with new “Send Key…” actions.

The toolbar.shortcuts Structure

To extend the toolbar with new Send Key options, you have to use the toolbar JSON structure. It contains a javascript object array named shortcuts where each object represents a “Send Key…” menu option and has two fields:

• “text”: It’s the option caption text (String).
• “keys”: It’s an object array, where each element contains a keyboard action.

Why is “keys” an array? Because many times you need to press more than one key to create a “keyboard gesture”. The best example of this are the [CTRL]+any key combinations, where the keyboard sequence is…

• Press [CTRL] (keydown)
• Stroke any other key (keydown, keypress, keyup)
• Release [CTRL] (keyup)

The same occurs with [SHIFT], [ALT], the [SHIFT]+[ALT], [CTRL]+[SHIFT] combinations, etc.

Other options can be added to supply and/or complement existing actions, or to add useful keystroke sequences to help your users.

To do this, each key action has two fields: a type (action field) and a value (key or text field, depending on the current value of action).

The following table explains each action in detail:

And these are the value types:

The following example shows these actions and values in action:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

    "toolbar": {
        "shortcuts": [
            {
                "text": "Help (F1)",
                "keys": [
                    { "action": "stroke", "key": 0x70 } // F1
                ]
            },
            {
                "text": "Find",
                "keys": [
                    { "action": "down", "key": 0x11 },  // CTRL
                    { "action": "stroke", "key": 0x46 }, //F
                    { "action": "up", "key": 0x11 } // CTRL
                ]
            },
            {
                "text": "Type 'Hello'",
                "keys": [
                    { "action": "type", "text": "Hello" }
                ]
            },
            {
                "text": "Find 'Hello'",
                "keys": [
                    { "action": "down", "key": 0x11 },  // CTRL
                    { "action": "stroke", "key": 0x46 }, //F
                    { "action": "up", "key": 0x11 }, // CTRL
                    { "action": "type", "text": "Hello" },
                    { "action": "stroke", "key": 0x0D } //ENTER
                ]
            }
        ]
    }

In this example, the first shortcut sends an F1, the second triggers a find/search (a [CTRL]+F), the third just types “Hello” and the fourth combines the second and third examples to process a find of “Hello”.

There are two ways to add new toolbar options:

• Adding the new options to the customSettings global variable, whose settings will affect all users and all connections in the Thinfinity Remote Desktop server installation.
• Adding the new options to the connection parameters, if you are an integrator who is using the sdk.html page or any other page with an embedded remote desktop.

Using customSettings to Extend the Remote Desktop’s Toolbar

The customSettings global variable is a JSON object defined in the customSettings.js file, which you’ll find in the Thinfinity Remote Desktop Server installation web folder. This variable, a Javascript object, has attributes to set or modify connection features, including some related to the toolbar. This structure doesn’t have default attributes (they are disabled in the source code) and looks like this:

1
2
3
4
5
6
7
8
9

var customSettings = {
    /*
        "createToolbar": true,                // Creates ThinRDP toolbar
        "toolbarVisible": false,              // ThinRDP toolbar starts expanded (visible)
        "checkBeforeWindowClose": true,       // when false, skips the user confirmation popup of the onBeforeUnload event
        "noSsnDialog": false,                 // avoids the share session popup dialog
        "noShowPopupsOnClose": false          // when true, skips the session closed message popup
    */<
};

To add the toolbar.shortcuts structure to customSettings you’ll just have to do this:

1
2
3
4
5
6

var customSettings = {
    ...
    "toolbar": {
        "shortcuts": [ ... ]
    }
}

Modifying Parameters in an SDK Custom Connection

If you are using the Thinfinity Remote Desktop SDK and you don’t want to change the toolbar for all users, or if you want to modify it in a conditional way (e.g. depending on a user identification or profile), you can add the toolbar.shortcuts structure to the connection parameters. The difference with the previous example is that this addition is not for all users. This change will only affect SDK users, and optionally you can add this data conditionally.

Add the toolbar.shortcuts structure to the connection parameters for all SDK users:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var mythinrdp = null;
 
$(document).ready(function () {
    mythinrdp = GetThinRDP("", false);
    mythinrdp.connect({
        targetWindow: "myiframe",
        centered: true,
        ...
        ...
        // Custom shortcuts (Toolbar Actions/Send Keys...)
        "toolbar": {
            "shortcuts": [ ... ]
        }
    });
    ...
});

For a selective toolbar.shortcuts addition, you could do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

var mythinrdp = null;
 
$(document).ready(function () {
    var params = {
        targetWindow: "myiframe",
        centered: true,
        ...
        ...
    };
 
    // hypothetical functions created by you
    if (userProfile(CurrentUser()).hasExtendsSendKeys) {
        params["toolbar"] = { "shortcuts": [ ... ] };
    }
 
    mythinrdp = GetThinRDP("", false);
    mythinrdp.connect(params);
    ...
});

As you can see, Thinfinity Remote Desktop offers different ways in which it can be customized and have its functionality extended.

Please stay tuned to learn more about our products!

The post Add Actions to extend the Remote Desktop’s Toolbar appeared first on Cybele Software.