La primavera pasada, los usuarios comenzaron a cerrar sesión en Toolz.dev. A veces no, constantemente. Inicie sesión, haga clic en una herramienta, boom: regrese a la pantalla de inicio de sesión. El backend emite tokens de acceso de 15 minutos y tokens de actualización de 7 días, y I'd probó ese flujo cien veces. Así que, naturalmente, supuse que el punto final de actualización estaba roto y pasé una hora y cuarenta minutos leyendo middleware Express que no tenía nada de malo.
Entonces finalmente hice lo obvio. Saqué un token de acceso en vivo del encabezado de autorización, lo pegué en un decodificador y miré las reclamaciones. los exp estaba bien los iat estuvo bien. El token fue válido durante otros 14 minutos. Lo que significaba que el servidor estaba bien y el error tenía que estar en el cliente. Efectivamente: mi interfaz estaba comprobando payload.exp < Date.now(). exp Segundos desde hace una época. Date.now() son milisegundos. Cada token recién acuñado parecía haber caducado alrededor de 1970, por lo que el cliente "ayudablemente" desconectó a todos antes de que el servidor tuviera voz y voto. Tres caracteres de corrección - /1000- después de casi dos horas de caza.
Eso' es todo el discurso para tener un decodificador JWT en su caja de herramientas. Un JWT parece ruido de línea: tres trozos de galimatías de base64url pegados con puntos, pero es solo JSON con una gabardina. En el momento en que puedes leer las afirmaciones, la mitad de tus errores de autenticación dejan de ser misterios. Audiencia equivocada, token caducado, rol faltante, sesgo de reloj, milisegundos contra segundos - ellos' Todos están sentados ahí en texto plano una vez que decodificas.
Pero, y esto importa, donde decodificar no es una opción neutral. Un token de acceso real es una credencial en vivo. Péguelo en un sitio decodificador que envía tokens a un servidor, y usted & #39; acaba de depositar una clave de trabajo para su API en un registro de solicitud de extraño & # 39; Esa & # 39; es la razón específica por la que construí el Decodificador JWT Toolz.dev para ejecutarse completamente en su navegador. Más sobre eso a continuación.
TL;Dr: Para decodificar un JWT en línea, péguelo en el Decodificador JWT Toolz.dev- divide el encabezado, la carga útil y la firma al instante, traduce
exp/iaten fechas humanas y se ejecuta 100% del lado del cliente, por lo que el token nunca sale de su máquina. Una cosa que se puede grabar en la memoria: la decodificación NO es una verificación. Un JWT es simplemente JSON codificado en base64url que cualquiera puede leer; solo la verificación de firma con la clave lo demuestra y la confiabilidad #39.
Características clave
Encabezado instantáneo, carga útil y división de firma
Pegue un token y el decodificador lo dividirá inmediatamente en tres partes: el encabezado (algoritmo y tipo de token), la carga útil (sus reclamos) y la firma (codificada a la izquierda, porque es una MAC o firma sin formato, allí ' no hay nada legible por humanos allí). Sin botón de envío, sin recarga de página. Esto refleja exactamente lo que hace su biblioteca de autenticación internamente antes de la verificación: dividirse ., base64url-decodifica los dos primeros segmentos, analiza como JSON. Ver las piezas dispuestas una al lado de la otra es la forma más rápida de crear intuición para el formato. Después de unas pocas docenas de tokens, usted ' Comenzaré a reconocer un token RS256 Auth0 frente a un token HS256 Laravel de un vistazo; el encabezado lo delata cada vez.
Marcas de tiempo EXP, IAT y NBF legibles por humanos
La característica más útil, punto final. exp, iaty nbf son valores de NumericDate (segundos desde la época de Unix) y nadie, incluido yo mismo, puede leer 1783430700 Y te diré si es el próximo martes o la muerte por calor del universo. El decodificador convierte cada marca de tiempo en una fecha y hora reales, en su zona horaria local y UTC. Aquí es donde el error clásico de milisegundos frente a segundos se vuelve visible al instante: si está decodificado exp Renders como una fecha en el año 56,000 y tantos, alguien rellenó un JavaScript Date.now() en un campo que espera segundos. He enviado ese error. Ver la fecha absurda es el diagnóstico. Para una arqueología de marca de tiempo más profunda, la Convertidor de marca de tiempo está a una pestaña de distancia.
Cuenta regresiva y estado de caducidad
Más allá de solo renderizar la fecha, el decodificador le indica el estado actual del token: válido, caducado o aún no activo (cuando nbf está en el futuro). Si el token' sigue vivo, obtendrá una cuenta regresiva para que expire. Esto suena como una pequeña conveniencia hasta que usted're depuración de un 401 intermitente y necesita responder "¿estaba este token específico muerto cuando se activó la solicitud?" una y otra vez. Comparar la cuenta regresiva con su servidor ' TTL configurado también detecta una configuración incorrecta rápidamente: si se supone que sus tokens de acceso duran 15 minutos y la cuenta regresiva dice 6 días, su código de emisión lee el valor de configuración incorrecto.
Inspección de algoritmos e cabeceras
El encabezado decodificado le muestra alg y typ (más kid y amigos cuando están presentes), que responde a las preguntas que importan de seguridad, no solo depuración. ¿Este token es HS256 o RS256? ¿El kid ¿Coincide con una clave que realmente sirve su punto final de JWKS? Y el grande: es alg algo que nunca debería ser, como none¿? Fichas que reclaman "alg": "none" ¿hay dispositivos de prueba o alguien que esté sondeando su verificador? De cualquier manera, desea verlo de inmediato. Primero reviso el encabezado en cada token desconocido, antes de leer un solo reclamo.
Reclamos JSON con formato de sintaxis
Las cargas decodificadas sin procesar son blobs JSON de una sola línea, y a los proveedores de identidades les encanta empacarlos: objetos anidados, afirmaciones personalizadas con espacio de nombres, matrices de ámbitos. El decodificador bonito imprime todo con resaltado de sintaxis para roles, scope, aud Las matrices y los objetos de permisos anidados son realmente escaneados. Es el mismo trato que el Formateador JSON proporciona JSON arbitrario, aplicado automáticamente a sus reclamos. Cuando usted 'Estamos comparando dos tokens, digamos, uno de un usuario que puede acceder a un punto final y otro de un usuario que puede 't - la salida formateada convierte un ejercicio de entrecerrar los ojos en una diferencia de diez segundos.
100% del lado del cliente: su token nunca sale del navegador
Esta es la característica por la que luchamos. Un token de acceso pegado no son datos de muestra - it's una credencial en vivo que se autentica como un usuario real hasta exp. Cualquier decodificador que publique su token en un backend acaba de escribir una clave de trabajo en registros del servidor, análisis, tal vez un rastreador de errores de terceros. El decodificador Toolz.dev realiza toda la decodificación en JavaScript, en su pestaña. Nada se transmite, nada se almacena. No confíes en mi palabra: abre DevTools, mira la pestaña de la red, pega una ficha. cero solicitudes. Escribí por qué esta arquitectura es importante para cada herramienta de entrada sensible en Mi artículo sobre la privacidad de datos en las herramientas en línea.
Funciona con cualquier JWT, desde cualquier pila
Los JWT son un estándar - RFC 7519- entonces el decodificador no lo hace ' No me importa quién acuñó el tuyo. Tokens Auth0 y Firebase con sus reclamos personalizados con espacios de nombres, configuraciones adyacentes a Laravel Sanctum, Keycloak, Supabase, AWS Cognito o los tokens HS256 enrollados a mano, mis propios letreros backend Express para Toolz.dev - si es 's tres segmentos base64url unidos por puntos, decodifica. Eso incluye casi JWT con formato incorrecto: si el segmento dos ganó & #39; t analizar como JSON, el decodificador le indica qué parte está rota en lugar de fallar silenciosamente, lo cual es en sí mismo diagnóstico. Los tokens truncados en copia son más comunes que tú & #39;d piensa.
Cómo usar el decodificador JWT
Paso 1: Coge la ficha
Encuentra el token donde quiera que tu aplicación lo guarde. Más comúnmente: DevTools → Pestaña Red → Haga clic en una solicitud → Copie el Authorization: Bearer eyJ... valor del encabezado (sin la palabra "Bearer"). O verifique la aplicación → Almacenamiento local / Cookies, ya que hay muchas aplicaciones que almacenan tokens allí. En el backend, regístrelo o extráigalo de su conjunto de pruebas. Copie toda la cadena: un JWT que pierde sus últimos caracteres aún decodifica pero nunca lo verificará, y eso ' es una hora confusa que no necesita ' No necesito.
Paso 2: Pégalo
Abre el Decodificador JWT y pegar. La decodificación ocurre mientras escribes, sin botón. Si usted 'Está nervioso por pegar un token de producción en cualquier lugar (buen instinto), abra primero la pestaña Red y confirme que no se transmite nada. Es 't. Esa verificación de paranoia tarda diez segundos y es exactamente lo que yo 'd hago con otra persona 's herramienta.
Paso 3: Lee las tres partes
Encabezado primero: Confirmar alg es lo que su sistema espera y typ es JWT. Luego la carga útil: iss (quien lo acuñó), aud (para quién es para), sub (qué usuario), además de los roles, alcances o reclamos personalizados que agregue su pila. La firma permanece codificada - it's salida criptográfica, no datos. Si el encabezado dice none, detente y ve a verificar la lista de permisos de tu verificador antes que nada.
Paso 4: Verifique la experiencia y las afirmaciones que pican
mira el decodificado exp Fecha y el estado de caducidad. ¿Caducado? Ahí está tu 401. ¿Válido pero rechazado de todos modos? Ahora compara aud y iss en comparación con su verificador & #39;s config - los desajustes son la segunda causa más común después del vencimiento. Y si alguna marca de tiempo se representa como un año de cinco dígitos, felicidades: usted & #39; He encontrado un error de milisegundos contra segundos y por la presente le doy la bienvenida a un club muy grande.
¿Qué hay realmente dentro de un JWT? Anatomía de las tres partes
Un token web JSON, definido en RFC 7519, es tres segmentos codificados en base64URL unidos por períodos: header.payload.signature. (Estrictamente, la variedad firmada es un JWS según RFC 7515 - allí ' es un primo cifrado, JWE, pero casi todos los tokens que usted ' se encontrarán en la naturaleza son un JWS firmado)
La palabra clave es codificado. Base64url es una codificación de transporte, una forma reversible de hacer que los bytes sean seguros para URL, no cifrado. Cualquiera que tenga un JWT puede leer todo en el encabezado y la carga útil con cero claves, cero secretos y cero esfuerzo. Juega con la codificación sin formato en el Convertidor Base64 Y verás que es el alfabeto estándar con + y / cambiado por - y _, relleno caído. Escribí más sobre la codificación en sí en el Guía de codificación Base64.
Decodifique un encabezado típico y obtiene:
{ "alg": "HS256", "typ": "JWT" }
Y una carga útil construida a partir de las reclamaciones registradas RFC 7519 define:
{
"iss": "https://toolz.dev",
"sub": "user_8f3a2c",
"aud": "toolz-api",
"exp": 1783431600,
"nbf": 1783430700,
"iat": 1783430700,
"jti": "b4d1f0e2"
}
iss es el emisor, sub el asunto (generalmente su ID de usuario), aud el público al que se dirige, jti una identificación de token única. exp, nbfy iat son valores numéricos de fecha: artículos de segunda clase Desde la época de Unix. No milisegundos. JavaScript Date.now() Devuelve milisegundos y confundiendo los dos produce tokens que caducan instantáneamente (mi error de cierre de sesión de Toolz.dev) o tokens con exp fechas del año 56.000 que efectivamente nunca caducan, lo que es silenciosamente el fracaso más peligroso.
HS256 vs RS256. HS256 firma con un HMAC sobre un secreto compartido: rápido, simple, pero cada servicio que verifica tokens también contiene el secreto, y cualquiera que lo tenga puede hacerlo sin usar fichas Está bien para un monolito como mi backend, donde emisor y verificador son el mismo proceso. RS256 firma con una clave privada y verifica con una pública, por lo que puede publicar la clave pública (a través de JWKS) y dejar que una docena de microservicios verifique sin que ninguno de ellos pueda falsificar. Los sistemas distribuidos y los desplazados internos de terceros deben estar en RS256 o sus hermanos ECDSA/EDDSA.
los alg: none atacar RFC 7519 permite JWT no asegurados donde alg es none Y la firma está vacía. Las primeras bibliotecas confiaban en el encabezado alg ciegamente, así que los atacantes despojaron la firma, set alg para none, y navegó a través de la verificación con afirmaciones totalmente controladas por atacantes. Un truco relacionado swaps RS256 por HS256 para que el verificador utilice el público clave como secreto HMAC. Es por eso que RFC 8725 - Mejores prácticas actuales del token web JSON - es contundente: el verificador debe fijar sus algoritmos permitidos en el código y nunca dejar que el token elija. Si su llamada a la biblioteca no incluye 't incluir un explícito algorithms Lista, arregla eso hoy.
Decodificar versus verificar: la línea que importa. La decodificación es leer; verificar es confiar. La diferencia en el código:
// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
Buffer.from(token.split('.')[1], 'base64url').toString()
);
// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });
Un decodificador en línea hace lo primero. Puede mostrarle las afirmaciones; no puede (ni debe pretender) decirle que el token es auténtico. Sólo verify, con la llave, hace eso. Nunca tome decisiones de autorización de reclamos decodificados pero no verificados.
Lo que lleva a la última regla: Nunca pongas secretos en una carga útil de JWT. Sin contraseñas, sin claves API, sin datos, usted & #39;d le importa que un atacante lea. La carga útil es pública por construcción, firmada contra manipulación, abierta a lectura. Si es & #39;s en el token, asuma que Internet completo puede verlo.
Casos de uso comunes
Depuración de 401 durante el desarrollo de API
El 401 es el código de estado menos informativo en HTTP. El servidor dijo que no, pero ¿el token estaba caducado? ¿Audiencia equivocada? ¿Firmado con una clave obsoleta? Falta por completo porque su interceptor no disparó 't? Decodificar el token real de la solicitud fallida colapsa el espacio de búsqueda en segundos. La mitad del tiempo exp lo responde solo. la otra mitad, comparando iss y aud En contra de la configuración del entorno de su verificador, se reproduce un token de desarrollo contra la puesta en escena o viceversa. Mantengo el decodificador anclado junto a mi cliente HTTP para exactamente este bucle; es una entrada central en mi Kit de herramientas de depuración de API. Decodificar primero, leer el middleware en segundo lugar: el orden inverso me costó una hora y cuarenta minutos una vez, y tengo la intención de seguir cobrando interés en esa lección.
Explicación de los cierres de sesión sorpresa
Cuando los usuarios informan "sigue hablándome de la sesión", las marcas de tiempo de los tokens son su declaración de testigo. Decodificar un nuevo token de acceso y comprobar la brecha entre iat y exp- ¿son realmente los 15 minutos que configuraste o un env var lo anuló a 60 segundos? Luego verifique si el token de actualización 's ventana de 7 días es lo que cree que es. El sesgo del reloj también aparece aquí: si su servidor emisor & #39; el reloj funciona un par de minutos rápido, los tokens llegan ya antiguos según el cliente & #39;s. Y, por supuesto, el error de comparación de segundos contra milisegundos, el que bit Toolz.dev, se anuncia en el momento en que ve una validez perfecta exp En una ficha, su cliente jura caducidad.
Auditar lo que pone su proveedor de identidad en tokens
La mayoría de los equipos nunca han leído los tokens que sus IdP acuñan, y vale la pena hacerlo. Decodifique uno y podrá encontrar direcciones de correo electrónico, nombres completos, URL de imágenes, identificadores de inquilinos: PII que se encuentra en cada solicitud de API, se almacena en el almacenamiento local y se puede leer mediante cualquier cosa que tenga en sus manos el token. Aquí ' es mi postura obstinada, y yo ' lo discutiré con cualquiera: don ' pongo correos electrónicos de usuario en cargas útiles JWT. El sub La afirmación existe precisamente para que pueda llevar un identificador opaco y buscar los detalles humanos del lado del servidor. Cada reclamo adicional son datos que están transmitiendo y bytes que está pagando en cada solicitud. Decodifique, audite, luego vaya a recortar las asignaciones de reclamaciones de su IDP.
Verificación de roles y ámbitos durante la depuración de autorización
La autenticación dice quién eres; la autorización dice lo que puedes hacer, y cuando la autorización se comporta mal, la respuesta está en los reclamos. El usuario jura que es ' ¿Es un administrador pero obtiene 403? Decodifica su token. Si role dice user, el token se acuñó antes de la promoción y es necesario volver a iniciar sesión, una consecuencia clásica de que los tokens apátridas lleven instantáneas obsoletas. Si el rol está presente pero el acceso aún falla, verifique el nombre y la forma exactos del reclamo: roles contra role, matriz vs cadena, scope Como una cadena delimitada por espacio frente a scp como una matriz. Comprobación de middleware payload.roles.includes('admin') contra una carga útil que tiene role: "admin" falla silenciosa y exasperantemente. Dos tokens decodificados uno al lado del otro, uno funcionando y otro no, generalmente lo ajustan en menos de un minuto.
Comparación de acceso y actualización de contenido de tokens
En una configuración de token dual como la mía, los dos tokens deberían verse significativamente diferentes, y la decodificación de ambos es la auditoría. El token de acceso: corto exp, además de lo que sea que las afirmaciones de la API necesitan por solicitud. El token de actualización: largo exp, un jti para seguimiento de revocaciones, y lo más parecido posible a nada más. Si su token de actualización contiene roles y datos de perfil, algo ' está desactivado - it' solo se presenta en un punto final y debería ' duplicar el token de acceso ' trabajo. Esta verificación paralela también detecta la vergonzosa clase de error en la que ambos tokens obtienen accidentalmente el mismo TTL, lo que convierte su " ventana de acceso de 15 minutos" en el teatro de seguridad. Pregúntame cómo sé comprobarlo.
Tokens de sesión JWT vs Opaque: una comparación honesta
| J.T. | Ficha de sesión opaca | |
|---|---|---|
| apatridia | Autocontenido; cualquier servidor con la clave verifica sin una búsqueda | El servidor (o una tienda compartida como Redis) debe buscar todas las solicitudes |
| anulación | Difícil - válido hasta exp A menos que construyas un denillist, que reintroduce el estado |
Trivial: elimina el registro del lado del servidor, el token se apaga instantáneamente |
| Tamaño por solicitud | cientos de bytes a más de un kilobyte, en cada solicitar | ~32–64 bytes |
| donde ocurre la validación | En cualquier lugar que tenga la clave (pública), ideal para microservicios | Dondequiera que viva la tienda de sesiones |
| Reclamar frescura | Instantánea en el momento del problema; los cambios de roles esperan para volver a emitir | Siempre actualizado: lee datos en vivo |
| depurabilidad | Decodificar y leer reclamos al instante | Opaco por diseño; requiere acceso a la tienda |
Uso jwts para Toolz.dev y todavía les diré que están sobrescritas. La historia de revocación es genuinamente mala: cuando prohibis a un usuario, su token de acceso sigue funcionando hasta que exp- que es exactamente la razón por la que mis tokens de acceso duran 15 minutos y el token de actualización de 7 días es lo que puedo eliminar en el lado del servidor. Ese híbrido es el patrón honesto: JWT apátridas de corta duración para una verificación barata, un punto de control con estado para el control. Si usted ' estás ejecutando un monolito con una base de datos, las sesiones simples son más simples, más pequeñas y revocables instantáneamente: el superpoder de verificación distribuida de JWT' es resolver un problema que no tienes ' No tengo.
Mientras nosotros ' estamos comparando - HS256 vs RS256 de un vistazo:
| HS256 | 256 rupias | |
|---|---|---|
| Modelo clave | Un signo secreto compartido y verifica | Señales de clave privada, clave pública verifica |
| ¿Quién puede mentar fichas? | cualquiera que tenga el secreto | Solo el titular de la llave privada |
| Mejor ajuste | Servicio único, emisor = verificador | Microservicios, desplazados internos de terceros, JWKS |
| Tamaño de la firma / velocidad | Más pequeño, más rápido | Más grande, más lento, más seguro de distribuir |
Preguntas frecuentes
¿Es seguro pegar un JWT en un decodificador en línea?
Sólo si el decodificador se ejecuta en el lado del cliente. Un token real es una credencial en vivo: enviarlo a alguien. El servidor #39;s coloca una clave de trabajo en sus registros. El decodificador JWT Toolz.dev realiza todas las decodificaciones en su navegador y no transmite nada; puede confirmarlo usted mismo mirando la pestaña Red mientras pega. Para decodificadores puede 't verificar, usar tokens caducados o de prueba únicamente.
¿Puedes decodificar un JWT sin el secreto?
Sí, eso y #39; es el punto que más la gente pasa por alto. El encabezado y la carga útil son JSON codificados en base64url y la codificación no es cifrado. Cualquiera puede leer cada reclamo sin ninguna clave. La clave secreta (o privada) sólo es necesaria para crear o verificar la firma. La decodificación no requiere nada; confiar requiere verificación.
¿Cuál es la diferencia entre decodificar y verificar un JWT?
Decodificación lee el contenido: dividido en puntos, base64url-decode, parse json. Verificar prueba de autenticidad: volver a calcular o comprobar la firma usando la clave secreta o pública, confirmar el algoritmo, verificar la caducidad. Un decodificador le muestra lo que afirma un token; solo la verificación, realizada en el servidor con la clave, le dice si lo cree. Nunca autorices en base a afirmaciones decodificadas pero no verificadas.
¿Por qué mi JWT se muestra como no válido o caducado?
Muy a menudo el exp realmente ha pasado: decodécalo y comprueba la fecha. Siguientes sospechosos: un token truncado de una copia y pegado descuidado, an aud investigaciones operacionales iss Eso no coincide con la configuración de su verificador, el sesgo del reloj entre servidores o una firma de una tecla rotada. Si el decodificado exp Se ve bien, pero su código rechaza el token, verifique si está comparando segundos con milisegundos.
¿Están los JWT encriptados?
Los JWT estándar, técnicamente JWS, según RFC 7515, están firmados, no cifrados. La firma detecta manipulación pero no oculta nada; la carga útil es legible por cualquiera. Existe una variante cifrada (JWE), pero es poco común en la autenticación web típica. Regla práctica: trate cada carga útil de JWT como pública y nunca coloque contraseñas, claves API o datos confidenciales en uno.
¿En qué formato está el reclamo EXP?
exp es una fecha numérica: segundos desde la época de Unix (1 de enero de 1970 UTC), como se define en RFC 7519. Lo mismo para iat y nbf. El error clásico está usando JavaScript Date.now(), que devuelve milisegundos, produciendo tokens que parecen caducados instantáneamente o tienen fechas de vencimiento alrededor del año 56.000. Si una marca de tiempo decodificada muestra un año de cinco dígitos, ese ' es tu error.
¿Qué es el ataque de Alg None?
RFC 7519 permite JWT no seguros con "alg": "none" y una firma vacía. Las bibliotecas antiguas confiaban en el campo de algoritmo de encabezado, por lo que los atacantes despojaron las firmas, set alg para none, y verificada con reclamos falsificados. RFC 8725, las mejores prácticas actuales de JWT, requiere que los verificadores anclan una lista explícita de permission-algorithms in code e ignore lo que sea que pida el token.
¿Debo usar HS256 o RS256?
HS256 utiliza un secreto compartido para firmar y verificar: simple y rápido, adecuado para un solo servicio que emite y verifica sus propios tokens. RS256 firma con una clave privada y verifica con una pública, por lo que muchos servicios pueden verificar sin poder falsificar. Regla general: monolito, HS256; microservicios o proveedor de identidad de terceros, RS256.
envolviendo
construí el Decodificador JWT porque lo seguí necesitando mientras construía Toolz.dev, los mismos tokens de acceso de 15 minutos y tokens de actualización de 7 días I' He estado analizando a lo largo de esta guía. Decodifica instantáneamente, traduce las marcas de tiempo que causan el 90% de la confusión y nunca envía su token a ninguna parte. Esa última parte es 't una casilla de verificación de funciones; para una herramienta que maneja credenciales en vivo, es ' es todo el diseño.
Si las fichas son parte de su depuración diaria, los vecinos también se ganarán la vida: el Convertidor de marca de tiempo Para la arqueología de la época, la Convertidor Base64 Para pinchar en segmentos crudos, el Formateador JSON para reclamar blobs y el generador de hachas Cuando estás trabajando con Digests. Para el flujo de trabajo más amplio, mi Guía de herramientas de depuración de API Cubre donde encaja un decodificador en el bucle.
Y mantenga la versión de una sola oración pegada a su monitor: la decodificación le dice lo que dice un token, la verificación le dice si debe creerlo. Confundir a los dos y enviarás el tipo de error que termina como la anécdota de apertura en la publicación del blog de alguien. Esta vez fue mío.
