The act of proving the identity of a computer system user. Authentication in the context of web applications is usually performed by submitting a username or ID and a piece of private information (factor) such as a password.

In Raider the authentication process is defined by a series of Flow objects. Those are extracted from the _authentication variable in the hyfiles, and stored inside an Authentication object. It’s also accessible from the Raider directly:

>>> import raider
>>> app = raider.Raider("my_app")
>>> app.authentication
<raider.authentication.Authentication object at 0x7fbf25842dc0>

A factor can be something the user knows (passwords, security questions, etc…), something they have (bank card, USB security key, etc…), something they are (fingerprint, eye iris, etc..) or somewhere they are (GPS location, known WiFi connection, etc…).

Finite state machine

A mathematical model of computation abstracting a process that can be only in one of a finite number of states at any given time. Check the Wikipedia article for more information, since it explains this better than me anyways.


A Raider class implementing stages. To create a Flow object, you need to give it a name, a Request object, and optionally outputs and operations. Check the Flow configuration page for more information.


A Raider class containing all Flows objects that don’t affect the authentication process. The Functions object is extracted from the _functions variable.


The documentation uses the term hyfiles to refer to any *.hy file inside the project’s configuration directory. Each will be evaluated in alphabetical order by Raider.

The objects created in previous files are all available in the next file, since all the locals() get preserved and loaded again when reading the next file. A common practice is to prepend the file names with two digits and an underscore, for example 03_authentication.hy and 09_users.hy.

Multi-factor authentication (MFA)

An authentication method in which the user is granted access only after successfully presenting two or more pieces of evidence (factors).


A piece of code that will be run after the HTTP response is received. All Operations inherit from Operation class.

All defined Operations inside the Flow object will stop running when the first NextStage Operation is encountered.

Raider comes with some standard operations, but it also gives the user the flexibility to write their own Operations easily.


A piece of code that can be used to generate inputs for outgoing HTTP Requests, and/or extract outputs from incoming term:Responses <Response>. All plugins inherit from Plugin class.

When used inside a Request, Plugins acts as input and replace themselves with the actual value.

When used inside the Flow’s :output parameter, Plugins act as outputs from the HTTP response, and store the extracted value for later use.

Raider comes with some standard plugins, but it also gives the user the flexibility to write their own Plugins easily.


To avoid confusion with the Application class, Raider uses the term Project to refer to an application, with existing hyfiles.


A HTTP request with the defined inputs. In Raider it’s implemented as a separate class Request. This however is not used directly most of the times, but as an argument when creating the Flow object in hyfiles.

When used inside a Request, a Plugin will replace itself with its actual value during runtime.


A HTTP response from which the outputs are extracted and stored inside the Plugins.

When the Flow object containing this response is received and processed, the Operations are executed.


A Raider concept describing the information exchange between the client and server, containing one request and the respective response.