Koas.dev

Si al instalar la extensión de PECL OpenSwoole nos aparece este error:

PHP Warning: PHP Startup: Unable to load dynamic library 'openswoole.so' (tried: /usr/lib/php/20230831/openswoole.so (/usr/lib/php/20230831/openswoole.so: undefined symbol: socket_ce)) in Unknown on line 0

es porque hemos añadido la línea extension=openswoole.so en el fichero php.ini, y esto hace que intente cargar la extensión de OpenSwoole antes de tener cargadas otras de las que depende (como sockets o curl, dependiendo de las opciones que hayamos indicado al instalar OpenSwoole).

La solución es quitar esa línea del fichero php.ini, y llevárnosla como un fichero a la carpeta conf.d, por ejemplo /etc/php/8.3/cli/conf.d/30-openswoole.ini.

Aquí la clave es que ese número inicial (30 en este ejemplo) sea superior al que tienen los ficheros que cargan las extensiones necesarias (en mi caso eran 20-curl.ini y 20-sockets.ini).

Cuando tenemos que subir ficheros grandes a S3 en varias partes las peticiones PUT no deben llevar la cabecera “Content-Type”, pero Axios la pone por defecto y esto genera un error 403.

Para que Axios no añada esta cabecera hay que indicarlo expresamente usando el valor false:

headers: { "Content-Type": false }

Para probar con código PHP que irá en el futuro en un paquete de Composer podemos incluirlo en nuestra aplicación de esta forma:

• Creamos un repositorio de Github para el paquete (esto es obligatorio para poderlo subir a Packagist).
• Supongamos que nuestro paquete se llama karontek/bcons y que el repositorio está en /home/koas/bcons. En el fichero composer.json de la aplicación donde queramos usar ese paquete añadiremos:

"repositories": [
  {
    "type": "path",
    "url": "/home/koas/bcons"
  }
]

"require": {
  "karontek/bcons": "dev-main"
}

Estoy desarrollando bcons y el entorno de desarrollo de la aplicación web es el típico de Vue3 con Vite que abre un puerto para poderse conectar y que haga el refresco automático etc. En mi caso accedía con esta URL: http://bcons.local:4321

Pues bien, la API se ejecuta desde http://bcons.local/api y me estaba volviendo loco porque no había forma de crear las cookies desde el PHP de la API. Aunque en teoría el puerto no afecta a las cookies no conseguía que el navegador creara la cookie.

La solución es configurar nginx para que las peticiones al puerto 80 se redirijan al puerto 4321 que es donde Vite está sirviendo la app. Así quedaría el bloque de configuración (incluyendo la regla para que las peticiones a las API se ejecuten correctamente):

upstream devapp {
    server bcons.local:4321;
}

server {
  listen 80;
  listen [::]:80;
  proxy_hide_header X-Frame-Options;

  server_name bcons.local www.bcons.local;
  root /home/koas/Server/htdocs/bcons;
  index index.php index.html;

  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
  }

  location /api/ {
     try_files $uri $uri/ /api/index.php?$query_string;
  }

  location / {
    proxy_pass http://devapp;
  }
}

Ahora accedo a la app de desarrollo a través de http://bcons.local (sin necesidad de especificar el puerto) y la cookie se crea sin problema.

Esta página es muy útil para verificar que hemos configurado correctamente las cabeceras de seguridad:

https://securityheaders.com