Rafraichir la page parente à la fermeture de la page fille

Derrière ce titre alambiqué se cache un besoin particulier que j’ai cherché (et réussi) à résoudre dernièrement. La situation est la suivante : un utilisateur arrive sur une page, celle-ci effectue un appel ajax afin de connaître l’état d’un paramètre utilisateur. Pour illustrer, nous dirons donc que la page interroge une api pour répondre à la question : l’utilisateur a-t-il une image de profil enregistrée ?

Si l’utilisateur possède une image enregistrée, on la lui affiche ainsi qu’un message pour lui permettre de la supprimer. Si aucune image n’est présente, l’utilisateur peut choisir d’en ajouter une. L’acquisition de l’image s’effectue dans une page dédiée, que nous appellerons la page fille. Cette acquisition est réalisée à l’aide de la bibliothèque Cropper.js.

Une fois l’image acquise, l’utilisateur valide la sélection via un bouton. Au niveau de la page fille, un appel est donc réalisé vers une api pour sauvegarder l’image. Si l’appel est une réussite, nous fermons la page fille. À ce stade, l’utilisateur se retrouve sur la page parente qui lui propose toujours d’ajouter une image, ce qu’il vient de faire, nous allons donc recharger la page parente à la fermeture de la page fille.

J’illustre ce processus dans le code HTML en fin de page. Lorsque la page parente est chargée, celle-ci affiche en alert(), le message « Page chargée ! » afin de matérialiser le rechargement de la page. En cliquant sur le lien, une nouvelle page s’ouvre. Lorsqu’on clique sur le bouton de cette page, on va déclencher la fermeture de la page courante (la page fille) et le rechargement de la page parente. De plus, afin de matérialiser l’action de la page fille dans la page parente, de rendre l’exemple plus intéressant et de matérialiser ce qui correspondrait dans mon cas pratique à la mise à jour de l’information par le premier appel ajax (celui sur la page parente), le texte saisi dans le formulaire sur la page fille est transféré à la page parente et affiché par un alert().

Par ailleurs, le test du booléen pageFille.fermeture dans la fonction de l’événement unload de la page fille permet de s’assurer que la page parente ne sera rechargée que si le traitement est réussi sur la page fille où window.fermeture vaudra alors true. En effet, si on enlève le test du booléen, on constate qu’un événement unload a lieux dès l’ouverture de la page fille, ce qui aurait donc pour effet de recharger immédiatement la page parente. Le test du booléen permet de palier à ce « problème ».

Page Parente (pageParente.html)

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
  </head>
  <body>
    <p>
      <a href="javascript:ouvrirPageFille();">cliquez ici</a>
    </p>

    <script>
      function ouvrirPageFille() {
        var pageFille = window.open('pageFille.html', 'Titre', 'top=42,left=42,height=800,width=600,scrollbars=yes,status=no,toolbar=yes');
        //Recharge la page parente à la fermeture de la page fille 
        pageFille.onunload = function() {
          if(pageFille.fermeture) {
            alert(pageFille.message);
            //Rechargement
            location.reload();
          }
        }
      }

      window.onload = alert('Page chargée !');
    </script>
  </body>
</html>

Page Fille (pageFille.html)

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
  </head>
  <body>
    <form>
      <label for="message">Message :</label>
      <input id="message" type="text" name="message">
      <input type="submit" value="Valider et quitter" onclick="quitterPage();">
    </form>

    <script>
      function quitterPage() {
        window.message = document.getElementById('message').value;
        window.fermeture = true;
        window.close();
      }
    </script>
  </body>
</html>

Voilà pour l’exemple. Il reste maintenant quelques limitations à préciser pour finir cet article. Si l’utilisateur ferme la fenêtre du navigateur via le bouton prévu à cet effet (la croix rouge généralement en haut à droite), la page parente n’est pas rechargée. Dans mon cas pratique, cela fait sens car l’utilisateur n’aura alors pas soumit d’image; il n’y a donc aucun raison de rafraîchir la page. Autre point, si l’utilisateur rafraîchit la page fille, cela a pour effet de casser la liaison existante entre les deux pages et le rechargement de la page parente n’aura pas lieux.

Voici donc une manière de rafraîchir une page parente à la fermeture de sa page fille en restant dans les fonctionnalités de base du navigateur et des langages. D’autres façons de faire sont très certainement possibles (avec des événements) et certains framework js seraient à même de simplifier le problème, en permettant de ne mettre à jour dynamiquement qu’une partie de l’interface.

[ArchLinux] Partage Samba

J’ai installé, il y a de cela plusieurs mois, un serveur miniDLNA sur l’une de mes machines équipée d’Arch Linux pour pouvoir partager facilement du contenu multimédia sur le réseau local. Jusqu’à présent, j’effectuais le transfert de fichier vers cette machine en branchant directement un disque dur sur la machine, en m’y connectant en SSH, en montant le disque puis en copiant les données à coup de commande cp. J’ai également effectué quelques transferts en montant un répertoire distant de la machine sur ma machine principale via sshfs. Ces deux solutions fonctionnent plutôt bien. Je me tourne aujourd’hui vers la mise en place d’un partage Samba, afin d’être en mesure de déposer facilement des fichiers depuis Windows également. Voici donc les quelques étapes nécessaires à la mise en place d’un répertoire accessible en lecture écriture sans restriction.

# Installation de Samba
sudo pacman -S samba
# Mise en place du fichier de configuration par défaut
cp /etc/samba/smb.conf.default /etc/samba/smb.conf
# Edition de la configuration
sudo nano /etc/samba/smb.conf

Pour le partage d’un répertoire, j’ajoute les lignes suivantes dans le fichier configuration :

[Media]
 path = /vers/le/répertoire
 public = no
 writable = yes
 printable = no

Avec cette configuration, le répertoire est bien disponible en lecture écriture et visible sous Windows. Pour configurer plus précisément l’ensemble, il faudra regarder les autres options disponibles. Dans mon cas, cette configuration me permet de faire ce que j’espérais. Suite de l’installation :

# Démarrage des services
sudo systemctl start smbd.service
sudo systemctl start nmbd.service
# Mise en place du service au démarrage
sudo systemctl enable smbd.service
sudo systemctl enable nmbd.service
# Ajout du user système dans Samba
# A vérifier si nécessaire
sudo smbpasswd -a <user>
# Vérifier la syntaxe de la configuration
testparm -s

En cas de modification de la configuration, ne pas oublier de redémarrer le service :

sudo systemctl restart smbd.service

 

Informations issues de l’excellent wiki Arch Linux pour la page concernant Samba.

SFR et l’emailing sauvage

Avant de rentrer dans le vif du sujet, laissez-moi introduire le contexte. Il y déjà plusieurs années de cela, j’ai configuré ma première adresse mail FAI en tant qu’adresse bis de contact administratif pour la gestion de la connexion internet de mes parents. Cela n’a pas été plus utile que ça, à part pour suivre l’évolution du montant de la facture de l’abonnement et vérifier l’absence de problème. Je n’avais en revanche jamais pris la peine de remarquer que cette opération avait eu pour effet d’inscrire mon adresse sur la liste publicité pour les nouvelles offres de SFR en matière d’abonnement, etc. Jusqu’à présent, les mails que je recevais finissaient à la corbeille et leur fréquence n’était pas suffisamment haute pour être réellement dérangeante. Jusqu’au mardi 17 mai 2016…

Continuer la lecture de « SFR et l’emailing sauvage »

Redis-server 2.8 sur Debian 7 Wheezy

La version 8.3 de Gitlab nécessite une mise à jour de redis car celle-ci se base sur redis-server en version 2.8. Problème, ce composant n’est pas disponible par défaut pour Debian Wheezy. Deux solutions possibles, mettre à jour Debian vers Debian Jessie avec tous les risques que cela comporte (init.d -> systemd, apache2.2 -> apache2.4, etc…) ou compiler le composant à partir des sources. Pour ma part, j’ai donc choisi la troisième solution : utiliser le dépôt backport wheezy qui par chance propose redis-server dans la version qui m’intéresse !

Pour commencer, on ajoute la ligne suivante dans le fichiers /etc/apt/sources.list du système :

deb http://ftp.debian.org/debian wheezy-backports main

On met à jour les dépôts :

apt-get update

On peux ensuite passer à l’installation :

apt-get -t jessie-backports install redis-server

Il sera nécessaire de faire un choix entre votre configuration locale et la configuration en provenance du paquet. Ici, pas le choix en regardant le diff entre les deux fichiers, il faut absolument prendre la nouvelle version.

Cela nécessite néanmoins de ré-appliquer la configuration de redis pour Gitlab comme décrit dans le paragraphe redis de la doc d’installation à partir de « Configure redis to use sockets« .

Pour vérifier la version de redis installée, on aura utilisé au préalable la commande :

redis-cli info | grep redis_version

Un captcha, ça ne s’improvise pas !

Ou une raison supplémentaire de questionner la légitimité de la consultation pour le nom de la région Alsace Champagne-Ardenne Lorraine.

J’ai pris la décision de ne publier cette analyse qu’une fois la consultation terminée, afin que celle-ci ne puisse être utilisée pour en fausser les résultats (qui ont déjà suffisamment de raisons de ne pas être représentatifs de grand chose).

Commençant par aborder les premières incohérences de cette consultation. Pas de restriction géographique, pas de limitation IP. Comme l’ont relevé bien des internautes, une même IP peut donc voter plusieurs fois, tant que celle-ci est capable de fournir plusieurs adresses mails différentes (il semble tout de même y avoir une limitation sur les adresses mails. Ouf !). Le manque de limitation sur l’IP peut se comprendre, il faut que tous les personnes d’un foyer soit en mesure de participer. Pas de limitation géographique ou de « coupon » de vote pour les citoyens concernés, les internautes du monde entier pouvaient donc venir donner leur avis. Intrigué par ces manquements, j’ai donc décidé d’aller jeter un œil au site (Outre le fait d’être un peu concerné puisque résidant à Strasbourg).

Consultation Nom Région ACAL

Voici donc à quoi ressemblait le site. La présentation est aérée, ça semble plutôt fonctionnel. Pourtant, mon regard est attiré par le bas de page, son message « (afin de lutter contre les robots et de prouver que vous êtes une personne) » et son captcha. A première vue, le captcha semble relativement simple, pas de texte compliqué et quasi illisible, juste un calcul à effectuer. Par ailleurs, cette petite phrase invite au défi. J’aime m’interroger sur la possibilité technique d’écrire des programmes idiots arrivant à résoudre ces types de captcha. Captchas sensés démontrer l’humanité de la personne derrière son écran. Je me plonge donc dans le code HTML de la page.

Continuer la lecture de « Un captcha, ça ne s’improvise pas ! »