Google Scholar & Ezproxy : duo gagnant

A la demande expresse du petit Daniel B., voici la recette de Google Scholar version Bulco.

Le principe est simple : permettre à l’étudiant Lambda d’avoir accès depuis chez lui (ou depuis le Mcdo) aux ressources qu’il va trouver à travers Google Scholar et auxquelles la BU est abonnée.

La réalisation l’est tout autant. Il faut « proxyfier » Google Scholar. Toutes les ressources déclarées dans Ezproxy se trouveront alors proxyfiées aussi comme par magie. Il faut simplement récupérer la config’ gentiment fournie par OCLC, la copier dans le fichier config.txt, redémarrer le service Ezproxy, et c’est tout. Si vous débutez avec Ezproxy, regardez là.

Au passage, de la même façon, si vous avez également « proxyfié » Scopus, tous les liens « View at publisher » seront proxyfiés, enfin pas tous, seulement ceux qui pointent vers des ressources déclarées dans Ezproxy. Scopus utilisant le système DOI, veillez bien à ce que la ligne proxyfiant le DOI soit décommentée (c’est à dire sans # devant) à la fin de votre fichier config.txt.

Voyons maintenant comment se passe une session :

Le lien pointe vers Google Scholar via ezpoxy

On arrive sur l'identification CAS

On arrive sur Google Scholar (via Ezproxy, cf URL)

Les ressources délarées dans Ezproxy, ici ScienceDirect, sont "proxyfiées"

On arrive sur ScienceDirect (via Ezproxy, cf. URL)

On a accès au texte intégral en PDF

Dernière étape, mais certainement la plus importante : communiquer, encore et toujours, sur ces outils.

Read Full Post »

Ezproxy : Configuration des bases et le « Cas » Elnet

Le paramétrage des sources est relativement simple, pourvu que :

• La base soit répertoriée dans la liste présente sur le site d’OCLC. C’est le cas le plus simple, il suffit de relever le paramétrage et de l’insérer dans votre fichier. Seul hic, la dominante est anglo-saxonne, ce qui signifie que vous ne trouverez pas les paramétrages pour les bases « françaises », et que même si vous les trouvez, il faudra vérifier que l’URL est bien la bonne. Exemple : le paramétrage de Lexisnexis pointe vers la bas anglo-saxonne, vous devrez remplacer l’URL par celle que vous utilisez couramment.
• La base ne soit pas trop tordue dans son mode de fonctionnement. C’est heureusement le cas la plupart du temps.

Les liens vers les bases auront comme URL : http://ezproxy.votresite.fr/login?url=http://www.mabase.com

Après le processus d’authentification, l’URL deviendra : http://www.mabase.com.ezproxy.monsite.fr/

On configure l’accès aux bases dans le fichier config.txt après l’entrée ## Databases begin. Le paramétrage le plus simple contient :

• L’intitulé de la base précédé par Title. Il est purement informatif. On évitera d’utiliser deux fois le même. Rien n’est précisé à ce sujet mais de manière générale, j’éviterai d’utiliser guillemets et autres accents.
• Une URL précédée par URL. On indiquera l’URL qui correspond à la page sur laquelle vous souhaitez pointer. Si vous souhaitez pointer vers un formulaire de recherche au lieu de la page d’accueil, il suffit de récupérer l’URL correspondante et de l’indiquer ici.

C’est tout. Au revoir et à bientôt et n’oubliez pas le guide

Bon…presque…ça serait trop beau. Dans la plupart des cas, ça suffit. Faut tester. On n’oubliera pas de redémarrer le service pour que les modifications soient prises en compte. On testera non seulement l’accès mais aussi la recherche et tous les services proposés par la base (sauvegarde, veille, impression, envoi par mail, flux rss, export PDF…). En effet, le fait d’accéder à la base ne garantit pas le fonctionnement de tous les services.

Si par exemple, vous voulez insérer un lien vers un formulaire de recherche dont l’URL est http://formulaire.mabase.com et que dans votre paramétrage vous avez indiqué comme URL http://www.mabase.com, vous aurez soit un message d’erreur, soit le lien non « proxyfié ». En effet, Ezproxy considèrera les URL du type http://www.mabase.com et http://www.mabase.com/etc mais pas http://formulaire.mabase.com. Il faut donc ajouter une ligne du type Host formulaire.mabase.com

Autre rigolade, vous accédez à votre base, et même au formulaire de recherche. Par contre, rien ne se passe quand vous validez votre formulaire. C’est encore un coup de ce blagueur de Javascript qui n’est pas proxyfié. Faut tout lui dire à ce Ezproxy ! On va donc ajouter une ligne DJ mabase.com (DJ, c’est pour Domain Javascript) qui indiquera que le javascript doit être proxyfié aussi. Logiquement, ça devrait suffire. Si vous avez utilisé Host comme indiqué ci-dessus, ça devrait suffire aussi. Toutefois, la documentation n’étant pas très explicite à ce sujet, et si vous n’arrivez toujours pas à valider votre formulaire, ajoutez donc HJ mabase.com (HJ pour Host Javacscript) et vous m’en direz des nouvelles.

Vu comme ça, c’est du bricolage. Rassurez vous, ça l’est ! Et ça ne prétend pas être autre chose ! Mais ça marche, ça marche même très bien. Dans 95 % des cas, vous repiquerez le paramétrage sur le site d’OCLC, ou alors deux lignes vous suffiront pour paramétrer correctement l’accès à vos base.

Passons au cas Elnet.fr, la base Net Permanent des Editions Législatives.  On prend les choses dans l’ordre :

• l’URL : http://www.editions-legislatives.fr

Seul hic, il faut cliquer sur le bouton identification en haut à gauche pour accéder à la base proprement dite. Et là, c’est le drame. Plus rien ne marche, l’URL n’est plus proxyfiée et on vous demande des codes d’accès. J’ai l’impression que le mécanisme utilisé est Shibboleth. Deux choses à remarquer:

• le bouton identification utilise du javascript (regardez dans la barre d’état du navigateur). On va ajouter DJ editions-legislatives.fr
• l’URL devient https://secure.editions-legislatives, on va donc ajouter Host secure.editions-legislatives.fr (pour être propre, il faut l’ajouter avant le DJ précedent)
  

Enfin, on remarquera que ce n’est plus une connexion http qui est utilisée mais https, autrement dit une connexion sécurisée. Et là, Ezproxy n’est plus d’accord. Pour proxyfier ce type de connexion, il va falloir utiliser un certificat SSL, qui authentifie cette connexion sécurisée. Petit hic, ces connexions utilisent le port 443. Il va donc falloir être très mais alors très gentil avec votre CRI et leur demander d’ouvrir ce port à l’humble vermiceau que vous êtes. Ensuite dans le fichier config.txt, on va indiquer le port à utiliser en ajoutant LoginPortSSL 443 avant la définition des bases. On va pouvoir passer à la gestion du certificat. Ezproxy vous permet de créer un certificat « maison » qui va vous permettre de tester votre connexion. On verra ensuite comment obtenir un vrai certificat en bonne et due forme. On va ouvrir la page d’administration d’ezproxy, qui doit se trouver du côté de http://ezproxy.monsite.fr/admin. Ensuite on va accéder à page de gestion des certificats en cliquant sur Manage SSL (https) certificates, puis Create New SSL Certificate pour créer un certificat. Remplir ensuite le formulaire et cliquer sur self-signed certificates pour valider votre formulaire. Ensuite in faudra taper ACTIVE dans la case prévue à cet effet pour activer pour certificat. Redémarrer ensuite le service, et le tour est joué. Quand vous cliquez sur identification lorsque vous accéder à ELnet, l’URL suivante est proxyfiée et vous voilà authentifié sur votre base.

A partir de là, on peut mettre le champ’ au frais. Seul petit problème, votre certificat est reconnu comme un certificat pas vraiment conforme par les navigateurs qui vont produire une alerte de sécurité lors de cette connexion https. Soit, il suffit d’autoriser la navigation malgré tout, mais ça risque de freiner quelques utilisateurs. I l faudra être de nouveau très très gentil auprès de votre CRI et lui demander si par hasard, l’université n’aurait pas au fin fond d’un tiroir un certificat valide qui ne fait que vous attendre. On reprendra alors la manip précédente non pas en créant un certificat mais en important un certificat. Et, là, vous pouvez déboucher la bouteille, sortir les petits fours et boire un coup à man santé !

Ajout du 04/02/2010

A la demande des Editions Législatives, je précise que le processus d’accès distant décrit ci-dessus entre dans le cadre d’un licence autorisant cet accès distant et liée à un abonnement à la base Elnet.fr. L’accès distant se fait via une authentification, et n’est aucunement une tentative de piratage de la base Elnet.fr.

Read Full Post »

Ezproxy & Archimed : nous aussi, on peut être méchant

Résumé de l’épisode précèdent : dans un élan de générosité, Davidolib a décidé d’offrir à ces usagers des accès distants aux bases de données pour lesquelles son établissement claque des sommes folles . Comme Archimed s’occupait de son portail, il leur a demandé de mettre ça en place. Mal lui en pris, car Archimed n’en fait qu’à sa tête et a mis en place un mécanisme où tout le monde doit s’authentifier, même si on est dans la BU, ce qui exclut les extérieurs qui ne sont pas dans l’annuaire LDAP. N’écoutant que son courage, Davidolib décrypte les scripts et dévore la documentation d’Ezproxy. Au bord de la crise de nerf,  il parvient à comprendre l’affreux piège mis en place par le funeste prestataire. Il décide alors de zapper la méthode Archimed pour arriver à ses fins et vous fait part aujourd’hui de ses trouvailles.

Avertissement : ce que je vais décrire ci-après est basé sur ma propre expérience d’Ezproxy. Il se peut que les choses soient différentes chez vous.

Configurer Ezproxy se fait essentiellement en modifiant deux petits fichiers sur votre serveur dans le dossier  Ezproxy :

• user.txt qui va contenir les données propres au mécanisme d’authentification. Le logiciel permet  des filtrages assez poussé à base de groupes, que je n’ai pas eu besoin d’utiliser. Je vous renvoie donc à la documentation en ligne à ce sujet.
• config.txt qui va contenir la description technique de chaque base dont a besoin le logiciel pour fonctionner. C’est aussi ici qu’on va exclure, inclure ou auto-authentifier des tranches d’IP.

Archimed utilise un système de ticket qui reprend les mécanismes d’authentification d’Incipio sur le LDAP.  Vous avez dans ce cas des URL du type :

http://votreportail/incipio/ezp/getTicket.asp?URL=http://www.doctrinal.fr

Si on essaie maintenant d’appeler directement Ezproxy SANS passer par ce système de ticket à la noix de coco, on utilisera l’URL suivante :

http://ezproxy.votreportail/login?url=http://www.doctrinal.fr/

Vous risquez alors d’arriver non pas sur votre système d’authentification mais sur l’authentification native d’ezproxy. Il va falloir modifier le fichier user.txt : on va désactiver les informations qui indique une connexion LDAP  en collant un # devant chaque ligne et on va indiquer à ezproxy qu’il faut utiliser CAS en ajoutant l’entrée :

::CAS
LoginURL https://l’url du formulaire d’authentification cas
ServiceValidateURL https://l’url du service de validation de cas
/CAS

Il faut ensuite enregistrer votre fichier et redémarrer le service pour que les modifications soient prises en compte. Pour cela, Démarrer – Outil d’administration – Services puis cliquez sur l’onglet Standard, trouvez le service Ezproxy, clic droit et enfin redémarrer. Rééssayer maintenant l’URL modifiée et vous devriez arriver sur votre formulaire CAS habituel.

Jusque là, pour vos usagers,  concrètement, ça ne change rien. Pour nous, ça change TOUT. Maintenant, les modifications que vous allez apporter, par exemple au paramétrage des tranches IP sera pris en compte. Exit les tickets d’Archimed, on reprend la barre !

J’ai pour ma part paramétré les IP ainsi :

• IP de la BU : on squeeze Ezproxy
• IP de l’université : on passe par Ezproxy SANS authentification
• Tout les reste de l’univers passera par Ezproxy AVEC authentification

Cette fois, c’est le fichier config.txt qu’il va falloir modifier. On va ajouter ce paramétrage au début du fichier entre les indications du genre Name, Option, LoginPort, etc et la partie qui débute par ## Databases begin où seront indiquées les descriptions techniques des bases proxyfiées. La syntaxe est la suivante :

• ExcludeIP xxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy : toutes les IP comprises entre ces deux IP ne passeront pas par ezproxy
• AutoLoginIP xxxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy : toutes les IP comprises entre ces deux IP passeront par le proxy sans authentification (en fait, avec une identification automatique)

Ces deux lignes peuvent être utilisées plusieurs fois.

J’ai utilisé ce paramétrage car historiquement seules les IP de la BU étaient déclarées auprès des éditeurs. On a rectifié le tir mais ainsi je suis sur que toutes les IP de l’université auront bien accès à nos ressources.

Lors du prochain épisode, Davidolib plongera dans la jungle du paramétrage des bases et affrontera le « cas » Net permanent des Editions Legislatives

Read Full Post »

Archimed & Ezproxy : mais pourquoi sont-ils aussi méchants ?

Elvis Presley & Muhammad Ali, 1973

Ezproxy est une solution proposée par OCLC qui permet de proposer des accès distants via un service d’authentification. Il est dans l’ensemble assez simple à configurer, bien que la documentation soit famélique. J’ai été confronté à plusieurs problèmes, d’où l’idée de cette série de billets, qui je l’espère, pourra aider les personnes qui sont dans la même situation.

Je n’ai pas installé Ezproxy personnellement, c’est Archimed qui s’en est chargé. En effet, c’est la solution retenue par Archimed pour gérer les accès distants sur sa solution Incipio. A titre d’information, Ezproxy est installé sur un serveur dédié afin de ne pas surcharger le serveur web. A part ça, la documentation (en ligne sur le site d’OCLC) même si elle est maigre, me semble claire; l’installation ne devrait pas poser de problème.

Archimed a ensuite  créé un encart avec des liens pour que nous puissions tester les accès distants aux bases auxquelles nous sommes abonnés. Il ont fourni (après demande insistante) une documentation…de 4 pages qui vous indique comment déclarer une nouvelle base. Soit 4 pages, c’est pas terrible, mais dans la mesure où ce n’est pas un logiciel Archimed d’une part, et où d’autre part la documentation est éparse et peu fournie sur le site d’OCLC, on ne peut pas leur en vouloir, enfin pas pour ça (bon, attendez la suite ;-))

On modifie donc toutes les URLs de nos bases pour proposer ces accès distants. Tout baigne, quand on veut accéder à une base de données, on est redirigé vers l’écran d’authentification de l’université (ici, c’est CAS qui gère l’authentification sur le LDAP), puis on est redirigé vers la base de données en passant par ezproxy… Et on s’aperçoit avec effroi que ce mécanisme s’applique aussi aux postes de l’université et donc de la BU aussi. Résultats des courses : il faut s’authentifier même si vous utilisez un poste de la BU ou un poste de l’université, et bien sur le public « extérieur », qui n’est pas dans le LDAP, se voit privé de toute consultation de base de données.

On jette un oeil à la doc, on s’aperçoit qu’on peut exclure des tranches IP, on envoie donc nos remarques et désidératas à Archimed. Sans réponse (mince, on a déjà payé la facture !), on se dit qu’on va se débrouiller tout seul, on parcourt en long, en large et en travers la documentation pour comprendre comment exclure des tranches d’IP de ce mécanisme. On modifie donc le paramétrage…et on s’aperçoit que ça ne marche toujours pas. On s’arrache les cheveux, on remarque que l’url fournie par Archimed pour accéder aux bases ne ressemble en rien à l’URL dont parle la doc d’ezproxy, on remarque aussi qu’Archimed nous parle d’un accès par ticket. Dans la doc, on regarde comment fonctionne ce type d’accès : un ticket est délivré par un mécanisme extérieur à Ezproxy, qui peut être du code ASP. On compare le script fourni par ezproxy au script utilisé par Archimed, et là on s’aperçoit que ça n’a rien à voir, qu’Archimed a tout réécrit pour l’interfacer à sa solution, et que donc le mécanisme d’authentification est le même que celui utilisé pour s’authentifier sur le portail, et que c’est lui qui délivre le ticket. Vous pouvez toujours modifier votre paramétrage d’Ezproxy, de toutes façons l’authentification a lieu AVANT de parvenir à Ezproxy…Il va donc falloir zapper le mécanisme Archimed et revoir tout ça au calme. La suite au prochain épisode

Évidemment, arriver à cette conclusion m’a pris des semaines, à décrypter des scripts, à parcourir la documentation dans tous les sens, à frôler la crise de nerfs. Ce n’est pas de l’atermoiement, simplement une chronique de ce que peut être une partie de mes tâches, chronophage et stressante par manque d’information (et clairement par manque de pression sur un fournisseur que l’on qualifiera pudiquement d’indélicat).

Read Full Post »

Tester ses accès distants…sur place

Ami bibliothécaire, dans ta grande bonté d’âme, tu offres à tes lecteurs la possibilité de consulter depuis chez eux les bases de données auxquelles ta bibliothèque est abonnée à prix d’or. Que ce soit grâce à Shibboleth, EZProxy ou un VPN,  peu importe, mais ça existe et ça marche. En es-tu si sur ? Parfois, quand même, au beau milieu de la sieste d’après déjeuner nuit , un doute t’assaille :  « Et si ça ne marchait pas ?. Ça marche quand je teste depuis mon bureau mais depuis l’extérieur ? » Heureusement Malheureusement, ce doute te quitte dès que tu franchis le seuil de ta bibliothèque pour rentrer chez toi. Et tu n’as pas que ça à faire que de tester depuis chez toi que les ressources que tu proposes sont bel et bien accessibles.

L’ami, j’ai un petit truc qui va te permettre de tester depuis ton bureau tes accès distants. Il suffit de faire croire que ton IP n’est pas une IP de ton établissement, et carrément, une IP même pas française, un IP du bout du monde, tiens, pour être sur que ton lecteur de l’Ontario ou du Minnesota a bien accès à tes ressources. On va utiliser le logiciel Ultrasurf, téléchargeable ici. Ce soft dira bien sur quelque chose aux habitués de justin.tv, bien utile les soirs de foot ;-).  Juste un executable à télécharger à utiliser sans installation pour IE, un add-on pour Firefox, téléchargeable ici. Une fois lancé, le logiciel va nous connecter à un proxy et nous donc nous permettre de faire croire au monde entier que notre IP est une IP nord-américaine. On peut donc regarder le foot sans être embêté tester ainsi nos accès distants…sur place

Read Full Post »

Nouveau portail documentaire : Phase « Installation des serveurs »

Ca y est, l’installation des serveurs par Archimed a été faite fin juillet et l’installation des services est en cours, on va bientôt pouvoir les tester. Trois serveurs ont donc été installés :

• Un serveur Web qui contiendra le site web
• Un serveur qui servira à gérer les réservations des postes publics, les impressions, et qui sera contrôleur de domaine.
• Un serveur reverse proxy (Ezproxy) pour l’accès distant aux ressources en ligne.

On a prévu de coller un widget « Meebo » sur le site, histoire de faire comme tout le monde communiquer avec nos clients usagers.  Je me demande comment il se comporte avec les milliards de connexions simultanées qui nous attendent :-). Le fait de passer d’une page à l’autre me fait me demander si on peut vraiment avoir une conversation suivie. Faudra peut-être se satisfaire d’un lien pour l’ouvrir dans un pop-up. On verra…Je renvoie à l‘article paru dans Computer Librairies sur ces services (attention , accès restreint aux abonnés à Academic Search Premier)

Read Full Post »