Erreur 403 application click once

plus possible d'interroger un fichier php via une application sans un HttpRequestHeader.UserAgent. Pourquoi pas par rapport à la sécurité et bonne pratiques...

Bonjour,

Avez-vous une différence dans Hébergement > multisite > colonne "Firewall" ou "Pare-feu" ?

Je soupçonne celui-ci.

Bonjour Fritz2cat,
Je n'ai pas de différences au niveau de la colonne "Firewall".

Par contre, je remarque que le sous domaine incriminé (4ème ligne sur l'image jointe) avait une entrée DNS AAA valide en IP V6 contrairement aux autres sous domaines. Je l'ai donc désactivé l'IPV6 au niveau DNS (diffusion 24h)
mes deux problèmes sont peut-être liés:
-plus possible d'interroger un fichier php via une application sans un HttpRequestHeader.UserAgent.
>Ce problème est résolu (contourné) au niveau de l'application
-plus possible de lancer une application click-once sur mon espace (Perso) alors que cela fonctionne sur un autre compte perso également.
>Une application click-once est télécharger dans un premier temps puis fais appel au manifeste sur le serveur. Et c'est là que cela doit coincer car l'application n'intègre pas de UserAgent à ce niveau.

la piste du firewall est tout de même intéressante. mais dans mon cas, tout était désactivé.

la piste du firewall

On a effectivement un 403 avec un User-Agent comme wget.

Bonjour Fritz2cat,
il y a donc bien quelque chose au niveau du firewall. Pensez-vous que c'est possible de corriger ce problème ? Malheureusement, je n'ai pas la main sur ce type de paramétrage pour autoriser cette règle.
Merci pour votre implication.
Cordialement

Merci pour votre implication.

Sans connaître vos domaines, on ne peut pas s'impliquer plus.

Je confirme ce probleme,
Sur mon domaine (www.simhubdash.com) depuis 11h45 environ, plus aucun appels sans user agent ne fonctionnent.

Bonjour Fritz2cat,
je vous ai envoyé les domaines en privé.
Cordialement

je vous ai envoyé les domaines en privé.

J'ai répondu en privé, je n'ai malheureusement pas pu reproduire avec wget.

(www.simhubdash.com)

Bonjour,

de même, je n'ai pas pu reproduire le 403.

Bonsoir à tous.
Même soucis de chargement d'une page PHP depuis une application DotNet avec un WebClient sans UserAgent. Cela fonctionne si j'ajoute un UserAgent.
Impossible de contourner ceci, ni avec le .ovhconfig, ni avec .htaccess.
Ce nouveau comportement qui date de ce matin est très gênant.

AltiFab.

J'ai le meme probleme depuis le 30 octobre a 11h32.

sans user agent, on a un HTTP 302 avec setCookie:ovh_challenge_cookie qui renvoi sur la meme page.

curl daspower.fr -H User-Agent:

302 Found

---

nginx

Bonjour,

question con : c'est quoi vos cas d'usage ou vos requêtes non pas de User-Agent ?

Cordialement, janus57

moi c'est une station meteo, mais ca peut aussi bien etre des call back d'API diverses, ou n'importe quel equipement electronique avec des firmwares propriétaires sur les quels ont a pas forcément la main.

Bonjour Fritz2cat,
il y a bien un problème de firewall côté backbone chez OVH.
ci dessous 2 tests afin que vous puissiez constater le problème dans vos logs:
1- avec agent https://teleftech.fr/test_api.php?test=123
(avec agent car nous appelons la requête dans le navigateur)
2- test sans agent (résultat page banche) https://teleftech.fr/test.php
(sans agent car c'est le script qui génère la demande)
=>J'en déduis une erreur 403 sur ce second script car pas d'agent, appellation directe du script, ce qui est confirmer par mon application
détail du test :
fichier test.php (sans agent)
include ('./test_api.php?test=123');
?>

fichier test_api.php
$test=stripslashes($_GET['test']);
if ($test=='123'){
echo 'test réussi avec agent';
} else{
echo 'test non réussi sans agent';
}
?>

@ANTHONYG38, je suis tout à fait d'accord avec vous. plus aucuns appareils connecté, API... ne peuvent maintenant se connecter sur le site OVH sans un UserAgent.

@Fritz2cat
Une modification au niveau des firewalls OVH a été planifié depuis le 31/10/2024 et à pour conséquence ce topic.
M. Fritz2cat, merci pour votre retour.
Cela est très problématique et commence à toucher toute la communauté (le temps que la mise à jour du 31/10 se termine...)
Pour information, j'ai dû héberger mon application at home ;(
, le temps que le problème se résolve
Cordialement

Bonjour à tous,

Je vous confirme que nous travaillons régulièrement à l'amélioration des protections de nos infrastructures contre le trafic malveillant à destination de vos sites & applications.

Dans ce but, nous avons fait évolué le filtrage des accès sans user-agent, la pratique étant extrêmement présente dans le trafic illégitime que nous rencontrons actuellement.
Ce change a été déployé de manière très progressive sur les infrastructures depuis les 2 dernières semaines avec des phases d'attente et d'analyse pour nous assurer que le trafic légitime n'est pas impacté. Le déploiement est désormais terminé depuis ce mardi matin.

La navigation passant avec des user-agent légitimes n'est pas bloquées (wget dans l'exemple de @Fritz2cat par exemple, qui doit plutôt être bloqué par le firewall applicatif, en ayant le domaine, nous pourrions aisément confirmer)
celle sans user-agent passe par un challenge facile à suivre pour tout navigateur bien configuré.

@ANTHONYG38 pouvez-vous me fournir en privé l'hébergement concerné que l'on regarde les logs ?
La 302 avec le cookie doit être suivie par tout navigateur normalement configuré. Nous avons besoin de plus détails pour regarder.

@DavidP62 dans les logs pour le premier lien, je n'ai que des 200 et 500 dans les logs. Pour le second lien, c'est uniquement du 200 et 404.
Donc pas de blocage sur ces deux liens.

@FabriceS25 avez vous des détails sur le webclient concerné ? le usecase ?
Effectivement ce comportement n'est pas configurable et situé en frontal des infrastructures.

Bruno B.

Bonjour,

mon hébergement :
tzhiwwm.cluster030.hosting.ovh.net
dans les log de hier par exemple, j'ai aucune ligne pour weather.daspower.fr

Vous ne prévennez pas quand vous changez des choses du genre qui peuvent impacter les utilisateurs ?
Je trouve ca assez limite que votre collegue Jérémie E. dans mon ticket de support CS10351013 me dise que le problème vient de mon site et me laisse chercher tout seul alors qu'il savait d'ou vient le probleme...

Sinon comment peut ont faire pour débloquer nos problèmes ?

Des appels API rest typiquement, le user agent est une norme des navigateurs. Une requête (embedded, API, client lourd etc...) n'en dispose pas par défaut. Je ne comprends pas qu'un tel changement ai pu être fait sans aucun préavis (confirmé par un ticket au support). Un hébergement ne veux pas dire nécessairement site web, il y a une multitude d'autres usages légitimes comme les API

Wget spécifie un user agent par défaut. Des qu'il est présent tout fonctionne. Mais en cas d'appel http simple sans user agent (par exemple en .net) toutes les requêtes sont rejetées. Cote serveur aucune trace dans les logs elles sont rejetées "en amont"

Bonjour,

Nous avons le même problème de requêtes sans user-agent qui finissent en 403. Nous sommes dans le contexte d'une application C#. Nous n'avons pas été prévenu à l'avance et n'avons pas pu demander à nos clients de mettre à jour leurs versions et nous avons du découvrir par nous-même que c'était ce header qui manquait. L'erreur n'étant pas très explicite...

Nos clients se retrouvent bloqués par ce changement et tous les appels vers notre serveur échouent. C'est extrêmement gênant pour notre business et nos clients.

@BrunoB-OVHCloud, quelles solutions sont possibles ? J'apprécierai fortement une réponse rapide de la part d'OVH à ce sujet pour pouvoir permettre à nos clients d'utiliser notre application qui ne fonctionne plus depuis le 5 novembre matin.

Nous avons constaté également que c'était depuis 11h45 comme indiqué par @2f9e37cb726af0c38578 dans un message au dessus.

Bonjour.
Application client lourd DotNet 4.8, communiquant depuis plus de 10 ans avec des WebServices hébergés sur le site www.altimed.fr

Exemple de code source le plus simple possible :
private void button1_Click(object sender, EventArgs e)
{
var wc = new WebClient();
// Si je décommente, ça fonctionne
//wc.Headers["User-Agent"] = "Altimed";
var sz = wc.DownloadString("http://www.altimed.fr");
MessageBox.Show(sz);
}

A noter que l'application client lourd est actuellement déployée sur à peu près 3000 machines en France que je ne me vois pas mettre à jour à la main.
Il faut absolument que vous vous rendiez compte des conséquences de ce choix arbitraire et que vous assumiez votre responsabilité.
L'absence de préavis est très grave et je n'exclue rien pour le préjudice subi.
Monopoliser toutes mes équipes sur ces 3000 machines + le blocage de mes clients...essayez d'imaginer la suite.

Non mais d'où vous changez ça sans prévenir à l'avance ?

AltiFab.

Bonjour,

Depuis hier à 11h45, nous avons constaté qu'OVH force l'utilisation du header user-agent dans les requêtes REST.
Ce header, désormais obligatoire, empêche toutes les requêtes faites par nos clients d'atteindre notre serveur powerusersoftware.com. OVH les bloque en amont et retourne une erreur 403 à l'appelant.
Aucune communication sur ce changement ne nous a été faite en amont, et nous n'avons donc pas pu ajuster nos requêtes d'API.
Tous nos 100 000 clients se retrouvent donc avec des requêtes en erreur et sans possibilité de mise à jour automatique (puisqu'il faut un appel serveur pour cela) ce qui nous 10k€ par jour et menace notre entreprise de mort si OVH ne lève pas (au moins temporairement pour permettre à la mise à jour de passer) cette nouvelle restriction de toute urgence!!!

Nous sommes dans la même situation, avec 100 000 machines concernées dans le monde entier.

Ce change a été déployé

Bonjour Bruno,

Lorsqu'on viole des RFC, on doit bien se douter que ça va gêner des clients légitimes au coin des entournures.
Je me rends bien compte que la bataille perpétuelle contre les hackers et les abuseurs de toutes sortes est une calamité.

L'absence de communication fait que votre offre mutualisée devient incompatible avec certains usages, notamment l'accès depuis certains trucsbidules comme des IoT et on en découvrira d'autres.

Le fait que le support réponde à côté de la plaque, probablement parce qu'ils ont été aussi laissés dans l'ignorance, m'étonnera toujours.


RFC 2616:


RFC 7231:

On est bien d'accord que le user agent devait toujours etre spécifié.
malheureusement sur bon nombre d'equipement avec des firmware chinois / indien codé n'importe comment ce n'est pas le cas.

Mais pourquoi OVH prend la décision arbitraire de tout bloquer, firewall actif ou non ? on pourrait laisser le choix au clients OVH de choisir s'ils veulent laisser passer ou non les requetes sans user agent.
ou mettre un filtre par defaut dans le .htacess ?

Celui qui se fera hacké a cause de ca à la limite OVH s'en fiche non ?

devait

Justement pas.

Dans les RFC chapitre préliminaire: bien faire la distinction entre **SHOULD** (devrait) et **MUST** (doit)
SHOULD n'est pas une obligation, mais une pratique _recommandée_.

Bonjour à tous,

Même soucis et même conséquences de mon côté, parc de matériels bloqué difficile à mettre à jour sans l'accès à mon api :/

J'espère sincèrement qu'ovh propose rapidement un palliatif.

Voici un exemple de dialogue avec la nouvelle mesure mise en place par OVH.

On voit bien le HTTP 302 intempestif.
Un navigateur (ou wget par exemple) va suivre la redirection 302 et ça va fonctionner.

Par contre un IoT qui rapporte par exemple la température d'un aquarium avec une requête GET pourrait ne pas aboutir: GET api.php/?temperature=29
car votre api ne verrait jamais la requête arriver.


~# wget -d --user-agent="" example.net
Setting --user-agent (useragent) to
DEBUG output created by Wget 1.21.3 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2024-11-06 11:03:11-- http://example.net/
Resolving example.net (example.net)... 2001:41d0:1:1b00:213:186:33:24, 213.186.33.24
Caching example.net => 2001:41d0:1:1b00:213:186:33:24 213.186.33.24
Connecting to example.net (example.net)|2001:41d0:1:1b00:213:186:33:24|:80... connected.
Created socket 3.
Releasing 0x000055f0395a4b20 (new refcount 1).

---request begin---
GET / HTTP/1.1
Host: example.net
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 302 Moved Temporarily
server: nginx
date: Wed, 06 Nov 2024 10:03:11 GMT
content-type: text/html
content-length: 138
set-cookie: ovh_challenge_cookie=tJe5PWdeKiQkjoLbbTTxHWOlnSk=;Max-Age=60; Path=/; HttpOnly
location: /
x-iplb-request-id: 200141D008001D380000000000000101:B1E0_200141D000011B000213018600330024:0050_672B3EDF_394AA:16E3
x-iplb-instance: 51724

---response end---
302 Moved Temporarily

Stored cookie example.net -1 (ANY) / [expiry 2024-11-06 11:04:11] ovh_challenge_cookie tJe5PWdeKiQkjoLbbTTxHWOlnSk=
Registered socket 3 for persistent reuse.
Location: / [following]
Skipping 138 bytes of body: [

302 Found

---

nginx


] done.
URI content encoding = None
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2024-11-06 11:03:11-- http://example.net/
Reusing existing connection to [example.net]:80.
Reusing fd 3.

---request begin---
GET / HTTP/1.1
Host: example.net
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Cookie: ovh_challenge_cookie=tJe5PWdeKiQkjoLbbTTxHWOlnSk=

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
date: Wed, 06 Nov 2024 10:03:11 GMT
content-type: text/html
content-length: 3130
server: Apache
accept-ranges: bytes
vary: Accept-Encoding
x-iplb-request-id: 200141D008001D380000000000000101:B1E0_200141D000011B000213018600330024:0050_672B3EDF_394AC:16E3
x-iplb-instance: 51724

---response end---
200 OK
Length: 3130 (3.1K) [text/html]
Saving to: ‘index.html’

index.html 100%[====================================================>] 3.06K --.-KB/s in 0s

2024-11-06 11:03:11 (97.1 MB/s) - ‘index.html’ saved [3130/3130]

Bonjour @ANTHONYG38
Dans le ticket mentionné, il y a un amalgame fait entre la redirection 301 vers le https et la redirection 302 ajoutée quand il manque un user-agent.
Pour le premier cas et comme vous le précise le support, la 301 n'est pas gérée sur nos infrastructures mais vient soit du htaccess soit du code de l'application hébergée, soit du navigateur qui force le SSL.
Pour la 302, vous devez dans votre client http soit le configurer pour suivre la redirection et accepter le cookie de validation, soit lui ajouter un user-agent.

Bruno B.

Bonjour,
Nous ne bloquons pas le trafic des clients sans user-agent, nous ajoutons un challenge afin de valider sa légitimité.
Une très grosse majorité du trafic passe ce challenge sans encombre.

Bruno B

Bonjour,
Avez-vous des détails sur le parc matériel concerné ?
Je suis dispo en privé pour en discuter.

Bruno B.

Bonjour,

C'est exact, aucune obligation, c'est pour cela qui nous ne bloquons que si la seconde validation via le challenge ne passe pas.

Bruno B.

r cas et comme vous le précise le support, la 301 n'est pas gérée sur nos infrastructures mais vient soit du htaccess soit du code de l'application hébergée, soit du navigateur qui force le SSL.
Pour la 302, vous devez dans votre client http soit le configurer pou

oui au début j'avais pas fais attention pour le 301, ca venait du SSL donc ca j'ai réussi facilement a ne plus l'avoir.

par contre la redirection 302, il redirige vers une URL avec des paramètres GET en moins donc même si je la suivait, les données ne seraient pas envoyées correctement.
J'ai demandé au fabricant du matériel une mise à jour pour envoyer un user agent.
Mais je trouve ca pas normal de votre part de bloquer ca sans nous laisser la main dessus...

vous ne pouvez pas mettre ce filtrage uniquement si le firewall est activé ?

Bonjour,

C'est exact, aucune obligation, c'est pour cela qui nous ne bloquons que si la seconde validation via le challenge ne passe pas.
La RFC date de 10 ans, vous imaginez bien que les challenges liés à la sécurité et aux comportements ont fortement changés depuis.
C'est pour prendre en compte ces changements que nous nous adaptons et afin de continuer à respecter la RFC, nous ne bloquons pas les requêtes sans user agent mais nous ajoutons un second niveau de validation lorsque c'est nécessaire. Si là aussi la validation ne passe pas, alors oui une erreur 403 va être renvoyée.

Je suis demandeur de feedbacks pour des problématiques telles que celle remontée ici afin d'investiguer.

Je me permet également de préciser que le support est bien dans la boucle et accompagne les clients. Je suis preneur des tickets dans le cas contraire.

Bruno B.

Ce filtrage est situé bien en amont des serveurs web appliquant le firewall applicatif, il ne nous est pas possible de changer cela.
Avez-vous les traces complètes d'une requête avec la perte d'éléments svp ?

Bruno B.

Merci du retour @BrunoB-OVHCloud

all applicatif, il ne nous est pas possible de changer cela.

C'est donc bien pour cela qu'on ne voit meme pas les requetes dans les fichiers de log, encore une fois contrairement a ce que me dit le support dans mon ticket CS10351013...
( leur réponses sont vraiment légères techniquement pour un support).

on ne voit meme pas les requetes dans les fichiers de log

C'est logique (puisque c'est le frontal nginx qui met le client http sur une voie de garage), mais c'est compliqué pour débugguer les incidents.

Je comprends le désarroi des clients qui sont dans la panade.

Bonjour
Pouvez-vous donner des explications sur ce 2ème niveau de validation dont vous parler? Que devons-nous faire concrètement pour débloquer la situation?
Pas de réponse du support depuis hier sur notre ticket CS10373635, malgré 2 appels et une relance mail...
En attendant, notre entreprise est paralysée, donc un peu de réactivité serait bienvenue!

Bonjour

Deux possibilités s'offrent à vous :

1. Ajouter un user-agent propre à vos requêtes
2. Accepter le cookie et suivre la redirection 302

Bruno B.

Merci pour votre réponse @BrunoB-OVHCloud

Nous avons ajouté un haeder user-agent pour les futurs versions de notre outil, c'est chose faite.

Pour nos utilisateurs existant par contre et c'est là tout le problème cela n'est pas possible puisque leur version n'est pas à jour et ne peut pas se mettre à jour car la connexion à notre serveur échoue avec une erreur 403.

Vous m'indiquer d'accepter le cookie et de suivre la redirection 302. Ce n'est pas notre erreur, c'est celle de @Fritz2cat.
Nous, nous avons une erreur 403. Comment faire pour faire en sorte que cette erreur 403 disparaisse sans pouvoir toucher au client qui fait les appels sans ce header ? Une configuration est-elle faisable côté serveur ? Si oui, où et que doit-on rajouter dans quel fichier de configuration ? Nous sommes sur un hébergement mutualisé Web Cloud.

Bonjour,

Des appels API rest typiquement, le user agent est une norme des navigateurs.

Alors non c'est une norme du protocole HTTP de manière générale et non du navigateur (RFC7231).

Cordialement, janus57

Bonjour à tous.
Idem sur plusieurs hébergements sur le cluster010.
Indexation sur Google en 403 avec 10 ans de travail perdu au niveau SEO et API PayPal qui retourne aussi un 403 donc les commandes ne sont pas validées.
Le support me revoie vers ce topic mais je doute que la communauté puisse corriger le problème. Un rollback doit être effectué et les firewalls doivent être configuré pour autoriser certaines requêtes sans user-agent.
Alexandre

J'ai eu une même réponse "état de fait", en palliatif j'ai déployé d'urgence cloudf**re en frontal et créé une règle pour ajouter un UA aux requêtes n'en disposant pas.




Mais ce n'est pas le type de changement que l'on fait normalement à l'improviste, ca a bien secoué ce matin (problemes de certificats, 302 loop etc, que j'ai corrigé au compte goutte. Mais la situation est en train de se rétablir. En espérant que OVH puisse considérer des palliatifs viables qui ne consistent pas à laisser pour mortes des centaines de milliers d'installations logicielles/matérielles. Le web a cet avantage de permettre des déploiements de correctifs quasi instantanés coté serveur, mais à la frontière IOT/Client lourd ce n'est plus si évident.

Merci @2f9e37cb726af0c38578 pour cette réponse. Vous avez installé Clou d fl are en frontal c'est ca ? C'est possible de faire cela sur un environnement mutualisé ?

Bonjour @AlexandreN19
Pouvez vous partager le hosting concerné ?
Google a bien des user-agent, je ne vois pas le cas, on a besoin d'input.
L'API Paypal c'est du trafic sortant ou les callback ? Car les callback on les voit bien avec user agent

Bruno B

Oui, il faut créer un compte chez cloud**are, il va importer toute la zone dns de votre domaine, puis dans la console OVH il faut changer le nameserver comme indiqué dans leur guide pour leur donner la main.

En gros première étape c'est donner la main sur les IPs à cloudfl*** pour qu'il puisse basculer entre proxy ou direct.

Dans un premier temps avant de faire la bascule nameservers assurez vous bien de mettre tous les domaines en "dns only" cela vous permettra de maîtriser le passage sous proxy de cloud**flare.

Une fois que le trafic dns arrive chez eux activer le mode proxy sur les domaines victimes du problème de UA et ajouter la petite règle que j'ai mis en capture d'écran.

TIP SUPER important : dans cloud***re configurer le mode HTTPS en full pour que le proxy appelle le site en HTTPs et pas en HTTP (ce qui peut créer des boucles de redirections.)

Ce n'est qu'une solution temporaire mais ca ma sauvé la mise, mais j'aimerai bien me passer de cette usine a gaz, je ne sais pas si OVH saura renouveler le certificat côté serveur le moment venu, ce qui m'inquiète.
Juste pour que je sois bien clair, ce qui permet de mettre la règle d'ajout d'un UA c'est bien le passage en proxy chez eux qui permet de manipuler les requêtes. En DNS only, cela ne marchera pas.

Note : Je ne cherche surtout pas à faire de la promotion, je partage juste une solution pour ce problème, il y en a probablement bien d'autres (vps avec reverse proxy etc ...), mais en urgence cloudfl**e est ressorti de mon expérience passée dans le web comme un palliatif rapide quand on n'a pas la main sur des 100aines de milliers de clients déployés en client lourd.

"Ce filtrage est situé bien en amont des serveurs web appliquant le firewall applicatif, il ne nous est pas possible de changer cela."

ok, dans ce cas supprimez ce filtre, diffusez largement l'information pour que les personnes concernées soient en mesure d'appliquer un correctif, puis remettez votre filtre....actuellement mes applications pourraient se mettre à jour automatiquement avec une version corrigée, mais vous ne leur laissez pas l'occasion de le faire.

Idem pour nous

c'est celle de @Fritz2cat.

Pardon ?

Même soucis que toi, une application en C# déployée depuis plus de 2 ans
un WebClient de base et dans l'impasse depuis hier
Le code ne peut être changé à distance et à part faire une mise à jour ( qui sera dans mon cas difficile à déployer ) je ne vois pas ce qui peut être fait depuis notre hébergement pour débloquer temporairement la version actuelle :(

Je parlais de ce message qui parle de 302 intempestif. Ce n'est pas ce que nous constatons chez nous. Chez nous on a des erreurs 403, pas des 302.

Je pense que que pour tous les cas remontés la liste des urls ou pattern d'urls est clairement identifiée/identifiable, pourquoi ne pas ouvrir un liste d'exclusions (IE : compte client), ce qui rendrait tout le monde heureux, trafic non souhaité rejeté en vaste majorité et rétrocompatibilité maintenue.

Les nouveaux usages sans user agent se tariraient avec une petite FAQ qui décrit l'ajout d'un User agent vivement recommandé. Comme la plupart des autres utilisateurs ici le passé ne peux pas être "défait", et ces requêtes existent et sont somme toute légitimes. Je pense que tous le monde souhaite aller de l'avant et prendre en compte cette nouvelle contrainte pour le futur, mais dans le présent cette nouvelle règle est extrêmement brutale.

A ce sujet, les règles ont changé, ou peut on consulter ces règles ?

Nous rencontrons le même problème depuis 24h : 15 logiciels sont fortement impactés : les clients ne sont plus averti des mises à jours et il ne reçoivent plus certains paramètres indispensables.
Avec des milliers d'exemplaires dans la nature et autant de clients, si la situation reste en l'état sans solution c'est une véritable catastrophe pour notre entreprise.
Je ne peux pas croire qu'OVH ne fasse rien pour régler de ce problème.

Bonjour @DominiqueC5
Même question qu'aux autres remontées, je serais preneur de vos détails.
Le usecase précis avec des infos tech et votre service concerné

Bruno B.

Hello à tous.
Il y a quelques années, je me suis retrouvé dans cette situation de mise à jour bloquée de notre application suite à une maintenance planifiée, mais anticipée de plusieurs semaines par OVH, sans préavis. Nous laissant dans la panade. Tous les échanges techniques n'avaient rien donné.
Il a fallu une lettre d'avocat, chiffrant le préjudice pour que miraculeusement OVH me rétablisse la situation en une journée.
AltiFab.

Bonjour,
Vous devez être très occupé pour ne pas lire vos messages in private en ce moment suite à cette mise à jour.
Je comprend votre démarche. Mais que faut-il faire si la technologie ClickOnce créé par Microsoft ne suit pas les RFC ? Donc avez-vous demandez à Microsoft de mettre à jour leur technologie avant de la Bloquer ?
Vous pensez qu'en agissant ainsi, vous allez faire surgir des utilisateurs une rébellion contre leurs fournisseurs ?
Nous ne sommes pas au pays des bisounours, et je serai certainement plus là lorsque cela se produira.
En attendant ce monde, il faut absolument résoudre le problème et ce quelque soit la manière !
Je fais ne nombreux tests pour intégrer le ClickOnce et de le lancer avec un UserAgent mais Niette. ClickOnce de Microsoft est propriétaire.
Si vous ne pouvez rien faire, laissez nous au moins la main sur nos firewall... On saura les paramétrer
Cordialement
Bruno, il faut vraiment agir là.
Je garde confiance...

Bonjour @DavidP62
J'ai bien répondu à votre dernier message privé.
Je vais vous repréciser certains points à la suite

--
Bruno B.

Une class action pour demander dédommagement à OVH peut être ?

Que faire pour corriger cela ? Aucune solution dans l'espace client ? changer d'hebergeur ? merci

Bonsoir @BrunoB-OVHCloud.
Hébergement concerné : crocoboa.cluster010.ovh.net
Google nous indique une erreur 403 sur la sitemap par exemple sur Google Search Console et c'est l'IPN de PayPal qui nous indique aussi une erreur 403 quand il appelle le script situé sur le serveur.
Alexandre

Bonsoir @BrunoB-OVHCloud,
J'équipe plusieurs clubs de sport de solution de suivi de leurs membres, matériel à base de Raspberry. Le public utilisateur n'est généralement pas à l'aise techniquement :/
Nicolas
Ps: question bête, comment on lance une conversation privée ?

usecase

Bonjour, faut rétablir le fonctionnement d'avant, plus rien ne fonctionne meme avec un webAgent, c'est hallucinant ce qu'ils ont fait...

Bonsoir @BrunoB-OVHCloud
Merci pour vos interventions qui nous donnent espoir de voir nos applications distribuées fonctionner à nouveau.

Pour ma part 2 cas de figures et les 2 seront bien résolus avec une future mise à jour mais le gros soucis est de **pouvoir déployer cette mise à jour et avertir les utilisateurs**.

les 2 cas sont bien liés dans mon cas par des requêtes refusées car il n'y a **pas de USER-AGENT de spécifié ou refusé**.
[EDIT]pas de USER-AGENT spécifié uniquement[EDIT]

**- premier cas**: une application client lourd développée en C# et installée sur Windows qui envoie des requêtes sur un serveur OVH mutualisé afin de récupérer des licences / droits d'accès pour les utilisateurs / informations sur les mises à jour.
Le développement utilisé depuis plus de 5 ans utilise du code intégré officiel Microsoft pour exécuter la requête ( WebClient ) comme cité plus haut par un autre utilisateur. Et après recherches ce jour le code de base n'ajoute pas de user-agent.
Les requêtes reviennent alors avec une erreur 403.
Impossible de mettre à jour des milliers de logiciels diffusés qui sont des clients lourds et installés manuellement par les utilisateurs .
Seul moyen pour débloquer tout le monde: diffuser des mailings à tous les utilisateurs et déployer une nouvelle version, mais en pratique diffuser une mise à jour n'est pas si simple ( tous les utilisateurs ne sont pas à l'aise avec ces dernières , une bonne partie doit également faire appel a des services informatiques externe, bref des couts financiers et de la perte de temps pour tous ).
Mais je confirme qu'un simple ajout d'un user-agent débloque bien la situation.
Mais il aurait été sympa d'avoir eu cette info de filtrage avant une mise en pratique d'OVH.
Cela nous aurait laissé le temps de préparer une mise à jour et de la déployer sans blocage instantanné de tous les utilisateurs !

**- deuxième cas**: des cartes électroniques ( objets connectés ) qui ont bien un user-agent mais non accepté ( il ne respecte certainement pas les règles d'un user agent valide ).
[EDIT]après vérif il était fixé avec une chaine vide donc pas de USER-AGENT[EDIT]
bilan: toutes les données envoyées sont refusées et l'url d'arrivée n'a pas le temps d'en voir la couleur.
Toutes les cartes doivent être reprogrammées manuellement. intervention chez le client, perte de temps , perte de suivi de production. un joli imprevu.
Alors oui, si je spécifie un user-agent accepté comme : Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko tout se débloque mais notre soucis est ce filtrage brutal et ce plantage immédiat de tous nos systèmes déployés. Nos clients ne comprennent pas ( nous non plus d'ailleurs ... )

Pour résumer, pas de user-agent ou ce dernier invalide et tous nos logiciels / cartes électroniques sont HS depuis le 05/11/2024 à 11H45

Nous espérons avoir une solution pour débloquer même temporairement tous nos utilisateurs le temps de déployer des mises à jour

En espérant vous avoir apporté quelques détails sur notre cas

Merci par avance

Une très grosse majorité du trafic passe ce challenge sans encombre.

Quand allez-vous vous rendre compte que c'est justement la minorité des échanges rejetés qui empêchent plusieurs sociétés de fonctionner. C'est sûr que la majorité des échanges sont entre site et navigateur mais les échanges entre applications clientes et API sont essentielles et n'ont pas forcément le User-Agent... et surtout sans notification de la part de l'hébergeur...
La mise en place d'un correctif peut prendre en effet quelques minutes mais si on ne peut déployer cela ne sert à rien...
Laissez vos clients sélectionner les requêtes à filtrer ou non aurait été beaucoup plus intelligent et plus professionnel que votre manière de faire aussi brutale au risque de mettre en péril des entreprises.

Bonjour à tous.

Même situation ici. Parc iOT en carafe depuis le 5/11/24.
Aucun message d’erreur remonté, aucune alerte, aucune communication… Merci pour ce beau moment d’absence ! Mise à jour à la main à faire en urgence. Depuis quand passe t-on ce genre de changement en prod sans au minimum prévenir l’utilisateur au préalable ? Bonjour les process chez vous… Tout cela aurait pu être anticipé et être fait sans aucun heurt avec un minimum de dialogue...

En plus d’un downtime minable sur l’offre hébergé j’envisage de plus en plus la concurrence!

Bonjour @BrunoB-OVHCloud,

J'avais posté un message hier qui n'est apparemment jamais arrivé :/ Pour précision, j'équipe des clubs de sport de solution de suivi des membres donc pas de spécialiste technique sur place.

J'ai cherché partout mais surement pas au bon endroit car je n'ai pas trouvé comment lancer une discussion en privée !

Nicolas

Bonjour,
Le premier cas est en cours de traitement chez nous, une solution arrive.
Pour le second cas, je suis preneur de plus d'infos (user-agent rejeté, service concerné, ...) afin que l'on regarde.

--
Bruno B

Merci pour votre retour
Ce serait une très bonne nouvelle
Pour les cartes électroniques, je viens de voir avec le service concerné et on vient de refaire des essais
Après analyse, il y a bien dans le code une fonction qui fixe le user-agent et le développeur avait fixé ce dernier via une variable ( en fixant le nom de la société lors de ses premiers tests).
Au final, il avait refixé la variable avec une chaine vide pour ne pas mettre n'importe quoi.
Donc pas de user-agent de fixé au final, désolé pour cette fausse info.
On vient de faire le test avec un user agent 'bidon' > nom de la société pour essai et la carte émet bien normalement
Sans User Agent elle est bloquée
@BrunoB-OVHCloud Si besoin de vérifier sur notre compte, comment vous envoyer les infos en MP ?
Désolé je n'ai pas trouvé

Merci encore pour votre implication

Cela veut il dire que les requêtes sans user-agent type IOT, api etc .. vont de nouveau pouvoir passer sans 403 ? Ce serait un soulagement. Un délai de résolution du problème peut être ?

je ne comprend pas comment vous pouvez justifier de mettre vos clients dans la mouise alors qu'il suffirait pas exemple de virer ce filtre pendant 1 semaine en indiquant que vous le remettez en place dans 1 semaine...ça ne répond pas à tous les problèmes mais ça permet de débloquer tous ceux qui sont en capacité de déployer des mises à jour via cette requête HTTP justement.

Bonjour à tous,

Tout d'abord merci pour vos feedbacks et les infos détaillées envoyées ici ou en privé.
Cela nous a permis de comprendre certains cas d'usage précis qui utilisent des applicatifs avec un user-agent absent.
Nous gardons notre volonté de challenger ce trafic car la mesure est efficace mais nous prenons en compte les remontées et nous travaillons à l'application d'une solution pour vous aider à évoluer en douceur.
En conséquence, nous allons permettre de whitelister vos domaines utilisés par un trafic légitime et suspendre le challenge pour ce cas précis.
Bien entendu en cas d'abus et de trafic illégitime qui passerait par ce biais, nous nous réservons la possibilité de suspendre la blacklist pour les domaines concernés.

Dans un premier temps cette autorisation devra passer par une demande au support, je vous invites donc à vous assurer qu'un ticket est ouvert auprès de notre support et que celui-ci contient la liste des domaines appelés.
Ce changement est actuellement en cours de validation et sera progressivement déployé dans les heures qui viennent. L'ajout des domaines à la whitelist se fera progressivement au fur et à mesure du traitement des tickets support et du déploiement sur les différents clusters.
Vous pouvez d'ores et déjà nous communiquer ici l'ID support afin qu'on les prenne en compte le plus efficacement possible.
Merci pour votre compréhension.

--
Bruno B.

C'est ce que BrunoB a expliqué : un whitelistage temporaire va être appliqué. Pour bien faire il faudrait que cela soit définitif (pour ceux qui le souhaite bien sûr) ou de durée suffisante. Je pense qu'une semaine est très insuffisant pour la plupart d'entre nous. Dans notre cas cela nécessitera au moins 6 mois pour permettre à tous les utilisateurs d'effectuer la mise à jour (non automatique et déclanché par les utilisateurs) et pouvoir purger 90 % du stock.

Super !
dans ce cas pour mon ticket CS10351013, je veux bien que mon sous domaine weather.daspower.fr soit mit en whitelist. ( ou tout le domaine daspower.fr sinon peut importe )

Bruno,
Merci, pour nous le ticket a la référence CS10373635

CS10372262 Merci pour votre action et compréhension !

Merci pour cette solution de déblocage.
Mon ticket pour mon domaine prioritaire : CS10387435
Merci par avance

J'ai déjà ajouter mon mot sur un sujet similaire concernant le filtrage de user-agents qui n'est en aucun cas quelque chose de valide en terme de sécurité - cependant mon message n'a pas encore été validé par les modérateurs -: https://community.ovhcloud.com/community/fr/http-302-sans-ssl-set-cookie-ovh-challenge-cookie?id=community_question&sys_id=0af1d64664bd56902d4ce3bfb13fb781">https://community.ovhcloud.com/community/fr/http-302-sans-ssl-set-cookie-ovh-challenge-cookie?id=community_question&sys_id=0af1d64664bd56902d4ce3bfb13fb781

De mon côté j'ai un tunnel de vente fournit par un service en ligne (qui n'ajoute pas de UA à ses requêtes) qui communique avec une API que j'hoste chez OVH. Depuis deux jours mon business est donc inactif, je rejoins l'idée du dédommagement si rien n'est fait au plus vite de la part d'OVH. On ne peut pas se permettre de redéfinir les standards web sur un coup de tête, même lorsque l'on s'appelle OVH.

CS10389442 - Merci d'avance.

CS10390048 - Merci à vous

CS10373362 Merci

CS10379361 merci pour votre réactivité

Bonjour,

Merci d'avance :

CS10391489

Je ne vous réponds pas à chacun mais nous traitons à la volée et la réponse est apportée dans les tickets.
A date tout ce qui est antérieur à ce message a été traité.

Bruno B.

Bonjour,
Merci pour avoir redonner l'accès à nouveau en whiteliste, j'imagine.
@BrunoB-OVHCloud
j'approuve la solution choisie en ce qui me concerne pour une application Microsoft ClickOnce :
-Via un lien, cela fonctionne (donc via navigateur etc..) ++
-en directe, erreur 404 : vous êtes en Hamont de la sécurité que j'avais mis en place sur mon site. Donc plus besoin de sécurité au niveau de mon site ;) ++ ? (Je garde tout de même la sécurité mise en place au niveau client)
Le résultat de cette semaine a été constructif grâce à votre réactivité Bruno.
Vous avez également compris que Microsoft n'est pas forcément près à appliquer les RFC (En tous cas sur la Technologie ClickOnce). Donc nous sommes dans un compromis dont vous avez compris.
Vous tenez le bon chemin, si vous n'oubliez personne sur le bord de la route...
Je n'aime pas dire courage, mais là, ...
==>MERCI

Voilà pour moi : CS10393616 :)
Merci d'avance

CS10388282 Merci d'avance.

CS10379356 - Merci

nous

CS10373632 Merci pour votre action et compréhension

CS10379356 - Merci d'avance

Bonjour,
J'ai créé un ticket aussi : (CS10395836)

Notre logiciel permet d'ajouter des flux RSS sur la page d'accueil. Ce qui nous permet de communiquer seulement avec nos clients Français.
J'ai demandé à notre équipe de développement d'ajouter des User Agent à la requête ou de permettre la redirection et l'enregistrement de cookies.
Heureusement la prochaine mise à jour est prévue pour la fin de l'année.

Merci d'avance : CS10396357

Voici notre numéro de ticket CS10391525 . Merci

Et voila le mien CS10390131
merci

A ce propos, veuillez SVP ajouter mon domain claudiou.fr
TRES URGENTE
Merci

Bonjour,

De nouveau je vous remercie pour vos feedbacks.

Grace à vos remontées, et aux échanges privilégiés que l'on a eu avec certains d'entre vous, nous avons analysé vos usages en profondeur en partant du trafic de vos domaines.
Cela nous a permis d'adapter nos systèmes de détection et nous venons de terminer le déploiement d'une nouvelle version ne nécessitant pas de whitelist.

Il est donc désormais inutile d'effectuer des demandes de whitelist.

Merci à tous pour votre aide et votre compréhension

--
Bruno B.

Bonjour
Ticket num:CS10372090
Merci de débloquer legieinfo.fr
C'est URGENT, merci d'avance

URGENT AUSSI svp ticket CS10396367 blocage sur des appels API
domaine boutique-outilor.com

Bonjour,
Pour ma part mon prestataire me remonte bien qu'ils utilisent un user-agent, le user-agent en question est : "Vaisonet e-connecteur."
Mais nous avons quand même un blocage.
Pouvez-vous m'aider svp ?
Ticket : CS10396367
Merci beaucoup.

Encore merci @BrunoB-OVHCloud
Votre intervention a clairement fait évoluer les choses en étant à notre écoute
Pour ma part tout est désormais OK
Logiciel C# et objets IOT

Je comprends cette envie d arrêter les programmes (prog)d'envoyer du spam si pas de recaptcha, les prog qui essaient de pirater les sites, ces prog qui cherche les clés de cos API...
Selon moi, votre solution de bloquer le user agents n empêchera rien de tout celà. Ces programmes malveillant ont déjà depuis des années intégré un User agent.
Donc une forme de double validation des requêtes API ne sert strictement à rien car les programmes malveillant auront juste à valider cette broutille de validation pour faire ce qu'ils ont à faire.
Chacun adapte la sécurité à son niveau, il y a des subtilités qui peuvent être mis en œuvre pour que celà fonctionne (IP, certificat ,paramètres, nom,date, lieux... Pensée humaine...)
C est certainement pour celà que des sociétés mondialement connue ne prennent pas au sérieux certaines normes (comme RFC indiqué plus haut) et préfère donc appliquer leurs propres normes que le "monde" doit suivre... Mettons une grosse réflexion la dessus...
@ovh : lorsque vous peserez plus lourd que ceux qui dictent les règles, vous pourrez à ce moment là dicter les vôtres. En attendant, suivez celles de vos pères et adaptez vous.

Bonjour, j'ai un problème avec mon application ClickOnce aussi, j'avais une erreur 403, mais maintenant ça m'indique "Impossible de mettre cette application en ligne car la version précédente est installée. Pour installer cette application, désinstallez tout d'abord la version précédente ou marquez l'application comme étant installée." (hors ce n'est pas le cas).
Je n'arrive pas à savoir si le problème est encore lié au User-Agent, si oui comment faire pour whitelist ?

Merci.

Bonjour SimonC18,
Aucun rapport avec l'erreur 403...
Pour supprimer totalement l'application Clickonce,
>suppression/ajout de programmes comme vous l'avez fait à priori.
>Si cela ne fonctionne pas, pensez à supprimer les dossiers dans
C:\Users\"nom de votre user"\AppData\Local\Apps\2.0
lien rapide dans l'explorateur
%appdata%\..\Local\Apps\2.0
!! supprimez tout si vous n'avez aucunes applications ClickOnce autres installées.
==>Sinon supprimer uniquement le dossier qui concerne l'application.
C'est comme cela que je fait si je ne veux pas mettre en action un nouvelle version.

Puis forcément, réinstallez votre application via le lien que vous avez : https ou réseau...

Correction du lien rapide
%appdata%\..\Local\Apps\2.0

Bon, le forum ne permet pas pas de mettre un antislash après
%appdata%mettre anti slash ici