Support for custom driver commands in Selenium (Java) Server

92 views
Skip to first unread message

Seva Lo

unread,
Jul 17, 2015, 6:29:04 PM7/17/15
to selenium-...@googlegroups.com
When handling a command, Selenium (Java) Server
- first looks up command name in the list of standard Selenium commands that it has,
- then finds the session among the active sessions and forwards command there

First step fails if command is not one of the Selenium standard commands, even if the downstream driver supports that command.

I am going to try and change Selenium Server to forward the command to the driver of the particular session as long as the command has standard structure (name, parameters, etc) and let the downstream driver throw the error if it cannot handle the command.

Any problem with this approach?
Any advice before I start?
Does Grid need something like this? Or does it already have it? (I didn't look at Grid yet)

Seva

David Burns

unread,
Jul 21, 2015, 3:16:23 AM7/21/15
to selenium-...@googlegroups.com
I am not sure the Java server should care about the structure of the packet sent. Ideally the server should only be forwarding the session to the right place and then the remote end should just handle or error.

David


Sent from Mailbox


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CACD1K90kSRTcp2BDOC6b3jjqO6dJczDFBv75eCG8E72%2BHP30cw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Kristian Rosenvold

unread,
Jul 21, 2015, 3:29:45 AM7/21/15
to selenium-...@googlegroups.com

Doesnt that mean you are opening the server for arbitrary command execution ?

Unsure if that is wise?


Kristian



--

David Burns

unread,
Jul 21, 2015, 11:11:28 AM7/21/15
to selenium-...@googlegroups.com
I am more meaning that we should allow

/session/<sessionId>/<custom identifier>/rest/of/endpoint

This will allow us to do vendor specific extensions to the protocol[1]

David

[1] http://w3c.github.io/webdriver/webdriver-spec.html#vendor-specific-extensions



Jason Leyba

unread,
Jul 21, 2015, 1:00:45 PM7/21/15
to selenium-...@googlegroups.com
The Java server will need to know which drivers are remote and that it can forward the command to. It currently decodes commands and makes Java API calls - there's no knowledge of whether a session is using an implementation that speaks the HTTP protocol.


Jon Thor Austen

unread,
Jul 30, 2015, 10:56:05 AM7/30/15
to Selenium Developers, vlotos...@gmail.com
IN the newest Java .NET release notes, it says this:

Added ability to add custom wire protocol commands in .NET bindings. This
allows projects that use a WebDriver-like JSON-over-HTTP wire protocol to
add additional end points for their use.

https://github.com/SeleniumHQ/selenium/blob/master/dotnet/CHANGELOG
-Jon

Jim Evans

unread,
Jul 30, 2015, 6:20:07 PM7/30/15
to Selenium Developers, vlotos...@gmail.com, aust...@gmail.com
I should point out that this is for .NET only, and only affects the local (language binding) end. If you're using the .NET language bindings, and you need to communicate with a remote server that has additional end points (note that this does *not* describe the Java standalone server), you can now do so. Examples of this might be a mobile driver that might have additional end points that a desktop browser driver doesn't have.

Seva Lo

unread,
Jul 30, 2015, 8:07:37 PM7/30/15
to Jim Evans, Selenium Developers, aust...@gmail.com
Thanks everyone for your input!

David> I am not sure the Java server should care about the structure of the packet sent. Ideally the server should only be forwarding the session to the right place and then the remote end should just handle or error.
Kristian> Doesnt that mean you are opening the server for arbitrary command execution ?
I can see, although more theoretically than practically, how one may use an assumed-ownable remote driver implementation and seal that to only accept connections from wherever the selenium-server sends them, relying on the selenium server as an extra layer of protection (only letting through "good" requests: HTTP, well formed JSON, warmhearted payloads). I will start with *some* validation of that sort and we cold iterate on that. In general, selenium server isn't really a serious security protection layer though, it shouldn't be seen as that, so I don't think we should stress out about this too much.

Jason> It currently decodes commands and makes Java API calls - there's no knowledge of whether a session is using an implementation that speaks the HTTP protocol.
Right. I will see whether it makes more sense to a) keep the existing mechanism (Java API calls) for standard commands and only forward-over-http other ones or b) forward-over-http all commands to those drivers that listen HTTP. The latter may lead to a great simplification of the server and the only non-"remote" driver I know of is HtmlUnitDriver.... We will see.

Jon, Jim,
Re support for the custom commands support in the *client* side (language bindings), there is this related "good discussion". This thread was prompted by the same thing as that one:
local end support for a chromedriver specific commands will be pushed soon and now I am looking for a way to use that when the Selenium [Java] Server is involved.

Seva

Reply all
Reply to author
Forward
0 new messages