5 votes

Jersey - La redirection utilisant le Get et non le Put provoque une boucle de redirection.

Je travaille sur une application web qui utilise Jersey. J'essaie d'implémenter une sorte de get-after-post en utilisant un URIBuilder et une réponse seeOther. Le but est de rediriger vers le même URI que celui sur lequel le navigateur se trouve déjà, mais de forcer un GET. Cela fonctionne un peu comme ceci :

  1. La demande arrive par PUT
  2. Demande PUT traitée
  3. Réponse de SeeOther retournée

Ce qui devrait se passer, c'est que le navigateur capte le 303 See Other et exécute un GET sur l'URI qu'il reçoit. Malheureusement, ce qui se passe, c'est qu'il exécute un PUT sur l'URI à la place (pour autant que je puisse dire) et le PUT le renvoie à l'étape 1. ci-dessus, provoquant une boucle de redirection.

Une idée de ce qui ne va pas ici ?

   private Response giveSeeOther(){
  /*Get the base URI builder*/
  final UriBuilder uriBuilder = m_uriInfo.getBaseUriBuilder();

  /* Some stuff to create the URI */
  final Map<String, Object> parameterMap = new HashMap<String, Object>();
  parameterMap.put("uid", getUid());

  final URI redirectUri = uriBuilder.path(SomeObject.class).
                                     path(SomeObject.class, "get").
                                     buildFromMap(parameterMap);

  /* See Other (303) */
  return Response.seeOther(redirectUri).build();}

C'est le code pour la méthode see other. Je ne sais pas quel autre code vous voudriez voir, mais faites-le moi savoir.

8voto

Vous devez utiliser un code de réponse HTTP 301 à la place.

En utilisant 303, votre requête POST est maintenue, et redirigée en conséquence. En utilisant 301, votre demande est "déplacée définitivement" via GET.

Pour les autres lecteurs qui se demanderaient pourquoi quelqu'un veut faire cela, c'est pour empêcher l'utilisateur de soumettre ses données POST plus d'une fois en utilisant la fonction "Reload" de son navigateur web (ce que font souvent les utilisateurs ayant des problèmes de "communications pourries") pour recharger la page de "remerciement" qui n'a peut-être pas été chargée complètement.

Conseil : Lorsque vous effectuez une redirection de cette manière, si vous n'utilisez pas de cookies pour vous assurer que les informations parviennent à votre page de remerciement, vous devez ajouter un ou plusieurs paramètres à votre demande, de la même manière qu'un formulaire GET normal. Par exemple, si le numéro d'identification de la commande est 82838, vous pouvez le transmettre à votre page de remerciement de la manière suivante :

http://www.example.com/order/thank-you.pl?orderid=82838

Cela pose des problèmes de sécurité potentiels évidents, qui peuvent être facilement résolus si le code de votre page de remerciement vérifie que l'ID de la commande appartient bien à l'utilisateur connecté avant d'afficher l'état de la commande (je suppose que vous souhaitez inclure des informations sur l'état de la commande sur cette page de remerciement - dans ce cas, il est également intéressant d'inclure un bouton "Rafraîchir" {ou un lien} pour que l'utilisateur puisse vérifier l'état de la commande si celle-ci progresse à court terme en plusieurs étapes).

J'espère que cela vous sera utile.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X