El webservice de PrestaShop 8 da 401 desde Python: CGIPassAuth

Un compañero de la comunidad, con años de PrestaShop a la espalda, no conseguía conectar a la API desde Python en una tienda 8.1.4: creaba la clave en el back-office y el servidor le seguía pidiendo usuario y contraseña. La causa estaba en el servidor, no en la clave: Apache no le pasaba a PHP la cabecera de autenticación. Lo resolvió con una sola línea en el .htaccess: CGIPassAuth On.

Qué pasaba

El webservice de PrestaShop usa autenticación básica HTTP: la clave va como usuario y la contraseña va vacía. El cliente (Python, curl, un ERP, un conector) la manda en la cabecera Authorization. Si PHP no recibe esa cabecera, PrestaShop no ve ninguna clave y responde con un 401, igual que si no hubieras mandado nada.

Pasa sobre todo cuando PHP corre como CGI o FastCGI, que es lo habitual hoy con PHP-FPM en Plesk, cPanel y casi cualquier VPS. En ese modo Apache no reenvía la cabecera Authorization a PHP salvo que se lo digas expresamente. Por eso la misma tienda puede funcionar en un servidor y fallar en otro sin haber tocado nada de PrestaShop.

La solución que funcionó

Añadir al .htaccess de la raíz de la tienda:

CGIPassAuth On

Es una directiva de Apache 2.4.13 o posterior que hace justo eso: entregar la cabecera de autenticación a los procesos CGI. Gustavo, de la comunidad, recordó la otra forma clásica, útil en servidores donde el hosting no deja usar CGIPassAuth desde el .htaccess:

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule . - [E=HTTP_AUTHORIZATION:%1]

Esta copia la cabecera a una variable de entorno que PHP sí lee.

Cómo comprobarlo en dos minutos

Crea la clave en Parámetros avanzados → Webservice, dale permiso GET sobre el recurso que vas a probar y lanza esto:

import requests

r = requests.get(
    "https://tu-tienda.com/api/products?output_format=JSON",
    auth=("TU_CLAVE", ""),
)
print(r.status_code)
print(r.text[:300])

• 200 y un JSON con productos: todo bien.
• 401: o la cabecera no llega (lo de arriba), o la clave no está activada.
• Un mensaje sobre permisos del recurso: la clave sí llega, pero no tiene permiso para ese recurso o ese método.
• 404 en /api: falla la reescritura de URL; revisa que el .htaccess de PrestaShop esté en la raíz y que el servidor tenga mod_rewrite activo.

Existe la alternativa de mandar la clave en la URL con ?ws_key=. Funciona sin tocar el servidor, pero evítala en producción: la clave acaba en los registros de acceso, en el historial y en cualquier intermediario por el que pase la petición.

El aviso de «la ruta del servicio web no funciona»

Unos meses después, otro miembro del grupo, ya con PrestaShop 8.1.6 y PHP 8.1, veía en el back-office el aviso de que la ruta del webservice no funcionaba y que había que habilitar la reescritura de URL. Tenía las líneas de autorización en el .htaccess y la API respondía bien a sus llamadas reales.

Ese aviso sale de una comprobación que hace la propia tienda: se llama a sí misma en su dirección /api y, si no recibe respuesta o recibe un error distinto de «no autorizado», lo muestra. Si el servidor no puede llamarse a sí mismo por su dominio (un cortafuegos, un CDN delante, una resolución interna distinta), la comprobación falla aunque los clientes de fuera entren sin problema. Lo que manda es la prueba real: si tu script o tu ERP reciben un 200, el webservice funciona.

Y ya que estás con la clave

Dale a cada clave solo los recursos y métodos que necesita. Una integración que lee pedidos no necesita escribir en employees ni en customers. Una clave con permisos de más es una de las puertas de entrada habituales cuando se filtra, y en el back-office no hay nada que te avise de que alguien la está usando.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación