sitio - identificador de la aplicación no válido facebook
Cómo pasar el ID de Facebook del cliente al servidor de forma segura (4)
No sé si se trata de un lenguaje específico, pero el uso de la autenticación del lado del servidor y del lado del cliente no daña.
Puede trabajar en la opción 2 pero sí, eso también será vulnerable a la suplantación.
Al hacer la opción 3, tendrá un token de acceso único para esa sesión de usuario, por lo que sería la mejor opción, ya que siempre tiene la posibilidad de suplantar cuando pasa información del usuario desde el lado del cliente.
Tengo una aplicación de Facebook para lienzos. Estoy usando JS SDK para autenticar al usuario en el navegador y solicitar información a través de FB.api (por ejemplo, nombre, amigos, etc.).
También deseo conservar información adicional del usuario (no retenida en Facebook) en la base de datos de mi servidor haciendo una llamada ajax:
{ userFavouriteColour: "Red" }
Para guardar esto en el servidor y asociarlo con el usuario correcto, necesito saber el uid de Facebook y esto presenta un problema. ¿Cómo paso el uid desde el cliente al servidor?
Opción 1: agregar uid a la solicitud ajax :
{ uid: "1234567890",
userFavouriteColour: "Red" }
Esto obviamente no es bueno. Sería trivial para cualquier persona hacer una solicitud de AJAX a mi servicio web usando el ID de Facebook de otra persona y cambiar su color favorito.
Opción 2: en el servidor, extraiga el uid de una cookie : ¿esto es posible? He leído que Facebook establece una cookie que contiene el token uid y de acceso, pero ¿tengo acceso a esta cookie en mi dominio? Más importante aún, ¿puedo extraer de forma segura el uid de la cookie o está abierto a la suplantación al igual que la opción 1?
Opción 3: autenticación del lado del servidor del usuario en el servidor : podría usar la autenticación del lado del servidor para validar la identidad del usuario en mi servidor. Pero, ¿funcionará si ya estoy usando la autenticación del lado del cliente en el navegador? ¿Terminaré con dos tokens de acceso diferentes? Me gustaría realizar solicitudes FB.api desde el navegador, así que necesito el token de acceso en el cliente (no solo en el servidor).
Este debe ser un escenario muy común, así que creo que me estoy perdiendo algo fundamental. He leído mucha de la documentación de Facebook (varios flujos de autenticación, tokens de acceso, signed_request, etc.) y muchas publicaciones en SO, pero todavía no entiendo cómo la autenticación del lado del cliente y la autenticación del lado del servidor se juegan muy bien juntas.
En resumen, quiero saber la identidad del usuario en el servidor pero aún así hacer solicitudes a la API de Facebook desde el navegador del cliente.
(Estoy usando ASP.NET y Facebook C # SDK en el servidor)
EDITAR : Bounty añadido. Esperaba obtener una recomendación oficial más deifnitiva sobre cómo manejar esta situación, o incluso un ejemplo. Como ya he dicho, ya he leído muchos de los documentos oficiales de FB sobre los flujos de autenticación, pero todavía no encuentro nada definitivo sobre cómo la autenticación del lado del cliente y la del lado del servidor funcionan juntas.
Hace exactamente exactamente la misma pregunta. Es la opción 2. Verifique esta publicación en el blog de Facebook.
Para ser sincero, no soy lo suficientemente hacker como para saber si puedes falsificar el UID en la cookie, pero esta parece ser la forma "oficial" de hacerlo.
EDITAR: a la otra pregunta en la opción 2, sí, creo que tiene que acceder a esta cookie en su dominio.
Opción 1: La manera más fácil que puedo pensar es incluir el accessToken en JS y pasarlo con la llamada ajax.
Opción 2: Usar lo mismo que la opción 1, pero en lugar de enviar simplemente el accessToken, envíe la solicitud signed.
Del lado del servidor puedes decodificarlo usando el método ( TryParseSignedRequest ) que te dará el TryParseSignedRequest :-)
Nota: signedRequest está encriptado con la aplicación Secret. usted es el único que debería saberlo, por lo que está a salvo en ese extremo.
Renuncia:
No tengo experiencia en codificación en C #, pero una pequeña búsqueda en google me dio esto:
Es muy simple en realidad.
Cuando el usuario carga su aplicación, use la autenticación del lado del servidor , obtenga el token de acceso y cargue los datos del usuario emitiendo una solicitud de API del servidor.
En el lado del servidor, tendrás todo lo que necesitas y es un espacio aislado.
Cuando la página se renderiza para el usuario, al usar js sdk obtener los datos de autenticación del usuario, debe poder usar FB.getLoginStatus ya que el usuario ya pasó por la autenticación del lado del servidor.
Ahora en el lado del cliente también tiene un token de acceso que puede usar para obtener los datos del usuario de la API del gráfico.
Los dos tokens serán diferentes, y también tendrán una fecha de caducidad diferente, pero eso no debería ser un problema, ambos tokens deberían funcionar correctamente, como es de esperar.
Como ambos lados tienen su propio token y una forma de realizar solicitudes a la API, no es necesario enviar ningún dato de fb entre ellos.
Entonces, la tercera opción que mencionas, para mí, suena mejor, y es muy sencillo implementar eso también.
Editar
Todos los SDK de Facebook son solo envoltorios para solicitud de HTTP, ya que toda la aplicación de fb se realiza en solicitudes de http.
Los SDK solo le brindan un acceso fácil y más corto a los datos sin la necesidad de construir la URL usted mismo (con todos los diferentes parámetros posibles), realizar la solicitud y analizar la respuesta.
Para ser completamente honesto, creo que dejar de proporcionar una forma para que el C # SDK sea compatible con la autenticación del lado del servidor es una muy mala decisión.
¿De qué sirve proporcionar un SDK que no implemente toda la API?
La mejor respuesta a su pregunta, según mi experiencia, es utilizar tanto la autenticación del servidor como del lado del cliente, y como el SDK de C # no lo admite, mi consejo para usted es crear su propio SDK.
No es complicado en absoluto, ya lo implementé para python y java (dos veces), y como lo desarrollarás para tus propias necesidades, se puede adaptar a tus necesidades exactas, a diferencia de un SDK público que debería admitir todas las opciones posibles.
2nd Edit
No es necesario crear un SDK completamente nuevo, simplemente puede "ampliar" los que está usando y agregar las partes faltantes que necesita, como el soporte de autenticación del lado del servidor.