TinyMCE et Ruby On Rails autoriser certaines balises html

Sur un projet Rails où vous avez installé un tinyMCE suivant cette méthode, par défaut tinyMCE filtrera un certain nombre de balise HTML.
Si vous souhaitez autoriser la balise script (attention c’est assez dangereux si vous avez des rédacteurs mal formés ou mal intentionnés) il faut modifier le fichier config/tinymce.yml pour ajouter ceci :

Cela permet d’étendre la liste d’éléments valides par défaut de tinyMCE (plus d’infos sur cette liste) avec l’élément script et le « [*] » indique que cet élément peut avoir n’importe quel attribut (plus d’infos ici).

Et voilà, très pratique pour intégrer des tweets ou autres éléments dans la page.

Enjoy 😉

Debian – Apache2 reload vs restart mais pourquoi ?

Bon un petit billet pour expliquer un cas rencontré qui me semble des plus incohérents. Attention sur une ancienne version d’apache2 (la 2.2.16 autant dire une très vieille version).

Le contexte, je suis sur un serveur Debian en train de modifier des virtualhosts apache2, jusqu’ici rien de bien méchant.

Après ma modification (toute petite et n’ayant aucune conséquence sur la suite de l’histoire) je lance un « reload » d’apache2 => tout est ok.

Comme notre bonne pratique le veut (un peu comme chez les électriciens), c’est le dernier qui intervient qui est responsable donc pour éviter au copain de se prendre un restart qui failed à cause de ma modification (et ce potentiellement des mois après) je lance un « restart » d’apache2 et là bam ça failed. Je commente ma modification et je relance un « restart » et au surprise ça failed encore. J’en tire une première conclusion la bonne pratique n’a pas été respecté sur l’intervention précédente, bon cela arrive ce n’est pas le top mais ce n’est pas dramatique, la seconde conclusion que j’en tire et qui me pose beaucoup de souci, c’est là le souci réel c’est que la commande reload autorise des configurations qui ne sont pas bonnes alors que la commande restart elle ne les autorise pas donc à quoi sert d’utiliser une commande qui peu vous entrainer ce genre de soucis des mois après ?

Bon je me creuse la tête et je me dis tiens maintenant que je sais où est l’erreur je désactive le virtualhost concerné, je lance un « restart » => Ok parfait, je vais plus loin je réactive le virtualhost et je lance un « reload » et là devinez quoi bah OK donc la conclusion c’est quand vous avez une configuration qui ne passe pas en restart, commentez là, faites un restart, décommentez là et faites un reload mais oui bien sûr c’est super trivial.

Si certains comprennent ce genre de chose je suis preneur mais personnellement, je trouve ça incohérent surtout quand on sait qu’il y avait bien une erreur dans ma configuration. Donc le reload ne check pas autant que le restart et on ne peut être sûr d’une config qu’après un restart seulement.

Pas top 😉

Certificat ssl et virtualhost en 443 sur apache2 – debian

Si vous rencontrez une erreur de « restart » d’apache2 (attention le « reload » lui passe, ce que je ne comprendrai jamais c’est l’utilité d’une commande qui passe sur des configurations non valides plus d’explication ici) qui mentionne dans le fichier /var/log/apache2/error.log :

Il y a plusieurs points à vérifier le premier d’après ce forum est de vérifier que le chemin d’accès aux différents éléments de votre Virtualhost en 443 sont cohérents dans l’exemple suivant il faut vérifier « /etc/ssl/certs/domaine.fr.crt » et « /etc/ssl/private/domaine.fr.key » :

Dans mon cas cela n’a pas suffit, j’ai donc cherché un peu plus loin en relisant l’erreur qui m’indique que le serveur n’aurait pas de certificat de configurer pour quelque chose et je me suis aperçu que j’avais dans mes Virtualhost en 443, un Virtualhost de redirection comme ci-après :

Et là c’est le drame, oui on veut faire une redirection mais pour que cette redirection fonctionne il faut indiquer au serveur le certificat correspondant à domaine.fr, j’ai donc transformé mon Virtualhost en :

Et un « restart » d’apache2 plus tard tout est rentré dans l’ordre.

Enjoy 😉

Gestion des erreurs 404 et 500 en Ruby on Rails

Concept

La gestion native des erreurs en ROR souffre de deux manques : d’abord, les erreurs ne sont pas chartées selon le style de votre application, ensuite elles n’alertent pas les développeurs de ce qui s’est produit. Le code ci-dessous peut être placé directement dans l’application ou au sein d’une gem.

Étape 1 : Intercepter les erreurs 404, 422 et 500

Dans le routeur d’URL, ajouter les lignes suivantes :

Lorsqu’une erreur se produit, le moteur de Rails appelle automatiquement ces routes. En ajoutant les routes ci-dessus, on va pouvoir modifier le comportement natif de votre appli en les interceptant dans nos méthodes.

Étape 2 : Méthodes dans le contrôleur

Tout commence par la création d’un contrôleur dédié :

Ce code est simplifiable si vous ne le placez pas au sein d’une gem, mais bon, ça peut rapidement devenir un couteau suisse dans tous vos projets.

Étape 3 : le mailer

Bon là rien d’exceptionnel :

Étape 4 : Les vues des mailers fraichement créés

Pour les 404 je vous suggère d’extraire quelques infos utiles telles que @requete.remote_ip, @requete.user_agent, @requete.request_method, @requete.original_url ou encore @requete.filtered_parameters.to_s (les paramètres de la requête).
Pour les 500, vous pouvez ajouter :

Étape 5 : les vues des méthodes en question

N’oubliez donc pas de créer les vues correspondant aux méthodes selon les choix que vous aurez réalisé à la lecture de l’article.

Nous sommes à l’écoute de toute suggestion car la gestion des erreurs ne semble pas très élaboré d’origine.

Google autocomplete sur la france et les dom-tom

Si vous avez un champs autocomplete fait avec l’api Google maps places vous pouvez restreindre, la zone de recherche à un « territoire » par exemple la France métropolitaine assez facilement avec :

Si vous souhaitez, allez plus loin en ajoutant plusieurs « territoires », comme par exemple ajouter les dom-tom, il vous faut faire comme suit :

Pour comprendre les différents identifiants de territoires vous pouvez consulter la page Wikipédia sur la norme ISO 3166-1

Et voilà la zone de recherche sera plus large.

Enjoy 😉

Sources : https://developers.google.com/maps/documentation/javascript/reference?hl=fr#GeocoderComponentRestrictions, http://codepen.io/fchaussin/pen/VKboYd, https://fr.wikipedia.org/wiki/ISO_3166-1

Environnement d’exécution différents entre l’utilisateur et le cron de l’utilisateur

Une simple brève pour rappeler qu’un utilisateur que ce soit root ou un autre n’a pas le même environnement d’exécution que le cron de cet utilisateur. En d’autres termes ce n’est pas parce qu’une commande s’exécute correctement lorsque que l’on est connecté en tant que l’utilisateur X que cette même commande s’exécutera correctement dans un cron de l’utilisateur X (test fait sous debian).

L’environnement étant différent l’accès à certaines commandes ne se fait pas toujours de la même façon.
Ceux sont souvent des scripts peu classiques, par exemple un script de renouvellement automatique pour let’s encrypt comme proposé ici, s’exécutera très bien en root en ne tapant pas le chemin complet vers le script mais pas via le cron de root si vous n’indiquez pas le chemin complet vers le script. Il faut donc penser à tester ces crons, de manière quasi systématique pour être certains de la bonne exécution de ceux-ci.

Et voilà 😉

Récupérer les dates de début et de fin d’un certificat ssl en ligne de commande

Si vous avez besoin de récupérer rapidement et simplement les dates de début et de fin de certificat ssl pour par exemple vérifier le temps qu’il vous reste avant l’expiration il y a plusieurs solutions :

La solution simple via le navigateur : Vous vous connectez sur l’url à vérifier et vous inspectez votre certificat à travers le navigateur, action simple et visuelle.

Oui mais pas facile à automatiser cela demande une action humaine.

Si vous souhaitez monitorer les dates de manière automatique vous pouvez passer par une ligne de commande qui vous retourne les dates du certificat, la voici :
echo | openssl s_client -showcerts -servername monUrl.fr -connect monUrl.fr:443 2>/dev/null | openssl x509 -inform pem -noout -text | egrep "Not After :|Not Before:"

Cette ligne de commande vous sort ce résultat :

Not Before: Mar 24 07:28:00 2017 GMT
Not After : Jun 22 07:28:00 2017 GMT

Il est simple par la suite de récupérer les 2 dates (Not before : date d’émission du certificat, Not after : date d’expiration du certificat) et de les stocker comme bon vous semble et de faire les calculs qui vont bien pour vous prévenir quand l’échéance du renouvellement arrive.

Et voilà 😉

Source : http://serverfault.com/questions/661978/displaying-a-remote-ssl-certificate-details-using-cli-tools

phpMyAdmin : Augmenter la taille maximum pour l’import d’un fichier

Par défaut, on peut importer un fichier d’une taille maximale de 100Mo.

Pour augmenter cette limite, il faut éditer le fichier /etc/php5/apache2/php.ini et remplacer les deux valeurs suivantes :

Ensuite, il suffit de redémarrer apache :

Google maps Autocomplete déclencher la recherche au chargement de la page

Si vous avez mis en place un champ autocomplete de google maps et que ce champs et prérempli au chargement de la page et que vous souhaitez déclencher la recherche en conséquence, voici une petite astuce.

Cela consiste une fois tous les éléments chargés à simuler flèche du bas puis entrée sur la zone de recherche (souvent un input). Problème comment savoir que tous les éléments sont chargés car faire cette simulation trop rapidement ne fonctionne pas et aucun évènement n’est lancé d’après la doc google.

Du coup l’astuce consiste à attendre que la liste de propositions soit chargés et ensuite simuler la touche flèche bas puis entrée comme suit :

Voilà

Enjoy 😉

Problème innerHeight et height en JS sur mobile

Petite astuce qui peut éviter de perdre du temps à débugger.

Si lors de l’utilisation de la méthode .height() ou .innerHeight() vous rencontrez des difficultés pour récupérer la bonne valeur de la hauteur d’un élément (principalement sur mobile), Il faut vérifier dans le content de la méta viewport que la valeur height=device-height est bien présente.

Normalement, cela devrait résoudre pas mal de problèmes.