Comme vous le savez, en web il est possible d'accéder à un document directement par son UNID, mais aussi par l'intermédiaire d'une clé, clé qui doit correspondre au contenu de la première colonne triée de la vue en question. C'est un moyen très commode de mettre en place des URL significatives dans les applis web Domino, et c'est bien plus sexy et parlant qu'une suite de 32 chiffres hexadécimaux, comme le démontre sans ambiguïté possible l'exemple fictif suivant :

http://host/darkblog.nsf/billets/faites-un-geste-pour-la-france?opendocument

Seulement voilà, quand les documents en question sont protégés par des champs lecteur, ça peut vite tourner au drame. En effet, que se passe-t-il lorsqu'on tente d'accéder anonymement à un document protégé via son UNID ? Domino détermine qu'Anonymous n'a pas accès au document et retourne une demande d'authentification. Jusque là, tout va bien. Maintenant, que se passe-t-il lorsqu'on réitère la même procédure mais en ouvrant le document protégé via sa clé ? Et bien c'est facile : comme on n'a pas accès au document, il n'est pas listé dans la vue, du coup la clé n'est pas retrouvée, et là je vous le donne en mille : une belle erreur 404 des familles.

Ce genre de situation n'est pas censé se produire dans un cadre de navigation classique dans une appli, mais dès lors que les utilisateurs commencent à bookmarker des pages et/ou à se les refiler par mail ou par Sametime (et on saurait difficilement leur reprocher), c'est là que les ennuis commencent.

Si l'appli requiert nécessairement l'authentification des utilisateurs, cela peut se régler aisément en paramétrant correctement l'ACL ou en rajoutant systématiquement &login aux URLs des liens. Dans le cas contraire, je ne vois malheureusement pas de solution vraiment efficace, ni même triviale.
La solution que j'ai mise en place de mon coté - puisque j'ai été confronté à cette deuxième situation vendredi dernier - a consisté à capturer l'erreur 404 avec un masque spécial $$ReturnGeneralError, à extraire de l'URL la clé du document, puis à rechercher l'UNID du document par rapport à sa clé avec un agent (l'agent s'exécutant en tant que signataire, il voit tous les documents, lui), et enfin à rediriger l'utilisateur vers le document via la syntaxe UNID?opendocument. Et cela fonctionne plutôt pas mal. Cela aurait même pu être propre s'il avait été possible d'exécuter des agents au WQO dans le masque $$ReturnGeneralError, malheureusement, comme il s'agit d'un masque spécial, ce n'est pas le cas (pff) et mon implémentation passe par une redirection javascript (oui, c'est mal, mais je n'ai pas trouvé mieux).

Tout ça pour rebondir avec grâce et élégance sur le titre du billet : si vous utilisez l'ouverture de document par clé, faites attention aux restrictions en lecture.