Bouton de proxyfication des URL dokelek

Au SCD de Poitiers, depuis que nous utilisons le logiciel EZPaarse pour analyser finement les statistiques d’utilisation de la documentation en ligne (en récupérant notamment des informations sur le niveau d’étude, la filière ou le laboratoire d’appartenance des utilisateurs), nous essayons au maximum de faire passer les utilisateurs par notre reverse proxy EZProxy afin de disposer de ces fameuses informations.

Cela implique des changements d’habitude chez nos utilisateurs, notamment pour la consultation de la documentation depuis les postes de l’Université. En effet avant notre utilisation d’EZPaarse, les IP des postes situés dans l’Université étaient paramétrés pour se connecter à EZProxy en autologin: il n’y avait pas besoin d’authentifcation, et donc pas de transmission d’informations sur les caractéristiques des utilisateurs. Pour récupérer ces informations, cette possibilité a été supprimée de l’ensemble des postes universitaires sauf les postes publics des BU, afin de permettre aux lecteurs inscrits dans les BU mais non universitaires de pouvoir consulter la documentation en ligne depuis l’intérieur des BU.

Parallèlement et toujours pour pouvoir récupérer ces informations sur les utilisateurs, les IP des postes universitaires ont cessé d’être déclarées chez les éditeurs de documentation en ligne, pour forcer l’accès par EZProxy. Concrètement, une URL publique ou commerciale d’un éditeur ne donne plus accès au texte intégral même si nous sommes abonnés: il faut impérativement passer par l’URL « proxyfiée », qui permet l’authentification, puis l’accès au texte intégral.

Lorsqu’un utilisateur consulte régulièrement directement une ressource, il lui « suffit » de penser à changer son favori une fois pour toutes (ou de passer systématiquement par le site Internet du SCD, rubrique « La doc en ligne« , ce qui peut lui permettre de voir au passage nos actualités…). Mais lorsqu’il passe par un autre moteur de recherche pour arriver sur une ressource, il arrive sur une URL « classique » et il lui faut la proxyfier pour arriver sur le texte intégral. Nous avons notamment rencontré ce cas avec des chercheuses qui utilisaient revues.org pour arriver sur Cairn.

Pour proxyfier une URL classique, il y a en gros 3 solutions:

  • copier/coller le préfixe/suffixe du reverse proxy à l’URL classique
  • utiliser un plug-in à enregistrer dans son navigateur internet et à configurer pour qu’il fasse la même chose (EZProxy Helper sur Firefox, EZProxy Redirect sur Chrome…). À noter qu’il est possible d’adapter ces plug-in pour qu’ils soient directement installés avec la configuration adéquate à son établissement: c’est ce qui a été fait pour le SCD d’Aix-Marseille
  • enregistrer un favori internet capable de faire la même chose que le plug-in, mais pré-paramétré et plus facile à enregistrer dans son navigateur.

La responsable de la documentation en ligne a découvert cette 3e solution grâce aux collègues de l’INSA qui ont mis en place un bouton « login via Insa« . Voici comment nous l’avons mis en place à Poitiers:

  • le collègue du service informatique qui gère notre EZProxy, l’envoi des logs à EZPaarse et la visualisation des informations de connexion via Kibana, à qui nous avons soumis l’idée de ce bouton de proxyfication, nous a proposé  que l’apparence du bouton soit identique à celle des boutons « Visitez le site » que nous avons sur nos pages dokelek (ex: la page d’accès au DOAJ). Problème: dans le CMS KSup (qui gère notre site comme le site de l’Université) tel que nous l’utilisons, ce bouton est accessible via des pages « Liens » et pré-paramétré: dans l’outil d’administration, nous remplissons uniquement l’URL et les informations concernant la ressource, mais nous ne pouvons pas directement manipuler le bouton pour l’intégrer dans une autre page du site ou changer son intitulé. Il nous a donc fallu faire un clic droit et examiner l’élément pour repérer le code HTML de ce bouton et l’adapter. Voilà le code de départ:

<p class= »button »> <a class= »icon-globe » href= »http://ressources.univ-poitiers.fr/login?url=http://exemple.com &raquo; title= »Visitez le site » >

  • ce même collègue nous a indiqué qu’il suffisait de mettre comme « lien » sur le bouton le code suivant:

javascript:void(location.href=%22http://ressources.univ-poitiers.fr/login?url=%22+location.href);

Nous avons été confrontés à un problème: si on applique strictement le code de départ, c’est à dire :

<p class= »button »> javascript:void(location.href=%22http://ressources.univ-poitiers.fr/login?url=%22+location.href); » title= »Login via UP » >

Le code n’est pas correctement interprété. Le bouton est tronqué, le lien ne se fait pas, le titre n’apparaît pas, bref rien ne va.

Avec le code

<p class= »button »> » javascript:void(location.href= »http://ressources.univ-poitiers.fr/login?url=« +location.href);> Login via UP</a></p>

C’est un peu mieux, on obtient bien un bouton « entier » mais il n’interprète pas la commande de proxyfication correctement, il renvoie simplement vers l’URL http://ressources.univ-poitiers.fr/login?url=.

Nous avons dû faire un détour par le code du login de l’INSA pour comprendre notre erreur. Le code du bouton de l’INSA est le suivant:

<a name= »Doc Elec » href= »javascript:void(location.href=%22http://docelec.insa-lyon.fr/login?url=%22+location.href); »><img src= »http://scd.docinsa.insa-lyon.fr/sites/docinsa.insa-lyon.fr/files/loginvia.png &raquo; alt= »Login Via INSA » title= »Login via INSA » width= »150″ height= »40″></a>

Comme l’INSA utilise une image pour habiller son bouton, nous avons perdu du temps à intégrer une image dans notre bouton pour aligner notre code sur le leur. Avec le code:

<p class= »button »><a class= »icon-globe » href= »javascript:void(location.href=%22http://ressources.univ-poitiers.fr/login?url=%22+location.href); »><img src= »http://scd.univ-poitiers.fr/servlet/com.univ.utils.LectureImageToolbox?TAG=%5Bid-image%5D1326273338380%5B/id-image%5D &raquo; alt= »[legende-image]1326273338380[/legende-image] » title= »[title-image]1326273338380[/title-image] » data-pin-nopin= »true » style= »width:80px;height:40px;margin:0px 0px;border:px solid;float:; » /></a></p>

 

 

On obtient un bouton qui a cette apparence: bouton_logo_univ_poitiers et qui fonctionne correctement.

Mais plus simplement, l’erreur de notre code précédent qui  ne proxyfiait pas venait du fait que nous avions omis le href devant le javascript:void. Il faut donc pour que le code marche correctement, non seulement ajouter le href manquant, mais aussi faire attention à écrire les premiers guillemets «  », et les 2e: %22%22.

On obtient donc le code:

<p class= »button »> <a class= »icon-globe » title= »Login via UP » href= »javascript:void(location.href=%22http://ressources.univ-poitiers.fr/login?url=%22+location.href) » ;> Login via UP </a></p>

 

 

qui nous permet d’avoir le petit bouton que vous trouverez sur cette page, qui explique aux usagers comment se connecter à la documentation en ligne.

 

 

Publicités
Cet article, publié dans Documentation électronique, le numérique c'est chic, est tagué , , , , . Ajoutez ce permalien à vos favoris.

4 commentaires pour Bouton de proxyfication des URL dokelek

  1. Après avoir partagé mon scepticisme sur certains points de ce billet sur twitter, je me dis qu’il vaut mieux développer ici qu’en 140 caractères ce sera plus pertinent.

    La création et promotion du widget me semble une bonne chose bien entendu, et favoriser l’utilisation de liens proxyfiés ou de cet outil est certainement une bonne chose pour augmenter le volume de logs sur lesquels peut travailler ezpaarse et ainsi avoir une vision d’ensemble des usages et donc, puisque c’est le but ici, optimiser l’utilisation des budgets de la docelec par rapport aux usages. Pas de soucis sur ce point.

    Là où je m’interroge c’est sur : « les IP des postes universitaires ont cessé d’être déclarées chez les éditeurs de documentation en ligne ». En effet, même avec la meilleure volonté du monde, on n’arrivera jamais à faire passer correctement à tous nos utilisateurs qu’il faut et qu’ils doivent utiliser le bookmark. C’est une étape en plus, une configuration à faire, et comme on navigue sur plusieurs machines différentes, est-ce que l’usager va faire l’effort d’ajouter le bookmark à chque fois (et pourquoi le forcer à le faire s’il ne navigue que depuis l’université) ? Et sur son smartphone/tablette qu’il utiliserait via une borne wifi de l’université par exemple, peut-on faire la manip sur les navigateurs des smartphones ? Je ne suis pas sûr.

    J’entends bien la question de l’optimisation budgétaire mais celle-ci se fait me semble-t-il sur un arbitrage entre ressources plutôt qu’une utilisation en valeur absolue, donc on peut imaginer qu’en laissant les accès IP, les utilisations directes n’avantageraient/désavantageraient pas une ressource plus qu’une autre.

    Voilà en résumé mais en un peu plus développé que sur twitter mes points d’interrogation sur cette proxyfication forcée des accès, en espérant ne pas avoir fait trop long, et merci quoi qu’il en soit pour le retour d’expérience, il faudra que je me colle à la création d’une extension et/ou bookmarklet sur notre site, pour faciliter la proxyfication pour un usager à distance qui passe directement par un moteur de recherche pour accéder à ses ressources.

    • annesophiepascal dit :

      Merci beaucoup pour ce commentaire. Je trouve l’échange sur twitter très intéressant, je me permets de signaler le lien vers le tweet qui l’a déclenché pour que les personnes qui le veulent puissent lire les réactions là-bas: https://twitter.com/GillesRusse/status/798225309418065920.
      Le présupposé de départ dans notre cas était en effet que nous voulions utiliser EZPaarse avec des stats les plus complètes possibles et que nous voulions connaître le plus possible les UFR et les labos qui utilisent les ressources, et lesquelles. Que ce soit pour des raisons budgétaires ou pour d’autres raisons, c’était « la commande ». Parti de là, nous nous sommes tournés vers un établissement qui utilisait EZPaarse depuis plusieurs mois (le SCD de l’Université de Lorraine) qui nous ont expliqué qu’ils avaient supprimé l’autologin dans EZProxy sauf sur les postes publics des BU, et les IP chez les éditeurs. C’est la garantie de ne pas biaiser les statistiques parce que les membres de tel labo auraient l’habitude de se connecter depuis les postes des bureaux, alors que les membres de tel autre auraient l’habitude de se connecter à distance. Cette mise en place a été validée par le service informatique, c’était en quelque sorte le pré-requis à leur travail sur la mise en place d’EZPaarse.
      Moi aussi j’entends bien ce que tu dis, que « normalement » les stats sur place ne devraient pas modifier fondamentalement la répartition des usages sur les différentes ressources, mais à moins de le vérifier, comment en être sûr?
      Ceci dit, nous avons bien conscience que nous aurons toujours des consultations qui « échapperont » à EZProxy/EZPaarse: les ressources non ou imparfaitement parsées, les accès CNRS, les accès « sauvages » type #icanhazpdf ou scihub, les chercheur.se.s qui ont l’habitude de demander à des personnels d’appui de faire une partie des recherches documentaires, etc. Sans compter que nous n’avons pas supprimé les accès Shibboleth et que les éditeurs n’ont pas tous la même réactivité à supprimer les IP.
      Sur la question de l’étape en plus: c’est tout à fait vrai, c’est un « obstacle » supplémentaire pour l’utilisateur. Mettre en place le bouton n’est qu’une façon « d’adoucir » cet obstacle, mais oui il faut que l’utilisateur se l’approprie. Cela dit, le bouton fonctionne aussi quand on est à distance, et pour le coup je trouve que c’est un vrai progrès=donc une solution mise en place pour pallier une nouvelle difficulté de l’accès sur place, s’avère être un gros progrès pour l’accès distant.
      Pour résumer, si vous n’avez pas la commande qui est la notre, si pour vous peu importe que des statistiques incomplètes soient issues d’EZPaarse (mais du coup quelle est la plus-value d’EZPaarse par rapport aux stats éditeurs…?), je ne vois pas l’intérêt de compliquer l’accès sur place. En revanche, comme tu dis, la mise en place du bouton de proxyfication est de toute façon intéressante pour l’accès distant. Ce que je voulais surtout montrer dans le billet, principalement aux gens comme moi qui ont peu l’habitude de patouiller du code quel qu’il soit, c’est que c’est vraiment tout bête à faire.

  2. annesophiepascal dit :

    Je réponds en commentaire à une question qui m’a été posée sur twitter: https://twitter.com/nicomo/status/798503063627722752 sur la communication qui a été faite au sujet des informations récoltées par EZProxy/EZPaarse.
    La communication officielle a été faite par le VP numérique. Je ne copie/colle pas son message, mais il expliquait:
    – que la documentation en ligne prend une part croissante, dans les activités et dans les budgets
    – en conséquence, la politique documentaire nécessite une connaissance fine des usages
    – nous participons donc à EZPaarse, projet national
    – en conséquence, les accès depuis les murs de l’Université vont être modifiés.
    Suivi de l’explication sur la nécessité d’utiliser des URL proxyfiées, l’information que les statistiques seraient communiquées à la communauté universitaire, et les contacts pour l’aide technique.
    Les réactions que nous avons eues jusqu’ici concernent uniquement les difficultés d’accès, telle celle que je cite dans le billet (je passe d’abord par revues.org avant d’arriver sur Cairn), ou bien des BU dont les postes publics n’avaient pas été laissés en autologin, avec comme conséquence impossibilité pour les publics « de passage » de se connecter. Nous n’avons eu aucune question/curiosité sur les informations recueillies. Ça viendra peut-être, en tout cas je l’espère…?

  3. Thomas Jouneau dit :

    Merci beaucoup pour ce billet, très clair et très bien documenté. Je n’ai pas grand chose à ajouter, nous avions suivi la même démarche (notre bookmarklet avait été « piqué » aux collègues de Nice pour notre part). Je crois que je renverrai volontiers vers cette page pour les futures questions…
    Je souhaite juste ajouter une précision importante qui peut également constituer une solution pour beaucoup d’usagers : les fonctions de réécriture automatique des URL offertes par les logiciels bibliographiques (Zotero notamment, je ne connais ni Endnote ni Citavi mais je crois qu’ils le font également), et qui permettent au bout d’un certain temps (chaque domaine doit être reconnu une fois) de naviguer en toute transparence.
    Concernant l’autologin, même s’il empêche la récupération automatique d’informations d’affiliations, il peut éventuellement servir de base à une qualification en post-traitement dès lors que l’on est sûr que l’IP en question provient bien de telle unité ou composante. Evidemment, c’est double boulot, donc peut-être pas à recommander mais pas inenvisageable non plus.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s