RoboHydra summoners is a way to share a single RoboHydra server between multiple users.
Imagine that you work in some project with some other people. In 0.3
and earlier versions, if you setup a common RoboHydra server (let’s
http://common-test-server.example.com), only one person
would be able to use it at any given time. For example, if Alice opens
up a browser and starts the scenario
Bob, that came one minute later, will find that scenario started; if
he starts, say,
mixedCharsets, Alice will find that suddenly the
RoboHydra server doesn’t behave as she wanted it to.
First of all, let’s define a hydra as a collection of heads and scenarios with their status (attached/detached, active/inactive). Before RoboHydra 0.4, a RoboHydra server had a single hydra, and thus if you added a new head or started a scenario, anyone making requests to the server will see those changes. RoboHydra 0.4 and later allows you to have several hydras in the same server, and decide which hydras get which requests.
That is, in 0.3 and earlier versions a request was processed like this:
However, now, by default, it’s more something like this:
8a40f. As there’s no hydra named
8a40f, the summoner creates it.
8a40fprocesses the request normally.
25b1c. As there’s no hydra with the name
25b1c, the summoner creates it.
25b1cprocesses the second request normally. If the summoner function had returned
8a40ffor the second request (presumably because it also had a session cookie with that value), no new hydras would have been created, and the second request would have been processed by the already existing hydra
Take into account that the RoboHydra admin interface follows the same rules, so each user can independently see and manipulate the state of the heads, etc. from the web UI.
The default summoner always returns
*default*, and thus will always
use the same hydra (see figure 2 above), ie. will behave like older
versions of RoboHydra. If you want to support multiple users, you’ll
have to first decide how you want to tell them apart. Cookies work
well, but you might want to use headers, GET parameters or whatever
Once you know how you want to tell your users apart, you’ll have to
write a plugin that exports a function
function works in a way similar to
getBodyParts: it receives the
configuration and returns an object with the traits of the
summoner. The only currently supported summoner trait is
hydraPicker, a function that receives the request object and
returns a string with the name of the hydra to use for that request. A
trivial example of such a plugin could be:
If the RoboHydra server loads only one plugin with a
summoner trait, it will use this RoboHydra picker function to decide
how to dispatch the different incoming requests. If it has more than
hydraPicker available, you will have to use a configuration
file a set the
hydraPickerPlugin property in
summoner. See the
configuration section for more information.
Say that we want to have a common RoboHydra server for everyone working on a given project, and we decide that each user will have to “login” to the server so that RoboHydra can tell the different users apart. This login mechanism won’t have any password, which is ok because our users don’t have any incentive to pretend they are other users.
First we have to create the login mechanism. It will be a single head serving the login form and setting a cookie when the username is received:
Now we create the custom, cookie-based hydra picker by adding this code at the bottom of the file:
This code would be enough to add a cookie-based summoner and a simple login form. With this in place, you can add whatever heads or scenarios you want and have several users use this server without stepping on each others’ toes.
Back to the documentation index.