[Résolu]Plugin Mastodon et serveur Nginx

Bonjour
Pour un site sur serveur Apache, je parviens à configurer une instance mastodon dans la configuration du plugin Mastodon - SPIP-Contrib.
Pour un autre site sur serveur Nginx, la configuration échoue : après saisie de l’url de l’instance, je suis bien dirigé vers la page d’autorisation de l’instance (où je suis identifié et reconnu) mais après validation je suis renvoyé sur une page 404 de mon site.
Dans la doc du plugin Mastodon, il est fait mention du fichier .htaccess, mais ce dernier est inopérant avec les serveurs Nginx.
Je n’ai pas la main sur les réglages de ce serveur.
Que faudrait-il que j’indique à celui qui gère le serveur ?
Dans le fichier .htaccess, je vois :

APIs
http://site/xmlrpc.api
http://site/atom.api/articles/1234
https://site/offline.api.sw.js
RewriteRule ^(ecrire/)?([\w]+)\.api([/.](.*))?$ spip.php?action=api_$2&arg=$4 [QSA,L]
Fin des APIs

C’est cela qu’il faut régler dans le serveur Nginx ?

Merci d’avance.

Je complète :
Dans Nginx et Spip, je vois cela :

 # redirection des APIs
    location ~ /([\w]+).api([/.](.*))$ {
        rewrite ^/([\w]+).api([/.](.*))?$ /spip.php?action=api_$1&arg=$3 last;
    }

Je me réponds, et je mets en résolu.
C’est bien le code ci-dessous qu’il faut configurer sur le serveur :

`# redirection des APIs
    location ~ /([\w]+).api([/.](.*))$ {
        rewrite ^/([\w]+).api([/.](.*))?$ /spip.php?action=api_$1&arg=$3 last;
    }`

Je pense que l’expression que tu montres n’est plus entièrement à jour comparé au htaccess correspondant

###
# APIs
# http://site/xmlrpc.api
# http://site/atom.api/articles/1234
# https://site/offline.api.sw.js
RewriteRule ^(ecrire/)?([\w]+)\.api([/.](.*))?$ spip.php?action=api_$2&arg=$4 [QSA,L]

Disons, que j’ai envoyé au gestionnaire du serveur la proposition d’ajout :

Et l’installation du plugin mastodon a pu aboutir.
Pour ma part, je n’y connais absolument rien, je n’ai fait que reprendre l’info dans : Nginx et Spip.

Aurait-il fallu que j’envoie :

# redirection des APIs
    location ~ /([\w]+).api([/.](.*))$ {
        rewrite ^/([\w]+).api([/.](.*))?$ /spip.php?action=api_$2&arg=$4 last;
    }

Non…
Je suppose quelque chose comme cela (ecrire/)? en plus, avec le changement des numéros d’arguments :

# redirection des APIs
location ~ /(ecrire/)?([\w]+).api([/.](.*))$ {
    rewrite ^/(ecrire/)?([\w]+).api([/.](.*))?$ /spip.php?action=api_$2&arg=$4 last;
}

Testé et fonctionnel.

Merci.

Du coup, j’ai vu que je pouvais modifier Nginx et Spip.
J’ai ajouté un chapitre " Redirection des .api bis".

Comment expliquer qu’en 2023, la regex qui marchait, selon @Loiseau2nuit, était :

rewrite ^/([\w]+).api([/.](.*))?$ /spip.php?action=api_$1&arg=$3 last;

alors qu’en 2025, ce serait :
[Edit: pas « serait » mais « est », c’est la regex du .htaccess officiel]

rewrite ^/(ecrire/)?([\w]+).api([/.](.*))?$ /spip.php?action=api_$2&arg=$4 last;

L’ajout de /ecrire optionnel, ok, mais le décalage de l’ordre des attributs ?

Est ce que c’est Ezrest (ping @eric_tonton) qui ne prend pas les arguments dans l’ordre conventionnel des apis SPIP ?

Ah bé oui, suis-je bête, une capture en plus (/ecrire/) donc décalage des arguments, c’est logique.

Donc la version de @Loiseau2nuit fonctionne, mais date de 13 ans :rofl:

J’ai mis à jour la page du carnet en supprimant la vieille version (autant ne pas embrouiller pour rien les gens qui liront ça dans le futur).