Add dedicated e2e login tests

[AdrienClairembault]

Why do we need a dedicated login test ?

Our first implementation of e2e tests uses GLPI UI to login before a given test.

As per cypress official recommandations, this should be avoided: https://docs.cypress.io/guides/references/best-practices#Organizing-Tests-Logging-In-Controlling-State.

More details can be found in the cypress presentation from the assertjs 2018 conference: https://www.youtube.com/watch?v=5XQOK0v_YRE

To sum it up, the login process should be validated from the UI once in a dedicated test.
Then, all others tests should programmatically log into the application using some kind of direct HTTP requests.

Thus, I have moved the current login implementation into a dedicated test and added a new programmatic login command that can be used for all others tests.

Programmatic login

To implements programmatic login, we have two barriers:

• The login form inputs names are randomized (thus we can't just do a POST request with the username and password keys).
• We have a CSRF token.

Randomized inputs

To fix the randomized names issue, I've added some changes to the login front file.
It will now use predetermined names (username, password, remember_me) if it receives a request from a testing environnements that doesn't come from the UI.

CSRF

For the CSRF tokens, cypress give some example of the possibles strategies here: https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/logging-in__csrf-tokens/cypress/e2e/logging-in-csrf-tokens-spec.cy.js

I've chosen the 3rd strategy "expose CSRF via a route when not in production", which should bring the most performances while being easy to maintain.

The CSRF token will thus be retrieved by doing a GET request on front/csrf.php, a special page that does not return anything if the environnements is not testing.

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets

[AdrienClairembault]

@cedric-anne Regarding the two new behaviors that are only enabled while in testing env, would it be acceptable to enable them instead for all envs that are not production ?

The idea is to cover both development and testing env, because with the current implementation developers that want to do test driven development are forced to set their env to testing (which is not ideal).

[cedric-anne]

I do not like the idea of adding specific endpoints for testing. It means more code to maintain, potential security issues on them, ...

[AdrienClairembault]

This seems the simplest strategy among those demonstrated in the link above.

The alternative is to parse the login page to get the token, which IMO would generate more code to maintain compared to a simple endpoint with 3 lines of code.

edit: also, the file could be placed in a special folder that is deleted when building the production archive.

[cconard96]

I do not like the idea of adding specific endpoints for testing. It means more code to maintain, potential security issues on them, ...

Agree. Plus, I don't think there is much reason to worry about having a fresh login for every test. If you are testing a session-reliant feature like user preferences, just make sure to clear the session in the beforeEach or before hook in that specific spec before calling the login command.