usuarios tipo saber que permisos movil mobile_detect ejemplos dispositivo detectar como celular php android ios session phpfox

saber - php detectar tipo de dispositivo



¿Cómo administrar la sesión para un usuario conectado desde la aplicación móvil en PHP? (7)

A diferencia de los navegadores web, iOS y las aplicaciones de Android no pueden mantener sesiones. Por lo general, una vez que un usuario inicia sesión (las credenciales de inicio de sesión se verifican desde el servidor), sus credenciales de inicio de sesión se guardan en el lado del cliente. Luego, la aplicación obtiene datos del servidor utilizando menos llamadas REST api. Así es como se hace principalmente en aplicaciones móviles.

Sin embargo, si desea que la sesión del servidor y la aplicación móvil vayan de la mano (lo que no creo que sea una buena idea), el camino es

1) Cuando el usuario inicia sesión, se genera un token de seguridad en el servidor y se guarda tanto en el servidor como en el lado del cliente.

2) La aplicación móvil podrá comunicarse con el servidor siempre que el token de seguridad sea válido.

3) Cuando la sesión expira, el token de seguridad deja de ser válido. Ahora debe haber un entendimiento entre el servidor y el cliente sobre la respuesta cuando la sesión ha expirado. Ahora la aplicación móvil debe redirigir al usuario a la página de inicio de sesión nuevamente. El usuario volverá a iniciar sesión y luego se comunicará con el servidor. Esto debería suceder cada vez que la sesión expira.

Soy un programador PHP de profesión. Por lo tanto, no tengo ninguna idea sobre la codificación de iOS y Android.

El escenario es que hay un sitio web desarrollado utilizando un software PHP de redes sociales titulado "PHPFox" .

Ahora hay dos aplicaciones móviles similares que replican exactamente la funcionalidad de este sitio web. Una aplicación móvil está en iOS y otra está en Android.

Entonces, escribí un conjunto de API RESTful donde acepto la solicitud desde la aplicación móvil, analizo la solicitud, paso los parámetros de solicitud a la función que hace el mismo trabajo para el sitio web, obtengo la respuesta de esta función, la convierto en formato JSON y lo envió de vuelta a la aplicación móvil. Para aplicaciones iOS y Android estoy usando el mismo conjunto de archivos REST API.

Cuando el usuario inicia sesión, se llama a la API REST para iniciar sesión. Finalmente, se llama a la función PHPFox para la autenticación, se genera un token de seguridad junto con algunos otros datos del usuario. Con cada inicio de sesión, PHPFox genera el token de seguridad diferente. Esta información está configurada en la sesión. Ahora cada vez que llamo a cualquiera de las funciones a través de cualquier archivo REST API, el token de seguridad generado en el momento del inicio de sesión se verifica y solo después de la verificación exitosa de token se llama a la función PHPFox. Este proceso de verificación se realiza internamente por PHPFox. Por lo tanto, no es necesario pasar el token de seguridad explícita o implícitamente a ninguna llamada REST API.

Hasta ahora todo funciona absolutamente bien.

Mi duda comienza desde aquí. No sé si la sesión se mantiene en la aplicación iOS / Android. Entonces, si la sesión en el servidor, es decir PHPFox, se agota el tiempo de espera, ¿qué pasará con la aplicación? ¿Se bloqueará? ¿El usuario tendrá que iniciar sesión de nuevo? Si el usuario mata la aplicación en el dispositivo y vuelve a la aplicación, ¿tiene que volver a iniciar sesión?

Hay demasiadas dudas en mi mente. Me confundo por completo con estas cosas.

¿Alguien puede por favor enfocarse más en el problema que estoy enfrentando? Sería genial si pudieras explicar en detalle.

Gracias.


No tengo ninguna experiencia trabajando con PHPFox, pero así es como una interfaz móvil debería manejar los problemas idealmente:

Caso 1: aplicación móvil hablando activamente con el servidor:

  • El sello de tiempo de espera de la sesión sigue subiendo y la sesión se mantiene activa.

Caso 2: Aplicación móvil activa sin ninguna comunicación con el servidor (por ejemplo, llamada entrante, moviéndose entre aplicaciones, etc.):

  • La sesión del servidor puede o no agotar el tiempo de espera.
  • Si se agota el tiempo, la próxima consulta al servidor fallará auth y devolverá un error.
  • La aplicación consume este error y redirige con gracia a la pantalla de inicio de sesión con una pancarta de mensaje que insta al usuario a iniciar sesión. (Esto sucede en mi aplicación de banca)

Caso 3: el usuario mata la aplicación en el dispositivo y la relanza:

  • La aplicación debe almacenar el token en sqlite o preferencias compartidas. (Las aplicaciones que inician sesión siempre tienen este enfoque)
  • Al reiniciar, la aplicación puede consultar el servidor con el token presistente.
  • Si la sesión está activa, la comunicación se realiza y el usuario puede continuar. Si no, el usuario va a la pantalla de inicio de sesión como en el Caso 2.

REST no tiene sesiones por su naturaleza. Debe generar un token cuando el usuario inicie sesión. Debe guardar este token en su cliente móvil. Para cada solicitud, debe adjuntar un token válido en el encabezado de solicitud y verificarlo en el servidor. Si el token caduca, el token almacenado en un cliente no es válido. Por lo tanto, debe iniciar sesión nuevamente debido a la respuesta 401. Si token no es correcto, necesita responder 400. Espero ser útil para usted.


Si está utilizando Oauth 2 para la autenticación, aquí está la configuración común:

  • El usuario inicia sesión en la aplicación móvil
  • Si las credenciales son correctas, el servidor devuelve el token de acceso, un token de actualización y la vida útil del token
  • La aplicación móvil almacena esos valores + marca de tiempo actual
  • Del lado del servidor, un recolector de basura está configurado para borrar los tokens caducados
  • Antes de realizar cualquier llamada de API, la aplicación móvil comprueba si el token está a punto de caducar (con la ayuda de los valores almacenados). Si el token está a punto de caducar, la aplicación envía el token de actualización que indica al servidor que genere un nuevo token de acceso
  • Si desea que los usuarios permanezcan conectados, la aplicación se puede configurar para verificar el token de acceso periódicamente y solicitar uno nuevo si está desactualizado.

Espero que esto ayude.

Aclamaciones


Su servidor debe ser completamente apátrida, por lo que no se debe almacenar ninguna sesión ... una API REST es solo una capa de abstracción de datos con seguridad opcional (a través de token)

Por lo tanto, la API expone un servicio de autenticación, que responderá con un token de autorización que se utilizará en las siguientes solicitudes como encabezado, este token debe ser una relación de 1 a 1 con cada usuario y universalmente único. También debe tener un tiempo de caducidad, en ese momento su servidor responde con una respuesta de error apropiada solicitando a su aplicación que actualice el token, lo que puede hacerse a través de un sistema de token de actualización separado o solicitando que el usuario inicie sesión nuevamente para actualizar el token .

Es la aplicación que debe mantener el estado, no el servidor. El servidor solo está ahí para fines de datos, por lo que no debe confiar en ningún tipo de autenticación basada en sesión.


Una sesión es "algo" que vive en el servidor. Puede ser un objeto que almacena detalles sobre el usuario (por ejemplo, identificación de sesión, nombre de usuario, dirección de correo electrónico ...) o cualquier otra información que se requiera para procesar solicitudes futuras (como detalles del carrito de compras, dirección de entrega ...).

Ese "algo" es típicamente un objeto, que puede almacenarse en la memoria, en una base de datos o incluso serializarse y guardarse en el sistema de archivos (creo que este es el valor predeterminado en PHP).

Entonces, cuando dices "No sé si la sesión se mantiene en la aplicación iOS / Android", me temo que eso no tiene sentido. Solo el servidor puede mantener sesiones.

Normalmente, lo único que el cliente sabría (navegador web o aplicación móvil) es la identificación de la sesión (en forma de token o GUID). Es lo único que el cliente / aplicación necesita recordar y debe enviarse junto con cualquier solicitud al servidor.

Se podría almacenar como una cookie y / o enviarse al servidor como un encabezado de solicitud.

Luego, el servidor leerá la identificación / token de sesión de las cookies o el encabezado y recuperará los detalles de la sesión desde el lugar donde almacena las sesiones (sistema de archivos, memoria o base de datos). Eso es lo que sucede detrás de la escena cuando llamas a session_start() .

Para obtener más información sobre el manejo de sesión y cómo crear el manejador de sesión personalizado (que puede ser necesario en su caso para obtener un token de los encabezados de solicitud):
http://php.net/manual/en/function.session-start.php


No debe preocuparse por la sesión desde el lado del desarrollo móvil. No sé mucho sobre iOS, pero en Android usamos SharedPrefrence (Flag que mantiene la sesión localmente).