Une fois le reverse-proxy en place, et pour éviter à nos usagers de s’embrouiller la tête avec un nouveau chemin “accès distant” se rajoutant au site Bu et à l’ENT, nous avons rusé.
Si l’usager veut accéder aux bases de données du SCD, il conserve ses habitudes et se rend là sur notre site. Sans qu’il s’en aperçoive, un petit script développé par Magic Manu du STIC détermine alors sur la foi de son IP si l’impétrant est In ou Off campus.
Dans ce dernier cas (accès hors campus et donc à distance), le script rajoute à la volée à toutes les URL des bases de données le préfixe de notre serveur distant : le clic sur icelles déclenche l’authentification puis, si celle-çi est réussie, l’accès à la base de donnée à distance.
Voilà. Rien de compliqué. La prochaine fois, je vous dis comment que nous faisons pour les revues, et je me lance dans une grande autocritique.
Bravo, mais comment faites-vous pour connaître “toutes les url” à réécrire ? Chaque base de données est si vaste et si mouvante…
@olivier : attention, je parle de l’url de la base elle-même. Exemple : “www.scopus.com” est réécrite” https://budistant.univ-angers.fr/http/www.scopus.com/” ; à partir de là, tout le traffic distant avec scopus est “encapsulé” DANS scopus et tant que scopus ne fait appel qu’à lui-même, ça tourne.
Je ne sais pas si je suis clair…
si si, merci pour la prompte explication !
@olivier : mais la question est bonne, le problème se pose pour les revues, j’en parle dans le prochain billet 🙂
En fait, on a souvent des problèmes de réécriture quand une URL appelée dans une page n’est pas sous la forme href=”http://etc.” que le proxy identifie bien, mais planquée dans du code JavaScript
(comme
… 30 lignes de code javascript …
@import (‘/css/style.css’)
… 30 lignes de code javascript …
Et là ça devient pénible.
Les éditeurs sont d’une inventivité formidable pour créer du code pourri.
@Lully : c’est fini de déflorer mon billet de demain, oui ?? 😉