Página temporal en admin.all2cart.com para comprobar contra
api.all2cart.com la sesión por cookie y los endpoints del catálogo,
públicos y del panel.
Recargar la página es la prueba de verdad de que la sesión se mantiene: recarga el navegador entero y, si sigues dentro, es porque la cookie ha viajado sola.
Acceso del equipo (POST /api/v1/admin/login). Sólo acepta cuentas
admin: un cliente recibe el mismo error que una contraseña incorrecta.
Ojo con el límite: el acceso del panel bloquea a los 3 intentos fallidos por email + IP durante un minuto. Es a propósito.
POST /api/v1/registerRegistro público de clientes. No necesita sesión, y al terminar deja la sesión iniciada: no hace falta pasar por el login después.
Esa segunda casilla es la prueba que importa: el rol no es asignable, así
que la cuenta tiene que salir como customer igualmente. Si alguna vez sale
admin, para todo. El límite aquí son 5 registros por minuto y
por IP.
GET /api/v1/productsLo que ve la tienda. No necesita sesión, y sólo devuelve productos publicados: un borrador o un archivado no existe aquí.
Pedir una categoría padre trae también lo que cuelga de ella: con
category=summer salen los productos de Summer Items y de
Trending Items Summer. Una categoría que no existe devuelve lista vacía, no el
catálogo entero.
GET /api/v1/admin/productsRequiere sesión de administrador. A diferencia del público, aquí sí se ven los borradores y los archivados.
GET /api/v1/products/{slug} para la pública y
GET /api/v1/admin/products/{id} para la del panel. Se abren con los botones
«ficha» de las listas de arriba, o escribiendo el slug a mano.
POST /api/v1/admin/images
Requiere sesión de administrador. Sube el fichero y devuelve la URL, que es lo que luego
va en images[].url al guardar el producto.
Lo que se comprueba es el contenido del fichero, no su extensión: si
renombras un .txt a .jpg tiene que responder 422.
Merece la pena probarlo.
/api/v1/meLa ficha de quien tiene la sesión abierta. No lleva ningún id en la URL: no existe la posibilidad de pedir ni editar la de otro. Vale igual para un cliente y para una cuenta del equipo.
Cambiar el email pone email_verified_at a null: el correo nuevo
todavía no se ha demostrado. Y ojo con la diferencia — GET /api/v1/user
devuelve sólo la identidad mínima para saber si hay sesión; esto es la ficha completa.
PUT /api/v1/me/password
Exige la actual a propósito: sin eso, quien pille una sesión abierta se queda con la cuenta
para siempre. Pruébalo con una contraseña actual equivocada — tiene que dar
422. Al cambiarla se renueva la sesión, así que seguirás dentro
pero cualquier copia de la cookie anterior deja de valer.
/api/v1/me/addressesVarias por cliente (máximo 20), con una predeterminada de envío y otra de facturación, que pueden ser la misma o no.
Tres reglas que se pueden ver funcionando aquí mismo: la primera dirección
se marca sola como predeterminada de las dos cosas; marcar otra apaga la
anterior; y al borrar la predeterminada otra ocupa su sitio.
Prueba también con el país escrito como España: tiene que dar 422.
GET /api/v1/admin/customers
Requiere sesión de administrador. Sólo alcanza a clientes: el id de una
cuenta del equipo devuelve 404 en toda esta zona.
Una comprobación que merece la pena: coge el id de tu propia cuenta de administrador y
pídelo aquí a mano. Tiene que dar 404 — si diera la ficha, el panel de
atención al cliente serviría para cambiarle la contraseña a otro del equipo.
GET /sanctum/csrf-cookie — deja las cookies XSRF-TOKEN y de sesión.POST /api/v1/admin/login — con la cabecera X-XSRF-TOKEN.GET /api/v1/user — sin nada más que la cookie: si responde, hay sesión.POST /api/v1/logout — y se vuelve a pedir /user para confirmar el 401.
Del catálogo, lo que conviene ver funcionando: que el listado público
no saque borradores, que la ficha de uno no publicado sea un
404, que el panel sí los vea, y que el precio venga en
price_cents — enteros, nunca euros.