What protocol is used when connecting Protractor directly to browser drivers? - selenium

In the Protractor Infrasturcture documentation http://www.protractortest.org/#/infrastructure, it says that communication protocol between the test script and the standalone selenium server is http, and between the selenium server and the browser driver is JSON Webdriver Wire Protocol.
But in the documentation on setting up Selenium server https://github.com/angular/protractor/blob/master/docs/server-setup.md#connecting-directly-to-browser-drivers, it says there is an option to connect the test script directly to the browser driver.
My question is: When using the direct connect option, what communication protocol is used between the test script and the browser driver?
(reason I'm asking here rather than on Protractor github issues is the contributing guidelines say all questions should be posted on stack overflow or google group)

The protocol to communicate with the Selenium server or the drivers is http in both cases.
The commands are transmitted using the JSON wire protocol in the message of the http request/response.
Now with Selenium, you can work directly with the driver of the targeted browser or you can connect to the Selenium server which will transmit the commands to the driver.

Related

Is Selenium a security vulnerability?

I'm learning Selenium but I am concerned that the Webdriver (Chromedriver.exe, Geckodriver.exe) seems to open a port for communication functioning as a proxy between the selenium code and the browser. I don't want to expose myself to any vulnerabilities and would prefer some form of direct browser communication. I've viewed several solutions, but selenium just seems to be the reigning champion.
It appears that some form of what I am looking for was present with PhantomJS, but that seems to be no longer supported. This leaves me two options:
-Find a browser that selenium can communicate directly with without the aid of Webdriver.
-Find a way to completely restrict that port that it seems to open up so it does not allow connections from anybody on the network and no one can connect to my local machine.
Any suggestions folks?

Robot Framework executing test on RDP client

I have my robotframework setup on my PC.
I would like to connect to a remote windows client, have it open a browser and access a URL.
Verify that the pages has loaded.
Pretty basic but since I am new to RF, I wanted to know how that would work.
For Linux machines, I would use the SSHLibrary and just execute commands (wget) but for the windows machine, I need to use the browsers.
Do I need RF installed on the destination client RDP?
Do I need the webdrivers for each browser on the client RDP?
How would I go about logging in the Windows machine through RDP?
After Logging in with RDP, I run the same "open broswer" with broswer and URL?
Thanks!!!
The use case you describe - a browser to be opened & controlled on a remote machine, is precisely what Selenium solves.
Though in day-to-day work or debugging we are usually starting a local browser, SE is preliminary designed for remote execution. So head to www.selenium.dev, and focus on the Grid - that's the component you are after.
I'm that approach, answers to your specific questions:
no, you need Robot Framework and selenium library on the local machine, and only selenium & webdriver on the remote.
you don't need the drivers on the client - the selenium library is all you communicate with in your code; you need them installed in the remote only.
on the local you will get the logs of the webdriver commands execution; actual browser manipulation logs are only on the remote and the hub (but these are really debugging ones, everything high-level for the functional execution is local).
you don't really log into RDP with this approach (RDP is totally out of the picture here), and yes - your code is the same as running on local browser - Open Browser, Get Text, etc - but, executed on a remote machine.
If you want to see why 1) and 2), head to the answer over here (shameless plug 🙂)

What is the difference between Selenium Server and Selenium RC?

Selenium Webdriver - For interacting directly with browser
Selenium RC - Interacts with browser through a Server
If i need to test remotely using Web-driver, i need to use Selenium Server
So when we say Selenium Server in third point, does it mean then the
same server used by Selenium RC?
Is selenium server already included with selenium RC? If need to do automation using selenium RC, do i need to download Selenium Server separately?
Selenium Remote Control (RC) and Selenium WebDriver both are test automation tools supporting different programming languages but come with some critical differences.
Selenium RC
Till a couple of years back Selenium RC was an important component in the Selenium test suite. It was the testing framework that enabled a QA or a developer to write test cases in any programming language in order to automate UI tests for web applications against any HTTP website. Selenium RC comprised of two parts:
Client libraries for the preferred Language Binding Art.
A server that launches and destroys web browsers automatically.
Selenium RC’s architecture was a bit complicated as:
Developer/QA personal needed to install and launch a separate application called Selenium Remote Control Server before running test scripts.
The Selenium RC server acted as a mediator between the browser and Selenium commands.
The sequence of execution was:
The Selenium RC server injected a Javascript program known as Selenium Core into the browser client.
Once the Selenium Core program was injected, it started receiving instructions from the RC server based on test scripts. Selenium Core executed all these instructions as JavaScript commands.
The web browser executed all the commands given by Selenium Core and returns the test summary back to the Selenium RC server.
But there were limitations as follows:
Selenium RC Server's architecture was pretty complicated.
Execution of test scripts was time-consuming as Selenium RC uses JavaScript commands as instructions to the browser which resulted in slow performance.
API’s were less object-oriented.
There was no support for headless browsers.
All these limitations of Selenium RC Server led to the development of the new robust automation framework Selenium WebDriver.
WebDriver
From Selenium perspective, the WebDriver Interface is similar like a agreement which the 3rd party Browser Vendors like Mozilla, Chrome, Internet Explorer, Safari, etc have to adhere and implement the same. This would in-turn help the end-users to use the exposed APIs to write a common code and implement the functionalities across all the available Browsers without any change.
This usecase
To execute your testcases:
Locally: Selenium Client (jars) which is a bunch of API's would suffice your need.
On Remote machines(Selenium Grid): Selenium Server would solve your purpose.
You can find a relevant discussion in What is difference between Selenium Standalone Server and Java selenium Jar files

What is the difference between WebDriver and DevTool protocol

As we known WebDriver protocol is design for automation test purpose. But the major browsers also provide DevTool protocol. In some cases the DevTool protocol could achieve more powerful interactions and operations compare to WebDriver.
My question is why there are two different protocols and what's the main difference between these two protocols? Is there any selection experience available to share for a project development?
Thanks in advance!
Reference:
DevTools
https://learn.microsoft.com/en-us/microsoft-edge/devtools-protocol/
https://chromedevtools.github.io/devtools-protocol/
https://searchfox.org/mozillacentral/source/devtools/docs/backend/protocol.md
WebDriver:
https://www.seleniumhq.org/projects/webdriver/
https://www.w3.org/TR/webdriver1/
https://learn.microsoft.com/en-us/microsoft-edge/webdriver
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/WebDriver
https://sites.google.com/a/chromium.org/chromedriver/downloads
Main difference between WebDriver protocol and DevTools protocol is that WebDriver protocol needs a middle man like browser-driver (eg: chrome-driver) which is a server that sits between the automation script and browser enabling browser control, but in case of DevTools protocol the automation script can directly talk to browser running in debug mode making headless automation pretty straight forward.
And Chrome driver internally uses DevTools protocol to control browser, so if we are using WebDriver protocol it will in turn use Devtools protocol to control browser.
If cross-browser testing is something important for the new testing tool, DevTools protocol may not be suitable now, as there is no standard yet and it is mostly work in progress. Otherwise DevTools protocol will be a great choice as it gives more control like intercepting request header, simulating network etc and makes headless automation way easier.
WebDriver
WebDriver supplies us a well-designed object-oriented API that can provide improved support for modern advanced web-applications created through dynamic web pages. In short, WebDriver is the remote control interface that enables us to introspect and control the user agents. It provides us a platform and language neutral wire protocol along with as a way for out-of-process programs to remotely instruct the behavior of Web Browsers.
WebDriver Specification
The WebDriver Specification was published by the Browser Testing and Tools Working Group as Editor's Draft. Editor's Draft does not imply endorsement by the W3C Membership and may be updated, replaced or obsoleted by other documents at any time.
DevTools Protocol
The Developer Tools Protocol is used by various Browsers, JavaScript Engines and debugging tools to:
Help web developers with a set of diagnostics tools which work well across a variety of targets.
To converge the need for target-specific devtools protocol adapters and simplify the experience for tool users and tool developers.
Provide a vendor-neutral platform to facilitate collaboration and mutual consensus building between different protocol implementations and interested clients.
Reduce the engineering investment necessary to build any further compatible protocol implementations as per user stories.
Some of the Browser Engines and Browsers those have a built-in debugging protocol are:
Chrome DevTools
WebKit / Safari
Node.js
Firefox 1 (in development)
Edge 2 ([in development] (link will be updated soon))
Some of the adapters that exposes a common protocol:
Microsoft Edge Diagnostics Adapter - will be replaced by the native support (mentioned above).
RemoteDebug iOS WebKit Adapter
Here you can find the list of adapters in RemoteDebug - Protocol Adaptors
1. Note that DevTools Protocol for Firefox is Work In Progress
2. Note that DevTools Protocol for Edge is Work In Progress

Does selenium grid runs only Selenium command or also code chunk from different library

I have done my automation in Robotframework and I am using many libraries like Selenium2Library, Sikuli Library, HTTP Library, OS library and few more.
When I am running test on Selenium Grid, it invokes the browser on node and runs those steps which are from Selenium.
However, it does not run commands from Sikuli Library. Is selenium grid capable of running keywords from different libraries?
No, the selenium grid only works with selenium. The selenium grid is a server much like a web server. It listens for specific commands, and performs those commands. It will only respond to commands from selenium clients.
When using Sikuly in Robot Framework it is necessary to first setup the external sikuly server and then connect to it from Robot Framework. Typically this is a localhost connection, but connecting to an external host is also possible.
When using Selenium Grid, a connection is made to an anonymous node and thus the host to which the Sikuly server is runnning as well. Did a quick check in google and found that getting the hostname/IP of the running node from the hub is possible. Using the code example here I think it should be possible to create a direct connection to the Sikuly server.