1. props El componente principal pasa el valor al componente secundario El componente secundario vincula las propiedades del componente principal Declaración interna del componente secundario Uso
2 .$emit/$onEl componente secundario pasa el valor al componente principal (a través del formulario de evento) El componente secundario vincula el método del componente principal El componente secundario desencadena el componente principal
3.vuex Valor global el paso se puede usar en componentes del mismo nivel
4. EventBus se puede usar en componentes del mismo nivel
4. Los parámetros de URL se almacenarán en la URL para usar en la página siguiente cuando la ruta salta
5. $attrs/$listeners
6.$parent / $children
almacenamiento local
: La nueva API de almacenamiento local de H5 puede entenderse como la base de datos local del navegador, con un tamaño de solo 5 M. El
método CRUD correspondiente:
- setItem corresponde a agregar y modificar;
- getItem, clave es equivalente a buscar;
- removeItem, clear es equivalente a delete;
Ciclo de vida: permanentemente efectivo
Los datos almacenados por vuex son receptivos. Pero no se guardará y volverá al estado inicial después de actualizar. El método específico debería ser copiar los datos y guardarlos en localStorage cuando cambien los datos en vuex.Después de actualizar, si hay datos guardados en localStorage, sáquelos y reemplace el estado en la tienda.
sesiónAlmacenamiento
El ciclo de vida es la ventana o pestaña actual. Una vez que la ventana o pestaña se cierra de forma permanente, se borrarán todos los datos almacenados en sessionStorage. Pero la actualización no lo hará.
SessionStorage y LocalStorage son dos mecanismos de almacenamiento de datos proporcionados por el navegador. La principal diferencia entre los dos es que el ciclo de vida es diferente.
Token y cookie de sesión
Sesión
sesión Literalmente hablando, es una sesión.
Debido a que las solicitudes HTTP no tienen estado, la solución que se me ocurrió es enviar a todos una ID de sesión. Para decirlo sin rodeos, es una cadena aleatoria y todos la reciben de manera diferente. sessionid se guardará y transmitirá a través de una cookie
Simbólico
Contraseña símbolo
Al utilizar métodos de autenticación basados en tokens, no es necesario almacenar registros de inicio de sesión de usuario en el lado del servidor. El proceso aproximado es el siguiente:
1. El cliente utiliza el nombre de usuario y la contraseña para solicitar el inicio de sesión
2. El servidor recibe la solicitud para verificar el nombre de usuario y la contraseña
3. Después de pasar la verificación, el programa devuelve un token firmado al cliente.
4. El cliente almacena el token, como ponerlo en una cookie o almacenamiento local, y se usa cada vez que envía una solicitud.
5. El servidor verifica el token y devuelve los datos.
Galleta
La cookie es generada por el servidor y enviada al navegador. El navegador guarda la cookie en un archivo de texto en un directorio determinado en forma de kv. La próxima vez que se solicite el mismo sitio web, la cookie se enviará al servidor.
Dado que la cookie existe en el cliente, el navegador agrega algunas restricciones para garantizar que la cookie no se utilice de forma malintencionada y no ocupe demasiado espacio en disco, por lo que la cantidad de cookies para cada dominio es limitada.
El usuario solicita iniciar sesión -> el servidor se autentica y lo envía al navegador emitiendo una cookie que contiene el ID de sesión y, al mismo tiempo, guarda la sesión -> el navegador recibe la cookie y la guarda localmente -> la información en la cookie se envía al servidor al iniciar sesión en el mismo nombre de dominio la próxima vez
Este artículo está muy bien escrito, es muy útil para entender
autenticación basada en cookies
Una cookie es un archivo simple que se origina en un sitio y que el navegador almacena en la computadora de un cliente. Por lo general, contienen un nombre y un valor que identifican al cliente como un usuario específico con permisos específicos para el sitio.
La forma en que la cookie está vinculada al dominio de origen garantiza que solo el dominio de origen pueda acceder a la información almacenada en él. Los servidores de terceros no pueden leer ni cambiar el contenido de las cookies para este dominio en la computadora del usuario.
Los ex empleados de Netscape inventaron las cookies en 1993.
La autenticación basada en cookies tiene estado, lo que significa que la información de sesión o autenticación debe almacenarse tanto en el cliente como en el servidor. Este servidor de información generalmente se registra en la base de datos, y la interfaz se guardará en la cookie.
El flujo general de verificación es el siguiente:
El usuario ingresa las credenciales de inicio de sesión;
el servidor verifica si las credenciales son correctas, crea una sesión y luego almacena los datos de la sesión en la base de datos;
la cookie con la identificación de la sesión se coloca en el navegador del usuario;
en solicitudes posteriores, el servidor verifique la identificación de la sesión contra la base de datos, si se pasa la autenticación, continúe procesando;
una vez que el usuario cierra la sesión, tanto el servidor como el cliente destruyen la sesión al mismo tiempo.
autenticación basada en token
Con la popularidad de las aplicaciones de una sola página y el auge de la API web y la Internet de las cosas, los mecanismos de identidad basados en tokens se utilizan cada vez más.
Cuando se habla de autenticación basada en token, es común hablar de JSON Web Tokens (JWT). Aunque hay muchas formas diferentes de implementar token, JWT se ha convertido en el estándar de facto, por lo que JWT y token se combinarán más adelante.
La autenticación basada en token no tiene estado. El servidor no realiza un seguimiento de qué usuarios han iniciado sesión o qué JWT se han emitido. Cada solicitud al servidor debe llevar un token que autentique la solicitud. Esta etiqueta se puede agregar en el encabezado, enviarse en el cuerpo de la solicitud POST o enviarse como un parámetro de consulta.
El flujo de trabajo es el siguiente:
El usuario ingresa las credenciales de inicio de sesión;
el servidor verifica si las credenciales son correctas y luego devuelve un token firmado;
el cliente es responsable de almacenar el token, que puede almacenarse en el almacenamiento local o en una cookie;
la solicitud al servidor trae este token;
el servidor decodifica el JWT, si el token es válido, se procesa la solicitud;
una vez que el usuario cierra la sesión, el cliente destruye el token.
Ventajas del token sobre las cookies:
- Admite el acceso entre dominios
- sin Estado
- Falsificación de solicitudes contra sitios cruzados (CSRF)
- uso multisitio
- Compatibilidad con plataformas móviles
- actuación
- JWT
Resumen:
La sesión se almacena en el servidor, entendida como una lista de estados, tiene un símbolo de identificación único sessionId y se almacena en la cookie. Después de recibir la cookie, el servidor analiza el ID de sesión y luego busca en la lista de sesiones para encontrar la sesión correspondiente. Confiar en la cookie
Una cookie es como un token, cargado con sessionId, almacenado en el cliente y el navegador generalmente lo agrega automáticamente.
El token también es similar a un token, sin estado, la información del usuario se cifra en el token y el servidor puede saber qué usuario es después de descifrarlo después de recibir el token. El desarrollador debe agregarlo manualmente.
Por razones como las solicitudes entre dominios y la sobrecarga de recursos del servidor, Token nació.
La autenticación basada en token no tiene estado y no almacenamos información del usuario en el servidor o la sesión.
NoSession significa que su programa puede aumentar o disminuir la máquina según sea necesario sin preocuparse de si el usuario está conectado o no. Simplemente verifique el token cada vez que reciba una solicitud.
Bibliotecas disponibles:
js-cookie
Ver cookies directamente en el navegador:
document.cookie.split("; ");
