here is a brief tutorial on how to collect the direct login
configuration when the bookmarklet does not work. I have edited it
quite in a hurry, so please report any error on suggestions on how to
improve it. Once settled, we will add this to the "official"
documentation.
Best regards,
Giulio Cesare
How to debug a misbehaving direct login configuration
--------------------------------------------------------------------------------
You need to use Firefox and the "Tamper data" plugin
(<https://addons.mozilla.org/en-US/firefox/addon/966>).
With this configuration, go to the login page of the site you are
interested in. Fill all the login form, but do not submit it yet.
Before submitting the form, you need to enable the tampering module:
go to the "Tools" menu and select the "Tamper Data" item.
A new windows shows up, and you need to press the "Start Tamper" button.
After enabling the tampering, you can submit the login form. Once you
submit the login form, a dialog should appear asking you whether to
tamper the data or not (see Picture 1). If you allow the tampering, a
new panel shows up with all the details of the request (see Picture
2).
With the data on this panel you may build the direct login
configuration; below are the detailed instruction on how to extract
the relevant data.
Here how a direct login configuration looks like (the "## description
##" are the placeholders that you need to configure in order for the
configuration to work correctly):
{
"page": {"title": "## title ##"},
"form": {
"attributes": {
"action": "## action url ##",
"method": "post"
},
"inputs": [
## list of fields definition ##
]
},
"version": "0.2.3"
}
The "## title ##" is a simple string used to give the default name to
the card of direct login created using the configuration; its value is
not relevant for the direct login behaviour.
The "## action url ##" should be set to the value found in the spot
marked as "1" on the tamper data panel (shown in the attached Picture
2).
Now we need to take care of all the field definitions that have to
replace the "## list of fields definition ##" placeholder; each field
definition has the following structure:
{"type": "## type ##", "name": "## name ##", "value": "## value ##"},
ATTENTION: each field definition must end with a comma character (,),
but the last one. This is very important to keep the configuration
syntactically correct; otherwise the parser will not be able
We need to add a new field definition for each element in the panel
marked as "2" on Picture 2.
## type ##
You usually need to use only three different type of fields:
- text / password
- hidden
Text / password is almost equivalent, and the only difference is when
the configuration is used to generate a card; otherwise they behave
exactly the same.
You have to use one of these type when need to bind a field of the
card to a field of the login form; commonly, this means that you have
at least the username/password field typed either as text or password.
The value of the field marked as text/password is usually left empty
(""), as the real value is later filled with the matching value of the
card field.
All other fields can be usually marked as hidden; these are all the
fields that need to be submitted to the form, but with fixed data not
matched in any card field.
## name ##
This is the value reported in the panel marked as "2" on Picture 2.
## value ##
For all hidden fields, this is the value reported in the panel marked
as "2" on Picture 2. for all other fields, this is usually left empty
("")