J’ai un besoin fonctionnel que je ne sais pas résoudre. Voilà l’idée :
lorsqu’une prestation est finie, l’action faite dans l’outil par l’opérateur génère un mail au porteur de projet.
le porteur de projet n’a pas de compte simplicité. on veut que via le mail, il puisse ouvrir la prestation en mode non connecté et donner son accord ou pas avec un commentaire.
un peu comme quand on reçoit un questionnaire de satisfaction sur une réservation d’hotel.
La solution est sans doute un objet externe rendu accessible en zone publique (utilisant soit le user “public” soit un user webservices technique habilité au groupe “PUBLIC”). Un exemple c’est le site web de la démo.
L’idéal dans un cas comme celui là où il s’agit de mettre à jour des données “ciblées” c’est de générer coté métier un code aléatoire (genre de 50 digits) à usage unique passé dans l’URL de l’object externe public. La vérification du droit d’accès pour mise à jour se faisant en vérifiant et en “brulant” ce code
Ici en particulier l’usage de la bonne API (ici la getPublicExternalObjectURL) plutôt qu’une URL en dur aurait évité le pb car il n’y aurait pas eu le /ui qui n’a rien à faire dans une URL en zone publique (et qui provoque la demande de connexion, qui aurait de toute façon aboutie en 404 après connexion)
Par contre je suggère de faire un tour sur l’ensemble de votre code et paramétrage pour remplacer toutes les occurrences d’URLs utilisant les anciennes JSP par des appels des APIs HTMLTool.get(...)URL qui vont bien.
En effet les JSPs disparaîtront définitivement d’ici peu (et les utiliser encore aujourd’hui n’est de toute façon pas idéal car cela fait de toute façon un forward sur les nouvelles URLs).
Les APIs HTMLTool.get(...)URL - qui existent pour la plupart au moins depuis la 3.1 - garantissent la compatibilité ascendante, les URLs en dur non.