Blog

Latest Updates. News. Insights. Ideas.

technical Archives - Sahi Pro

Sahi Pro: Troubleshooting Series: Remote Desktop Connection (RDC)

Posted by | technical, troubleshooting | No Comments

Last week, we saw how to troubleshoot SSL issues.
Similarly, during automation, one might have to do a remote desktop connection (RDC) to multiple machines and there are chances of minimizing or closing the RDC connections. In this blog post, we discuss the solutions to problems with native elements if the RDC is minimised or closed.

Scenario 1: Minimised Remote Desktop Connection
When tests are executed on a remote machine using Remote Desktop Connection and the RDC window remains minimised, native events (including taking screenshots) fail to work.
To fix this, one needs to add registry keys on the client machine from which the Remote Desktop Connection is made.
NOTE that these keys are to be modified on the client and not the remote machine.

Please be careful while changing the registry entries.

Registry Editor

  • Launch the Windows Registry as appropriate on your Windows machine
  • For 32-bit Windows, find the registry key:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
  • For 64 bit Windows, find the registry key:
    HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client
  • Create a DWORD value with the name RemoteDesktop_SuppressWhenMinimized with value 2.
  • Run the tests.

Now native events should work well with a minimised Remote Desktop Connection.

Scenario 2: Closed Remote Desktop Connection
Sometimes users would want to open a Remote Desktop Connection, start running the tests on the remote machine, and close off the connection from the client while the tests are running.
In this case, native events (including taking screenshots) fail to work.

To work around this, please do the following instead of closing the remote desktop connection directly.

  • Create a batch file on the Remote machine’s Desktop (For example: “disconnect.bat”).
  • Type the following line in the file –
    tscon %sessionname% /dest:console
    and save it.
  • Start off the tests on the Remote machine.
  • Do not close the Remote Desktop Connection from the client directly.
  • Instead, double click on the batch file. The session will be closed by the remote desktop.

    Now native events should work well with the closed Remote Desktop Connection.

Scenario 3: Right Click > Paste (Clipboard) missing in RDP (RDC)

Clipboard Checked

Even though you have ensured that Clipboard is checked and available during the remote session, when you do a right click after a copy, the paste option might be disabled.

All you need to do is to kill the clipboard process and restart it again! You can do so by running the following command from the windows run command (Windows Key + R) or cmd (on the remote machine):

Taskkill.exe /im rdpclip.exe

The command above will kill RDP Clip Monitor process, and then you can restart the process again by running the following command:

Rdpclip.exe

It should start the process again and the clipboard should start working again now

Refer the following link for more information:
https://www.svenbit.com/2014/11/restart-copy-and-paste-clipboard-functionality-in-rdp/

Hope this post gave you information about troubleshooting RDC issues. Feel free to let us know if you face any other issues by sending an email to support [AT] sahipro [DOT] com

We will cover those in the upcoming posts.

SahiPro Troubleshooting Series: SSL Issues

Posted by | technical, troubleshooting | No Comments

We take pride in helping our customers solve their automation issues. We are planning to come up with a list of commonly faced issues and how we solved it. This might help multiple customers when they face similar issues. Over a period of time, this would turn into a good repository of problems and solutions.

Today, we share the common problems faced by our customers with SSL

Issue 1: Certificates does not conform to algorithm constraints
Certificates does not conform to algorithm constraints

Sahi Pro Console Error

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Ce
rtificates does not conform to algorithm constraints
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source
)

Solution:
Please perform all the steps highlighted below:
  • Open C:\Program Files\Java\jre1.8.0_111\lib\security\java.security file.
    The above path is for jre version 1.8.0_111. In your case, it might be different.
  • Search for the lines
    jdk.certpath.disabledAlgorithms=
    jdk.tls.disabledAlgorithms=
    jdk.jar.disabledAlgorithms=
    and comment them by prefixing # such that they look like this:
    #jdk.certpath.disabledAlgorithms=
    #jdk.tls.disabledAlgorithms=
    #jdk.jar.disabledAlgorithms= 
  • Open <SahiPro>/bin/dashboard.bat file and modify below lines fromjava -Djsse.enableSNIExtension=true -Djava.util.logging.config.file=%SAHI_USERDATA_DIR_TMP%\config\log.properties -classpath %SAHI_EXT_CLASS_PATH%;%SAHI_CLASS_PATH% net.sf.sahi.ui.Dashboard “%SAHI_HOME%” “%SAHI_USERDATA_DIR_TMP%”
    to
    java -Djsse.enableSNIExtension=true -Dhttps.protocols=SSLv2Hello,TLSv1,TLSv1.1 -Djava.util.logging.config.file=%SAHI_USERDATA_DIR_TMP%\config\log.properties -classpath %SAHI_EXT_CLASS_PATH%;%SAHI_CLASS_PATH% net.sf.sahi.ui.Dashboard “%SAHI_HOME%” “%SAHI_USERDATA_DIR_TMP%”
  • Save the changes and restart Sahi Pro.

Issue 2: “ERR_SSL_VERSION_OR_CIPHER_MISMATCH”
SSL_VERSION

Solution:

  • Please modify the following property in <SahiPro>/bin/dashboard.bat by toggling the value from true to false or false to true.
    -Djsse.enableSNIExtension=true
    or
    -Djsse.enableSNIExtension=false
  • Save the changes and restart Sahi Pro.

Issue 3: ERR_SSL_PROTOCOL_ERROR
Protocol
Solution:

  • Take a back up of <SahiPro>/bin/dashboard.bat and modify the following fromjava -Djsse.enableSNIExtension=true -Djava.util.logging.config.file=%SAHI_USERDATA_DIR_TMP%\config\log.properties -classpath %SAHI_EXT_CLASS_PATH%;%SAHI_CLASS_PATH% net.sf.sahi.ui.Dashboard “%SAHI_HOME%” “%SAHI_USERDATA_DIR_TMP%”
    to
    java -Djsse.enableSNIExtension=true -Dhttps.protocols=”SSLv3,SSLv2Hello,TLSv1″ -Djava.util.logging.config.file=%SAHI_USERDATA_DIR_TMP%\config\log.properties -classpath %SAHI_EXT_CLASS_PATH%;%SAHI_CLASS_PATH% net.sf.sahi.ui.Dashboard “%SAHI_HOME%” “%SAHI_USERDATA_DIR_TMP%”
  • Save the changes and restart Sahi Pro.

    Hope this post gave you information about troubleshooting SSL issues. Feel free to let us know if you face any other issues by sending an email to support [AT] sahipro [DOT] comWe will cover those in the upcoming posts.

OpenSSL and Heartbleed clarification in Sahi Pro

Posted by | Sahi, technical | No Comments

One of our support requests asked about the version of openssl used in Sahi Pro. Since it may be of concern to others, here is some more information related to use of openssl in Sahi Pro.

The version of openssl is :
OpenSSL 0.9.8h 28 May 2008

OpenSSL 0.9.8h did not have the heartbleed bug. (“OpenSSL 0.9.8 branch is NOT vulnerable” from http://heartbleed.com/)
In Sahi, Openssl is only used to generate a signed certificate with Sahi’s CA certificate (also created via openssl).
All other HTTPS communication between browser proxy and server are done via Java’s built-in SSL implementation.
Sahi does not add its version of openssl into the system path, so it should not affect the rest of your system/application.

Sahi Pro v5.1.1 fast execution without waits on Chrome 34

Posted by | Sahi, technical | No Comments

Some of you may have noticed that Sahi Pro does not wait correctly for page loads since Chrome 34. This happens because of a change in window.document.readyState behaviour in (since?) Chrome 34.

To fix it, do the following:

Open sahi/userdata/config/user_extensions.js and add

// Chrome 33 fix start
Sahi.prototype.replace33 = function(fn) {return "("+(""+fn).replace("_isChrome", "isChrome33Minus")+")";}
Sahi.prototype.areWindowsLoaded = eval(_sahi.replace33(Sahi.prototype.areWindowsLoaded));
Sahi.prototype.ping = eval(_sahi.replace33(Sahi.prototype.ping));
Sahi.prototype.getChromeVersion = function() {
var m = window.navigator.appVersion.match(/Chrome\/(\d+)\./);
return m ? parseInt(m[1], 10) : 0;
}
Sahi.prototype.isChrome33 = function() {return this._isChrome() && this.getChromeVersion() == 33;}
Sahi.prototype.isChrome33Minus = function() {return this._isChrome() && this.getChromeVersion() <= 33;}
//Chrome 33 fix end

before the line:
__sahiDebug__("user_ext.js: end");

Restart Sahi, clear browser cache and check if it works. If you have trouble, please email support.

HTTPS Problem Resolution: Unable to tunnel through proxy

Posted by | technical, troubleshooting | One Comment
Sahi had been using its own custom implementation of proxy tunnelling till a few months back. Owing to a lot of demand for some features, we moved to Java’s httpsurlconnection which supported tunnelling through a corporate proxy with authentication. 
But unfortunately a bug in Java’s httpsurlconnection was tripping up a few users on some https sites. One case was the failure of websites using login via SiteMinder. 
The exception thrown was  
Unable to tunnel through proxy. Proxy returns “HTTP/1.1 400 Bad Request”
After some research we figured that it was due to this bug 6687282 
Switching to the latest java 1.6.0_14 fixed this issue for us.

Improving Sahi’s performance

Posted by | features, technical | No Comments

Over the last year, Sahi has steadily undergone enhancements to speed up its proxy.

For outgoing connections, we moved away from raw sockets and started using java’s HttpURLConnection primarily for its proxy tunnelling capabilities, but it helped in boosting performance over using raw sockets due to better socket reuse and buffering.

Caching was allowed for static files so that browsers could just use files from their own cache, instead of fetching from the server.

But there was still one big problem with Sahi’s proxy. Let me explain:

Opening a connection to a server or a proxy is expensive for the browser. In a simple case a browser will open one connection per request and then close it down when it has read the response. But since it is an expensive process, the HTTP protocol allows something called keep-alive or persistent connections. What this means is that a browser can open a connection, send its request, read the response, then again send the next request using the same connection. This helps in reusing connections and can vastly improve browser performance.

So, how does the browser know that a response is complete before it sends the next request? It knows because, the server first sends the length of the content that the browser is supposed to read, via the Content-Length header. Once the browser has read that many bytes, the browser will assume the response is complete. It can then use the connection for the next request.

Browsers do one more thing to improve performance. Even before the full content is read, the browser starts to render partial data. This means that if there is a script or css file included in the html page, these included files will start to get fetched (through different connections) while the page is still rendering.

But this is not the case when using Sahi as its proxy. Sahi modifies the content slightly so the content length changes. And since it is not known what the eventual content length would be, Sahi first reads the full response from the server, modifies the response, recalculates the content-length, and then sends the new content-length to the browser followed by the modified content. This means that while the response is coming in slowly from the server, the proxy is still buffering it, so the browser cannot start rendering partial content or fetch embedded content. (Note that the communication time from the proxy to the browser is negligible compared to proxy-web server communication, since the proxy is either on the same machine as the browser or on the LAN.)

Have a look at how Firefox behaves with and without proxy. Both are keep-alive connections and both have the content-length header set correctly.


Without Proxy: Notice how the css and js files are being fetched before the first response has been fully read.


With Proxy: Notice how the css and js files are being fetched only AFTER the first response has been fully read.

So how can we solve this? HTTP allows one other mechanism. This is called chunked transfer, which can be activated via the header Transfer-Encoding:chunked. What this means is, you no longer need to send the content length of the whole response. You can break down the response into chunks and you send the content-length of a single chunk, then its data, then the content-length of the next chunk followed by its data etc. You signal the end of the response by an empty chunk of content-length 0.

This is how Firefox behaves when using Transfer-Encoding: chunked. This is with the proxy on.

With Proxy: Notice how the css and js files are being fetched along with the first response.

Does this mean that, all Sahi had to do was change the headers? No.

Working on a whole string is much easier than working on a stream of data. For example if we wanted to change all instances of “blue” to “red”, it would be easy to work on “It is a blue blue sky”. It would not be the same to work on three substrings of the same string like “It is a bl”, “ue blu”, “e sky”. You can see that none of them individually have “blue” in them. A solution in this particular case, would be to keep the last word somewhere, concatenate it with the next string, and then try substitutions.

Second, and more significantly, you cannot just chain data coming in from an inputstream from the web-server into an outputstream pointing to the browser. Why? Because, both network reads and writes via java.io are blocking calls in Java and such a read and write in a single thread can cause a dead-lock. What that essentially means is we need to have a common buffer where data is written to and read from, but via two different threads. This is solved well using PipedInputStreams and PipedOutputStreams (which will be a separate blog post).

After a few days of work, Sahi now has a fully functional, much faster streaming proxy, with filters on the streams doing all the data and header modifications. The changes should be available in the next build.

Flash testing

Posted by | features, technical | One Comment

The other day I came across a link explaining how to test flash applications using Selenium. Sahi already supports testing of Flash objects embedded in web applications out of the box, with no extra code.
For any attribute or method that is exposed via ExternalInterface in the flash object, one can just do

_call(_byId(“flash”))

Sahi no longer needs waiting for AJAX calls

Posted by | features, technical | 2 Comments

The new release of Sahi (Sahi Nightly 2001-10-11) automatically waits for AJAX responses to complete before proceeding.

This removes the need to add AJAX request url patterns to exclude_inject.txt

Sahi accomplishes this by waiting for XHR requests to complete before it proceeds to its next step. It already used to wait for frames and iframes.

Another significant change is the way variables are used in Sahi code.
I shall be writing a new blog post for that.

_dragDropXY(element, x, y) has been added.
A lot of bugs including iframe traversal, _setFile on IE and _button have been fixed.

Download: https://sourceforge.net/project/showfiles.php?group_id=151639

/ is unfortunately down right now.

Ajax and Sahi

Posted by | features, technical | One Comment

Problem

In Sahi, some javascript is added to all pages. In an ajax call, the response should be xml. But sahi may taint the xml with its javascript and hence ajax calls may stop working. Sahi looks at the content type of a file before it injects its js, but most of the time the ajax responses also have the content type as text/html

Solution

Sahi can be asked to not inject js into requests whose urls follow specific patterns.
Say urls which have say “/ajax/” in them can be excluded from injection.

What you need to do is add the regular expression pattern of the ajaxy urls to config/exclude_inject.txt
so if your url is something like
http://www.example.com/ajax/list.html” use
“.*/ajax/.*” (without quotes) to match all urls with /ajax/ in them and exclude them from js injection.

Use fully-loaded Sahi Pro FREE for a month. Download Now Request a Demo