Configuration push pour freemobile

Bonjour Maxime pour un push sms free il manque la possibilité de 1 caractère dans user et pass
j’ai fais multiples essais avec l’ensemble dans url mais ne marche pas
je mets en pièce jointe un exemple merci de dire ou est l’erreur
cdt

+1
Je valide aussi le problème décrit par didierm: Il me manque aussi 1 caractère pour inscrire complètement les user et pass
est ce que cela sera suffisant pour utiliser la fonctionnalité ( Push sms Free ) en natif ?
Bonne journée à tous
Mario

Bonjour,

Après étude du problème, la cause est visible dans la première pièce jointe.

On y voit que l’API de free réclame l’exécution d’un javascript sur la V4. Hors, comme on peut d’ailleurs le deviner dans cette même communication, ce genre de chose est généralement plutôt l’affaire des navigateurs ou autres serveurs en ligne… Nous allons voir s’il est possible pour nous de l’intégrer mais cela me parait très compliqué.

Pour information, j’ai également joint la configuration utilisée. Comme indiqué précédemment, le user et le mdp font partie de l’API et doivent donc être dans la partie URL qui accepte 220 caractères…

Pour solutionner, je vous invite donc à utiliser Notifix pour le moment.

Bonjour Maxime, pour information la ligne est https://
cela serait un plus d’avoir le service en natif sur la V4
car je crois que Notifix ne peut pas non plus gérer le https://
cdt

Bonjour,

La V4 envoi des commandes en HTTPS (GET, POST) mais la compatibilité n’est pas complète… Ça marche avec gmail par exemple mais ce n’est pas le cas de tous. Nous ne pouvons pas intégrer tous les encryptages sur la V4, c’est impossible en terme de ressource. De même, il est impossible (ou presque) de mettre la V4 en HTTPS elle même. Cela voudrait dire qu’il faudrait un certificat unique pour chaque carte, cela ferait exploser le coup de nos produits… D’ailleurs, il y a très très peut de serveur web embarqué (et non externe à la carte) qui offre ce genre de services.

Notifix fonctionne en HTTPS dans les deux sens et dispose de la plupart des encryptage existant mais les certificats ne sont pas officiel c’est tout.

En ce qui concerne Free, le problème premier est cette histoire de cookie. Dans un second temps, je ne suis pas sur de la compatibilité en terme d’encryptage mais de toute façon la question ne se pose pas.

La sécurité est un axe de progression intéressante mais extrêmement coûteux en terme de R&D comme en terme de ressources. On y viendra mais ce n’est pas encore d’actualité. Nous y travaillons déjà mais ça ne sera pas effectif tout de suite.

epuis quelques mois, la société Let’s Encrypt propose des certificats SSL gratuit :wink:
Le seul inconvénient c’est qu’ils ont une durée de vie de 90 jours et du coup il faut automatiser leur renouvellement.
Je conseille fortement de regarder du côté du certbot de la EFF afin de faciliter son intégration/déploiement.

ntégrer HTTPs pourrait être un avantage commercial du coup :wink:

(Si vous n’avez pas assez de ressources pour ajouter cette fonctionnalité, je peux éventuellement aider)

Bonjour,

Le déploiement d’un certificat sur un serveur n’est pas comparable à un déploiement sur des dizaines de milliers de produits. Les couts sont monstrueux ! Sans compter que Google change ses méthodes de cryptage très souvent et qu’il faudrait recommencer à chaque fois.

L’ipx800 dispose d’ un cryptage TLS 1.0 sur les pushs et je pense que nous sommes les seuls à le proposer sur un automate à moins de 250€ TTC
On travaille sur l’implantation du tls 1.2 et même si je comprend votre souhait il faut admettre que ce n’est pas pour demain. Ce genre de développement est très long et très coûteux.

On essai d’améliorer nos produits tout en maintenant un prix abordable, je dois faire attention que le cout d’un développement soit justifié et n’impacte pas trop sur les prix de ventes.

CDT

e quels coûts parlez vous ? Des coûts de R&D ? Si c’est le cas je peux aider :wink:

e ne comprends pas ce que Google à avoir la dedans. Pourriez-vous m’expliquer ?

à, vous parlez de l’IPX en tant que client (ie. celui qui émet les requêtes HTTP). Moi je parle d’ajouter un certificat au server web de l’IPX afin que ce dernier soit accessible par nos navigateurs sur du HTTPS.

e ne connais pas vos contraintes de développement/ressources, mais TLS 1.2 date d’Août 2008 et il y a une bonne dizaine de libraries qui l’implémente (OpenSSL et son fork récent LibreSSL étant les plus populaires).
J’espère que vous n’implémentez pas vous même TLS :open_mouth:

Bonjour,

Les coûts de développement sont les salaires des ingénieurs et en France les charges sont conséquentes ! Donc ça grimpe très vite.
Je vous remercie pour votre aide mais nous ne partageons pas les codes sources pour des raisons évidentes de sécurité et de copyright.

Google c’est Gmail, pour pouvoir utiliser leurs services smtp, google change régulièrement les méthodes de cryptologie ! C’est pour cette raison qu’on travaille sur l’implantation coté client !

Une IPX800 en tant que serveur HTTPS est déjà possible techniquement. Le soucis c’est le déploiement et l’implantation des certificats !
ça viendra surement mais pas tout de suite car il y a pas mal de choses à valider et on à déjà pas mal de truc sur le grill !

Nous n’utilisons pas des librairies qu’on trouve sur internet… Dailleurs les librairies que vous citez ne sont pas compatibles avec notre hardware et encore moins avec notre OS…
Enfin on implante tout nous même. Cela permet d’avoir une grande stabilité, une liberté totale sur le code et pas de licence commerciale à payer.

Pour en revenir au sujet initial les pushs vers Free ne sont pas liés à un problème de cryptage mais à l’API de free que l’IPX800 ne sais pas encore gérer.

Cdt

k, vous parliez donc d’implémenter TLS côté client. Merci pour l’éclaircissement.

e comprends tout à fait et loin de moi de demander à ce que cela soit mis en place ASAP.
Je souhaitais simplement rebondir sur l’argument du coût des certificats SSL évoqué par Maxime, qui sont maintenant gratuits.

trange comme remarque, étant donné que votre IHM est basée sur freeboard, que vous utilisez knockout.js pour gérer les bindings, justgage pour les jauges, raphael pour les graphiques, jQuery pour manipuler le DOM, etc…
Mais bon, j’imagine que vous voulez dire que vous n’utilisez pas de librairie trouvées sur le net pour votre firmware :wink:

a, par contre, je le comprend tout à fait :wink:

l existe plein de licenses de logiciel open source qui permettent l’utilisation du code à usage commercial (MIT par exemple).

e vous souhaite bien du courage d’implémenter TLS par vous même.
Personnellement, je ne m’y attellerais pas.
C’est un travail titanesque pour le faire correctement (ie. fiable).
Rien qu’à voir le nombre de CVEs qu’à la librairie la plus populaire (238 CVE pour OpenSSL) mon coeur saigne un petit peu :wink:

1 « J'aime »

Bonjour,
V4 en 4.00.29 et le sms Free n’est malheureusement toujours pas d’actualité.

Avez-vous prévu la possibilité d’utiliser ce service dans une prochaine maj ?

Bonjour,

C’est possible en passant par notifix.

Cdt

Bonjour,
C’est ce que j’avais cru comprendre mais j’espérai que l’IPX800 pouvait désormais le faire sans avoir besoin d’un site extérieur (ce qui est très dommage pour un système dont le principal atout est d’être cloudless).

(j’avais demandé un accès à Notifix il y a 2 ou 3 jours mais mon compte n’a toujours pas été activé, ça prend longtemps ?)

Bonjour,

Tous le monde est en vacances mais je vais voir si je peux vous activer votre compte.
L’API de free est curieusement " tres particulière " ce qui explique pourquoi on ne l’a pas intégré…on ne veux pas sacrifier les ressources de l’ipx800 pour Free !

De plus Il faut comprendre que le cloudless à ses limites et qu’on ne peux pas intégrer toute les solutions qui existent.

Cdt

Bonjour,

j’ai besoin également de cette fonctionnalité…

Ce qui m’étonne, c’est que cela fonctionne également depuis un simple terminal avec wget ou curl (sous linux) et pas que depuis un navigateur…
donc, le JavaScript de l’API Free est complètement hors de cause dans ce cas…

wget --no-check-certificate « https://smsapi.free-mobile.fr/sendmsg?user=xxxxxx&pass=xxxxxxxxxxxxxxxx&msg=Alarme_Intrusion_Maison »

ou encore mieux :

curl « https://smsapi.free-mobile.fr/sendmsg?user=xxxxxx&pass=xxxxxxxxxxxxxx&msg=Alarme_Intrusion_Maison »

Ne serait t-il possible de implémenter une telle commande de cette façon lors d’un événement ?

Alain

Bonjour,

En effet la procédure est assez simple en dehors de la gestion du HTTPS. Le soucis étant que nous ne pouvons pas actuellement intégrer le TLS. Si nous avions une carte qui intégrerait des librairies comme wget ou curl ce serait en effet très simple mais aussi probablement plus chère, moins stable et moins réactif.

Nous travaillons toujours sur la possibilité d’intégrer le TLS dans une future MAJ de V4 en espérant qu’elle en est la capacité (cette fonctionnalité étant très lourde) mais cela prendra dans tous les cas un certain temps.

Bonjour,
@Biocef
quoi qu’il en soit l’IPX aura besoin d’une API Free externe pour lancer des SMS.
Que cette API soit appelée chez Free par l’IPX directement ou via Notifix ne change rien au problème, le cloudless dans ce cas est impossible, la dépendance est incontournable
(sauf aujourd’hui avec le module X-GSM)

Pour ma part, j’ai créé des scripts PHP sur mon NAS ( Ils sont joignables en http :slight_smile: ).
Les scripts sont appelés par les Push de l’IPX v3, cela fonctionne depuis plus de 2 ans, sans faire appel à Notifix (je limite donc les dépendances).

Cela dit, Notifix reste une solution pour ceux qui n’ont pas de serveur à domicile.

Cdlt

Pour ceux que ça intéresse,
voici la fonction Php faisant appel à l’API free.
J’ajoute un horodatage systématiquement à la fin du message.

smsFreeMobile.php :

<?php
  function sms($titre, $message) {
    $donees = array(
      'action' => 'envoyer',
      'user' => '12345678',   //Remplacer par votre identifiant Mobile Free
      'pass' => 'XxxXxxXxxX', //Remplacer par votre mot de passe API
      'msg' => utf8_encode($message)
    );
 
    $envoi = stream_context_create(array(
      'http' => array(
        'method'  => 'POST',
        'header'  => "Content-type: application/x-www-form-urlencodedrn",
      ),
    ));
  
    $response = file_get_contents("https://smsapi.free-mobile.fr/sendmsg?user=" . $donees['user'] . "&pass=" . $donees['pass'] . "&msg=" . utf8_encode($titre) . "%0a%0d" . $donees['msg'] . "%0A%0DNotification%20generee%20le%20" . utf8_encode(date("d/m/y-H.i.s")) . "", false, $envoi);
}   

//récupération des parametres passés dans l'URL
parse_str($_SERVER['QUERY_STRING']);

$r = sms($titre, $message);
?>

Pour appeler la fonction, voici un exemple :

http://IP_SERVEUR/smsFreeMobile.php?titre=DANGER&message=Ceci%20est%20un%20test

Cdlt

edit : Merci @ZogStriP pour la mise en forme. :wink:

2 « J'aime »

Bonjour,
Merci à tous pour votre participation à ce sujet.
Mon intervention n’a qu’un faible rapport avec celui-ci, mais j’ai perdu beaucoup de temps pour trouver la raison pour laquelle certains push ne fonctionnaient pas, à savoir : dans le corps du message IL NE FAUT PAS METTRE DE CARACTERES ACCENTUES.
Je ne sais pas si cette limitation vient de Free ou de Notifix, mais ce n’est pas grave, on fait avec :slight_smile:
Bonne journée.

1 « J'aime »

Bonjour,
les URL sont toujours encodées avec les caractères imprimables du jeu US-ASCII
Les navigateurs le font systématiquement, même si l’utilisateur ne le voit pas.
C’est pour cela que dans votre exemple le caractère « espace » est remplacé par %20 (32 en hexa)

A priori j’en conclue que l’IPX ne fait pas l’encodage, il faut donc encoder au préalable.

Si vous avez besoin d’encoder une URL, il existe des outils en ligne.
Par contre, dans le cas des push, certains appareils peuvent avoir des problèmes à afficher les caractères accentués. Ils les remplaceront en général par des points d’interrogation.
cdt

2 « J'aime »