auth.statusChange no se activa durante FB.init si el usuario no ha iniciado sesión en Facebook

Question

Me pregunto si alguien ha encontrado una solución al comportamiento que estoy experimentando.

Tomemos el ejemplo del código de abajo:

<script> 
window.fbAsyncInit = function() { 
     FB.init({ 
      appId  : '[----removed-------]', // App ID 
      channelUrl : 'http://localhost/channel.html', // Channel File 
      status  : true, // check login status 
      cookie  : true, // enable cookies 
      xfbml  : true // parse XFBML 
     });  
     // Additional initialization code here 

     FB.Event.subscribe('auth.statusChange',fbLoginStatus); 

     console.log("getloginstatus"); 

     FB.getLoginStatus(fbLoginStatus); 
</script> 

Usando FB.init con el estado se establece en true, las llamadas esencialmente getLoginStatus() según la facebook documentation. Sin embargo, es apparently intended behaviour que esto no activa el evento auth.statusChange, porque el valor predeterminado es 'desconocido', y el valor para 'no conectado' también es 'desconocido' (aunque puede conocerse !!)

por lo tanto he tenido que hacer una llamada a FB.getLoginStatus() explícitamente , así como tengan la condición establecida en true si quiero responder también a los usuarios que no estén conectados a Facebook.

El problema es que esto provoca que la función se llame dos veces si el usuario no está "desconectado".

¿Hay alguna manera de evitar que esto suceda? Creo que mi única opción podría ser la de llamar a una función diferente para manejar los eventos de cambio de autenticación ..

Answer 1

Mi mejor solución para esto era para establecer el estado de 'falso' en las opciones de fb.init, a continuación, llamar explícitamente getloginstatus por separado.

SI get LoginStatus regresó como desconocido (es decir, desconectado), me suscribí al evento de cambio de estado, así como hacer el habitual de mostrar el botón de inicio de sesión. Luego, cuando el usuario inicia sesión, el estado cambia según lo esperado.

Answer 2

Puede comprobar la respuesta a volver después de pasar un cierto parámetro en el getLoginStatus:

window.fbAsyncInit = function() { 
    FB.init({ 
     appId : '', 
     status : true, 
     cookie : true, 
     xfbml : true, 
    }); 

    FB.getLoginStatus(function(response) { 
     //console.log(response); 
     if (response.status === 'connected') { 
      var accessToken = response.authResponse.accessToken; 
      alert(accessToken); 
     } else if (response.status === 'not_authorized') { 
      //login function 
     } else { 
      //login function 
     } 
    }, true); 

    FB.Event.subscribe('auth.authResponseChange', function(response) { 
     //console.log('The status of the session changed to: '+response.status); 
     window.location.reload(); 
    }); 
}; 

Si configura el status en true, el objeto de respuesta FB.getLoginStatus será almacenado en caché por el SDK y las llamadas subsiguientes a FB.getLoginStatus devolverán los datos de esta respuesta en caché.

Para solucionar esto, debe llamar al FB.getLoginStatus con el segundo parámetro establecido en true para forzar un viaje de ida y vuelta a Facebook, actualizando efectivamente el caché del objeto de respuesta.

FB Docs: https://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus/

Answer 3

Una mejor solución que teóricamente debería guardar un ida y vuelta es el siguiente (CoffeeScript, pero fácilmente traducible a javascript):

FB.init 
    appId: appId 
    channelUrl: channelUrl 
    status: true  # Check Facebook Login status on init 
    cookies: true 
    xfbml: false 

FB.getLoginStatus (response) => 
    @parseResponse(response) 
    FB.Event.subscribe 'auth.statusChange', @parseResponse 
    FB.Event.subscribe 'auth.authResponseChange', @parseResponse 

Todavía estamos utilizando un getLoginStatus manual para disparar cuando el usuario es desconocido, pero esta vez todavía usamos 'status: true' para que el estado de inicio de sesión ya esté almacenado en caché cuando se llama a getLoginStatus. Al suscribirse a los eventos relevantes solo después de que getLoginStatus se haya disparado, nos aseguramos de que el método de manejo parseResponse solo se invoque una vez durante la carga.