Accès refusé à mon cloud depuis mon NAS

[Ryry]

Hello @calande 

---

Je me demande d'ailleurs ce que fiche SFR dans cette liste de spécialistes du stockage en ligne...

---

J'avoue qu'au fond, je me pose la même question : mais que fait donc ce choix "SFR" dans la liste des propositions Qnap... Alors que SFR n'a jamais publié d'API pour que son Cloud soit utilisé de cette façon.

---

c'est QNAP qui aurait dû corriger les données qu'ils utilisent pour accéder à l'API d'SFR Cloud. Quoi qu'il en soit, j'imagine qu'à une époque ça fonctionnait, et le fait que SFR modifie son API ou empêche carrément à ses clients d'accéder à leur cloud du jour au lendemain en utilisant l'API, c'est vraiment problématique pour ceux qui comptaient sur ce service pour faire leurs sauvegardes. [...] Et je doute que Google ne ferme du jour au lendemain l'accès à son cloud par l'API (contrairement à SFR)

---

Oui, en l'occurrence c'est Qnap qui devrai "se corriger".

Et que ce que Qnap propose ait fonctionné un jour, je l'espère, mais on n'en sait rien.

En revanche, je ne suis pas d'accord avec ta suite et ta conclusion

• à ma connaissance SFR n'a jamais publié d'API pour accéder à son cloud
• et SFR n'a jamais non plus proposé ou laissé entendre qu'on pouvait sauvegarder sur le cloud de SFR autrement que via leur propre outillage

(donc situation bien différente que la comparaison que tu as faite avec Google qui eux proposent une API et invitent des outils tiers à écrire sur leur cloud... et qui donc "piégeraient" effectivement des utilisateurs si du jour au lendemain Google stoppait ou bloquait cette API).

---

je suis extrêmement déçu, c'est la douche froide... [...] Mais j'en ai plus que marre des limites techniques artificiellement imposées par SFR... [...] Uniquement furieux contre l'entreprise SFR qui vend des services sans donner tous les détails, et ensuite quand on a commencé à payer et à utiliser les services, c'est la douche froide (ligne téléphonique avec accès difficile aux identifiants SIP, cloud sans accès à l'API, réseau mobile inaccessible à la campagne, etc...). 

---

Tout en étant éventuellement déçu par les mêmes choses, j'avoue ne pas partager ton avis :

Réseau mobile inaccessible à la compagne : oui, il ne faut pas généraliser à "partout en campagne" non plus, mais certes, le réseau de SFR a une moins bonne couverture que celui de Orange qui reste 1er. Cependant c'est loin d'être catastrophique selon toutes les études qu'on lit à droite et à gauche... Et on trouve des zones blanches (ou de très mauvaises réceptions) diversement réparties chez à peu près tous les opérateurs. Mais pour ma part, je ne peux pas dire que ma ligne SFR m'ait posé beaucoup plus de problèmes que mes camarades de vadrouilles, vacances, randonnées, chez d'autres opérateurs.

Identifiants SIP : cela fait longtemps que SFR a dit qu'il ne voulait plus promouvoir de genre d'utilisation (le service Libertytalk permettait par le passé notamment d'exploiter le protocole SIP et SFR a annoncé le fermer en janvier 2017, soit il y a déjà plus de 7 ans). Cela fait donc bien longtemps que SFR ne fait aucunement miroiter la possibilité d'exploiter SIP. Et je dirai même que c'est une "chance" que tu aies réussi à le faire quand même. Il y a des opérateurs où ça n'a jamais été possible, et où tu peux toujours essayer de trouver une solution pour le faire quand même (par exemple sur le réseau coaxial Numericable que j'utilise depuis plus de 18 ans où manifestement il n'y a jamais eu de communication du comment y faire du SIP, et que jusqu'à présent je n'ai trouvé que des gens que se sont cassé les dents sur l'interconnexion avec MGCP pour la téléphonie). Pourtant j'aurais aimé.

Protocoles standard d'accès à SFR cloud : là aussi, je regrette qu'il n'y en ait pas car c'est plutôt ma façon de fonctionner (j'évite Windows, les applis dédiées, et préfère de loin un protocole connu, libre et éprouvé). Mais je suis conscient aussi que SFR ne m'a jamais vendu son cloud comme étant accessible via ces protocoles standards. Il ne correspond pas à mon usage, je ne l'utilise pas (d'ailleurs je n'utilise mon Drive Google qu'à peine plus, peut-être 3 ou 4 documents partagés dessus, tellement là-aussi ça ne m'intéresse pas et ne convient pas à mon usage puisqu'il utilise son protocole propriétaire et que ça ne me va pas). À ma connaissance, pas de protocoles standards non plus pour accéder au drive d'Orange.

---

Concernant la rétroingénierie, QNAP pourrait ne pas se lancer dans "ce petit jeu-là" comme tu dit, mais peut-être que précédemment c'est ce qu'ils avaient fait (ou bien SFR avait peut-être rendu disponibles les infos de son API, je ne sais pas)

---

Pour une API cloud de SFR documentée ou publiée, comme dit précédemment, je doute franchement que ça ait un jour existé puisque depuis des années je n'ai vu que des mentions qu'elle n'existait pas (comme par exemple ICI il y a plus de 4 ans).

Donc oui, s'ils ont réussi à le faire, Qnap aura sans doute fait quelques efforts particuliers. En l'occurrence, à leur place et pour un marché aussi "petit" que le SFR cloud "franco-français", on peut aussi imaginer qu'ils n'aient fait qu'automatiser des opérations via l'interface web (c'est en tous cas comme ça que je le ferais si je voulais me fatiguer au minimum) :

• c'est facile à faire (je t'avoue même que je me suis tâté de le réaliser il y a quelques années, en guise d'exercice via le procédé FUSE).
• ça marcherait bien (en gros ça revient à faire tout ce que ferait un humain par l'interface web, sans utiliser d'interface web bien sûr)
• mais ça casserait et serait à refaire au moindre changement non marginal de cette interface web (donc risqué, mais risque mesuré quand on voit que l'interface web de Google Drive a à peine bougé depuis de très très très très très nombreuses années, restant donc dans ces changements marginaux).

à+

[calande]

@jnq35 : Oui, j'ai fait ça ce matin,  je n'ai pas encore eu de retour de leur part (ils sont de Taïwan, donc c'est le soir maintenant)... J'espère qu'un développeur de QNAP lira le message que je leur ai envoyé. Il faut qu'ils suppriment cette option de leur liste de prestataires de clouds.

[calande]

@Ryry 

OK, j'ai lu ton message... Globalement d'accord.

SFR n'a jamais non plus proposé ou laissé entendre qu'on pouvait sauvegarder sur le cloud de SFR autrement que via leur propre outillage

---

C'est vrai... Mais pour moi, c'était implicite... Je pensais vraiment pas que c'était bridé. C'est comme si je souscrivais à une formule d'hébergement web, et je découvre que je ne peux pas utiliser mes propres outils pour accéder au serveur de fichiers (WinSCP, FileZilla, MountainDuck, WS_FTP, WebDrive, etc...) parce que l'hébergeur aurait décidé de bannir de son réseau les protocoles FTP, SFTP, FTPS, SSH, et aurait préféré qu'on utilise ses propres logiciels "maison" et une interface web de gestion des fichiers. Ça aurait de quoi surprendre...

[Ryry]

Bonjour @calande 

---

C'est vrai... Mais pour moi, c'était implicite... 

---

Je peux le comprendre... quoique étant conscient que de plus en plus de fournisseurs (et je ne parles pas que de SFR ou Orange, mais j'inclue les "gros" comme Google ou Microsoft) ne reposent plus que sur des protocoles propriétaires, ça fait longtemps que je me méfie.

---

Je pensais vraiment pas que c'était bridé. C'est comme si je souscrivais à une formule d'hébergement web, et je découvre que je ne peux pas utiliser mes propres outils pour accéder au serveur de fichiers (WinSCP, FileZilla, MountainDuck, WS_FTP, WebDrive, etc...) parce que l'hébergeur aurait décidé de bannir de son réseau les protocoles FTP, SFTP, FTPS, SSH, et aurait préféré qu'on utilise ses propres logiciels "maison" et une interface web de gestion des fichiers.

---

Disons que même Google Drive ou Microsoft OneDrive, ou Dropbox et tous les autres commerciaux colleraient aussi à cette critique que tu écris là.

• Si ce n'est que bon nombre d'entres-eux proposent quand même une API "maison" pour utiliser leur protocole tout à fait propriétaire (bref en gros c'est "je ne fais pas comme tout le monde, mais si vous voulez de moi, vous pouvez adapter vos logiciels" (ce qui ne me plait pas à moi comme je te le répondais).
• Effort de proposition d'API pour son cloud grand public que SFR ne fait (d'ailleurs vu que Orange ne propose pas webdav non plus sur son cloud grand public, je me demande bien s'ils divulguent une API).
  
  • À vrai dire, j'avoue qu'à leur place j'hésiterai aussi à divulguer mon API car il faut avoir vraiment les reins solides pour être sûr qu'elle résistera aux attaques et usages erronés que feront alors les milliers d'instances "non maison" de logiciels cherchant à y accéder.
  • pour un "petit" franco-français (face aux gros comme les autres que j'ai cités) à mon sens, la solution la moins risquée c'est de s'interfacer (en interne) avec des protocoles standards éprouvés qu'ils présenteraient en externe : webdav étant à l'heure actuelle celui à prendre en considération en premier.

Au fond de moi j'ai un secret espoir que, justement, un jour ce protocole (ou un autre de la liste des standards) soit rendu disponible en effet sur SFR Cloud... Mais franchement, c'est très très très optimiste j'en suis conscient !

À+

[calande]

C'est clair... Ça me fait penser à mes demandes répétées à l'ISP Free pour qu'il installe un certificat SSL sur les pages perso Free car depuis quelques années, les navigateurs, soit affichent un message d'alerte de sécurité quand on accède à une page perso Free à cause du protocole http non sécurisé, voire parfois bloquent carrément l'accès à l'utilisateur. Des années que ça dure... Les webmasters ont dû quitter les pages perso Free car leurs sites commençaient à avoir des toiles d'araignées.

Avec SFR Cloud, c'est pareil à mon avis, je n'imagine pas que ça change, ils n'auraient pas grand chose à y gagner. Le protocole de connexion au cloud va rester fermé. Ne retenons pas notre souffle 🌬️