CRON et erreur 403

[dom54]

Bonjour,

Parfois lecteur, j'ai actuellement un souci... et deviens auteur ;o)

J'ai besoin de créer une tache CRON qui appelle une page de mon propre site... Type GET, toutes les 60 minutes.
Ainsi, je cree la tache, y mets ces éléments et je sauvegarde sans erreur
Les premiers essais conduisent à un 403 :/
J'ai tenté d'identification, en reprenant mon token Joomla, mais les 2 alternatives (jeton ou titulaire) et mon code ne valide rien...

A noter que j'essaie d'appeler la meme page depuis mon poste avec un wget ou un curl et ai également une erreur 403
Depuis mon Chrome, ou autre browser local, cela fit ce que l'on attend.

Je verrais bien une limite en termes de sécurité dans le .htaccess ou dans le backend, mais je ne sais pas où chercher...

Aurions nous une piste ?
Merci par avance

[woluweb]

Chez mon hébergeur, quand je configure une tâche CRON ça ressemble à ceci:

wget -O /dev/null "https://www.exemple.be/mapage" >/dev/null 2>&1

Pas d'erreur dans la tâche CRON ?
A quoi vois-tu que tu as une 403 d'ailleurs ?

[dom54]

Merci de cette piste...
Mon hébergeur (OVH) ne semble pas permettre autre chose que des appels PHP... donc pas de WGET coté hébergeur. Pas d'erreur dans le CRON log, mais je ne vois pas le travail se faire dans les bases... Donc je pense que cela part en vrac.
Coté Joomla (je suis en J5), il y a bien les taches planifiées d'origine Joomla, mais... cela termine également en 403 (et je ne sais pas si le jeton fonctionne ou pas mais avec et sans, erreur 5, 403 Forbidden)
Enfin, si j'appelle depuis mon poste (j'ai les 2 outils en version Windows) via CURL ou WGET le site, j'ai aussi des 403 Forbidden
A noter que
c:\>curl mon.site donne un 403
Mais c:\>curl --user-agent "bidon/1.0" mon.site récupère bien le site (et c'est pas peu dire que le UA bidon/1.0 est connu) !
Donc je vois avoir qque chose sur le site qui me bloque... mais quoi et où ???
J'ai supprimé un temps les captcha, mais pas mieux
Je ne pense pas avoir d'accès réservé à des membres
Il doit y avoir une sécurité qui identifie un user agent mais mystère pour le moment...
Dans l'idée, ce serait bien que cela s'intègre dans les taches planifiées de Joomla... afin de centraliser les choses... meme si je pense que le souci est plus sur le GET page que sur la mécanique CRON...

[lefabdu51]

403..... soucis de droits utilisateurs ?
essaye cette requete :
CURL -k -A "Mozilla" -u XXXXXXXXXX: https://www.mondomaine.com/mapage.html

-k pas de controle du certificat
-A on utilise l'user agent mozilla
-u url complète a traiter.

second point le firewall ovh est activé?
Si c est le cas desactive le.

3eme point tu as modifié le fichier .htaccess de ton site ?

4eme point tu a accès a ton site via ftp ?

[dom54]

Bonjour,
Alors... OVH...
Dans la CRON, on peut donner la version de PHP. Je me suis acharné sur mon code PHP avant de voir dans les exemple, que leurs noms de fichiers sont de type toto.sh ...
Et de finir par comprendre que si version PHP alors fichier PHP, si pas de version de PHP alors bash et donc un ficher.sh !
Super simple quand on sait que du coup, on peut passer sur un bash et non un appel php !

En fait je ne suis pas Linux pour un rond, donc j'ai essayé des version CURL ou WGET sur mon poste windows, et voyais le 403.
La CRON de Joomla me disait aussi erreur 5 / 403 (ca, je n'ai pas encore réussi a m'en sortir, mais c'est un manque de UA dans les headers !)

Et apres en fouillant les logs "error" et "http" et cron, j'ai vu des choses...
dont le fait que la User Agent était WGET ou CURL et que la réponse était "malicous crawler" ou que de l'autre coté, "No user agent defined" !

Du coup, je viens de solutionner la CRON OVH en utilisant un bash, avec wget et en forçant un UA qui ne contient pas le terme wget et ca passe !

Le firewall est bien activé, je le laisse, car c'est supposé faire un peu de protection... (et surtout que j'ai solutionné mais le désactiver aurait surement permis de confirmer un souci entre l'appel et le site). Il doit etre a la base de la sécurité qui m'a bloqué, mais l'un dans l'autre, je sais pourquoi je ne suis pas passé... Donc pas grave, mais compliqué de démasquer la cause, je pensais au départ a la CRON TASK...

Le 403 n'était pas un souci de droit sur les users car en appelant la page depuis un browser, sans s'être identifié ca passait

Donc bien vu les amis... En rubber duck debug et pistes proposées, nous y sommes arrivés..
Merci