facebook - composer - URL extraña añadida "#_=_"
facebook/php-sdk-v4 (1)
Vea esto: https://developers.facebook.com/blog/post/552/
Cambio en el comportamiento de redirección de la sesión
Esta semana, comenzamos a agregar un fragmento
#_=_a redirect_uri cuando este campo se deja en blanco. Por favor, asegúrese de que su aplicación pueda manejar este comportamiento.
Posible duplicado:
¿Desea jugar con Framework añadiendo # = para redirigir después de la autenticación de Facebook a través de OAuth2?
¿Alguien más ha visto esto suceder?
Estoy construyendo una aplicación de Facebook en Facebook usando Facebook PHP SDK, y algo de Javascript.
Ahora cuando llevo al usuario a través del flujo de autenticación de OAuth, me he dado cuenta de que la URL en el navegador se agrega automáticamente con este "#_=_" , por lo que mi URL empieza a verse así:
http://apps.facebook.com/xxxxxxxxxxxx/#_=_
y cuando redirecciono a la página de perfil de la aplicación, la URL es esta:
http://www.facebook.com/apps/application.php?id=xxxxxxxxxxxx#_=_
Estoy redirigiendo usando
echo "<script type=''text/javascript''>top.location.href=''$appcanvasurl'';</script>"
a la lona URL, y
echo "<script type=''text/javascript''>top.location.href=''$appprofurl'';</script>"
para la página de perfil de la aplicación.
Entonces, ¿por qué este #_=_ se adjunta?
Actualizar:
De acuerdo con este error en el rastreador , esto es por diseño, y dar un valor para redirect_uri no cambia esto.
Y según la respuesta oficial de Facebook en esa página (tiene que haber iniciado sesión en Facebook para ver la publicación):
Esto se ha marcado como ''por diseño'' porque evita una posible vulnerabilidad de seguridad.
Algunos navegadores anexarán el fragmento de hash de una URL al final de una nueva URL a la que se redirigirán (si esa nueva URL no tiene un fragmento de hash).
Por ejemplo, si example1.com devuelve un redireccionamiento a example2.com, un navegador que vaya a example1.com # abc irá a example2.com # abc, y el fragmento de hash contenido de example1.com sería accesible para un script en example2 .com.
Dado que es posible tener un auth flow redirigir a otro, sería posible tener datos de autenticación confidenciales de una aplicación accesible para otra.
Esto se mitiga agregando un nuevo fragmento hash a la URL de redireccionamiento para evitar el comportamiento de este navegador.
Si la estética, o el comportamiento del lado del cliente, de la URL resultante son motivo de preocupación, sería posible usar window.location.hash (o incluso un redireccionamiento del lado del servidor propio) para eliminar los caracteres ofensivos.