Sécuriser un site web avec TYPO3 !

Il y a quelques mois de cela j’ai eu l’occasion de me retrouver devant un petit problème de sécurisation d’un site web, plus précisément d’un intranet et cela m’a amené à trouver des solutions (et aux développeurs avec qui je travaille surtout !).

Voici le cas de figure que je vous propose ici d’étudier :

Un intranet qui proposerait une page de connexion qui ne serait accessible qu’aux visiteurs uniquement. Aucune autre page du site ne devrait être accessible sauf après s’être identifié via la page de connexion.

Notez que si le formulaire d’authentification aurait du se trouver sur la page d’accueil, cela aurait été simple, mais dans ce cas précis je devais créer une page spécialement conçu pour l’authentification avec un unique formulaire d’identification.

Voici une capture d’écran qui représente l’arborescence du site :

Arborescence d'un site TYPO3

Comme vous pouvez le voir sur cette image, la page root (JGH) se trouve sous la page de connexion, de manière à pouvoir s’en servir pour appliquer les droits de sécurité, ce qui donne concrètement ceci :

– Page de connexion (accessible à tous)
– Page root du site (protégé pour un groupe d’utilisateurs ainsi que les sous pages)
— Page d’accueil
— Page des actualités
— Page du plan du site
—- etc ..

Sécuriser la page du site et des sous-pages n’est pas un problème en soit car il suffit pour cela d’éditer les propriétés de la page ROOT de votre site ainsi :

Gestion des accès avec TYPO3

Le problème se situe plus au niveau de l’accès à la page de connexion. Ou mettre celle-ci si vous voulez que ça fonctionne ?

Si vous la mettez comme sous-page de votre page root, personne ne pourra y accéder car toutes les sous-pages sont inaccessibles :

Page de connexion à la mauvaise place

On pourrait créer un autre niveau pour mettre toutes les sous-pages Accueil, Actualités et Plan du site mais cela reviendrait presque au même et compliquerait les choses. Dans ce cas nous devons revenir à l’idée de départ.

J’ai donc commencé à chercher des solutions avec ce que TYPO3 me proposait et en l’occurence l’extension de macmade (loginbox_macmade), mais finalement nous avons opter pour l’extension “newloginbox” qui allait être bientôt intégré avec TYPO3 4.2 sous le nom de “felogin” et qui me permet d’effectuer une redirection après authentification :

Redirection avec l'extension felogin

Même chose avec l’extension de macmade :

Configuration du plugin loginbox_macmade

Malheureusement ça ne règle pas un autre problème ! Que se passe t’il si quelqu’un est déjà authentifié et décide de revenir sur le site (en tapant l’url du site), il y a de grande chance pour qu’il se retrouve sur une page d’erreur. Car avec notre configuration, nous avons fait en sorte que la page “Connexion” ne soit plus accessible quand un membre est connecté et le système tentera de repousser le dit membre vers la page parente à la page de “Connexion“ et étant donné que c’est la page la plus haute dans l’arborescence, cela ne fonctionnera pas => Message d’erreur.

Pour que nous puissions avoir un système 100% efficace, il faudrait que le plugin de connexion (newloginbox, loginbox_macmade ou felogin) offre la possibilité de rediriger l’utilisateur vers une page spécifique si quelqu’un tenterait d’y accéder et qu’une session “Frontend user” existerait. Ce n’est malheureusement pas le cas à ma connaissance avec les extensions citées ci-dessus.

La solution :

Finalement pour résoudre le problème, j’ai laissé soin aux développeurs de modifier le fonctionnement de TYPO3 pour qu’il puisse rediriger les membres vers la bonne page d’accueil et non plus la page de “Connexion”.

Je ne me souviens guère pourquoi cette modification ne s’est pas effectué directement dans l’extension que nous utilisions, à savoir “newloginbox”, sans doute parce qu’un autre problème se posait à nous : Que se passe t’il si quelqu’un tente d’accéder à une sous-page de la page root de notre site ? En l’occurence à une page qui est protégé aux visiteurs du site. Et bien la redirection va s’effectuer vers la page d’accueil qui ne doit pas être accessible sous aucun pretexte. Une fois de plus, il y a de grande chance pour que TYPO3 génère une nouvelle erreur.

Enfin tout ça pour dire qu’une fois que vous avez identifié ou est ce que TYPO3 effectue ces différents tests d’authentification, vous comprenez tout de suite qu’il faut mieux faire appel aux développeurs et évaluer pour voir si la XCLASS en question ne doit pas s’effectuer plutôt dans le core de TYPO3.

Conclusion :

Que devez-vous retenir de tout cela ? Car certaines parties de mes explications ne sont sans doute pas très clair ;-).

Et bien ce que vous devez vous souvenir, c’est que actuellement aucune extension ne prend en compte correctement la redirection des sessions quand une erreur d’authentification est rencontré. Le système à pour habitude de renvoyer les visiteurs vers la page parente, du moins en trouver une qui soit accessible pour tout le monde et si ce n’est pas le cas, renvoyer une erreur. Je ne vous est pas parlé ici de la gestion des erreurs 404 qui a été réglé en même temps que le reste car notre cas de figure posait aussi des problèmes.

Donc si un jour vous avez la même configuration que celle décrire dans ce billet, accrochez-vous et fouillez dans le code de TYPO3 !

Pour info, voici notre XCLASS (TYPO3 4.2)

$TYPO3_CONF_VARS[TYPO3_MODE]["XCLASS"]['tslib/class.tslib_fe.php']
=t3lib_extMgm::extPath($_EXTKEY)."class.ux_tslib_fe.php";

Notre code s’est inspiré de l’extension “beko_improved_login”