2010-01-28 17 views
79

Necesito redirigir al usuario de una página a otra, pero necesito mantener la cadena del referer original. Así, por ejemplo, si comienzan a cabo en http://www.othersite.com/pageA.jsp, haga clic en un vínculo que les llevara a http://www.mysite.com/pageB.jsp, que luego ejecuta un redireccionamiento 302 a http://www.mysite.com/pageC.jsp, necesito la cadena árbitro para contener "http://www.othersite.com/pageA.jsp"¿Una redirección 302 mantendrá la cadena del referer?

es éste el comportamiento normal para una redirección 302? ¿O mi referer original se descarta, a favor de "http://www.mysite.com/pageB.jsp"? Eso no sería deseable.

No sé si hace alguna diferencia, pero estoy trabajando en JSP, y estoy usando response.sendRedirect() para ejecutar el redireccionamiento 302.

Debo mencionar que hice un experimento con esto, y parece haber conservado la cadena del referer original ("http://www.othersite.com/pageA.jsp"), pero solo quería asegurarme de que este era el comportamiento predeterminado normal, y no algo extraño en mi fin.

Gracias por su ayuda.

editar para agregar:

Aunque actualmente estoy usando una redirección 302, probablemente podría utilizar un redireccionamiento 301 en su lugar. ¿Sabes si el comportamiento de los redireccionamientos 301 es más confiable?

+2

solo necesito lo contrario. Haga una redirección del lado del servidor * cambiando * la referencia en la redirección (por lo tanto, elimine la referencia original). ¿Nadie? – cprcrack

Respuesta

26

La respuesta corta no está especificada en el correspondiente RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 ni para el encabezado Referer ni para el código de estado 302.

Su mejor opción es hacer una prueba con varios navegadores y ver si hay un comportamiento de consenso.

Para correas y tirantes llenos, codifique la referencia original en la URL de redirección para que pueda garantizar su recuperación.

+14

Para quienes pueda estar interesado, hice pruebas de spme en los principales navegadores: http://stackoverflow.com/questions/2158283/will-a-302-redirect-maintain-the-referer-string/5441932#5441932 –

12

Buena pregunta. En este caso, el envío del referer depende completamente del navegador (porque se le dice al navegador que haga otra solicitud al nuevo recurso).

RFC 2616 permanece en silencio sobre el tema:

El recurso solicitado reside temporalmente en una URI diferente. Como la redirección podría verse alterada ocasionalmente, el cliente DEBERÍA continuar utilizando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si está indicada por un campo de encabezado Cache-Control o Expires.

No me gustaría confiar en que el navegador envíe el referer adecuado. Apuesto a que hay al menos uno que envía algo diferente a los demás.

Solución

Si es posible, por qué no añadir un parámetro ?override_referer=<old_url> a la URL redirigir a, y analizar ese valor en lugar de HTTP_REFERER.

De esta manera, puede estar seguro de obtener siempre el resultado correcto, y no está perdiendo nada en seguridad: el referer puede ser falso de cualquier manera.

+2

En realidad, está perdiendo algo en seguridad al hacer que el referer sea invalidable en la URL. En la mayoría de los navegadores modernos, el referente de las solicitudes de AJAX no se puede cambiar a través de JavaScript; sin embargo, la URL obviamente puede. Esto significa que, en el caso de un ataque XSS, el referer es más confiable que el parámetro URL. No me malinterpreten, el referer sigue siendo claramente una aportación del usuario en la que no se puede confiar por completo. Pero es mucho más difícil falsificar esos datos para otra persona que cambiar la URL. – phylae

+0

@phylae ¡buen punto y absolutamente vale la pena mencionarlo! –

103

No sé acerca de la 302, pero he probado el 301 en algunos navegadores hoy, aquí los resultados:

ESCENARIO: el usuario hace clic en el vínculo Dominio X que apunta a dominioA. domainA hace una redirección 301 a domainB.

  • IE8 referer al aterrizar en dominioB es: Dominio X (incluso cuando se utiliza la exploración InPrivate e incluso cuando el usuario abre enlace en una nueva pestaña)
  • Safari4 referer al aterrizar en dominioB es: Dominio X (incluso cuando el usuario abre eslabón de nueva pestaña)
  • FF3.6.10 referer al aterrizar en dominioB es: Dominio X (incluso cuando el usuario abre enlace en una nueva pestaña)
  • Chrome5 referer al aterrizar en dominioB es: Dominio X (menos usuario abre enlaces en una nueva pestaña)
  • Chrome26 referer al aterrizar en dominioB es: Dominio X (incluso cuando el usuario abre enlaces en una nueva pestaña)
+24

Nota: esta prueba se ha realizado hace un tiempo, y hoy en día Chrome 26 se comporta de la misma manera ** incluso cuando se abre en una nueva pestaña **. – Benjamin

+0

No probado en todos los navegadores, pero el comportamiento de 302 parece ser idéntico. –

5

que tenía el problema opuesto: quería que la árbitro era "páginaB" pero ninguno de PROCEDE navegador curent esta manera ...

así que traté con una redirección HTML en páginaB (en lugar de 301 o 302 redirección):

<meta http-equiv="refresh" content="0; url=pageC.jsp" /> 

y el resultado fue sorprendente:

  • Referer is pageB with Chrome
  • Referer está VACÍO con FireFox & IE!

Esperamos que esto pueda ayudar a

Cuestiones relacionadas