Lors de la conférence Build 2021, Satya Nadella, le PDG de Microsoft, a évoqué à plusieurs reprises le nouveau Windows, en disant qu'il le testait déjà depuis plusieurs mois, et qu'il serait plus ouvert. Nous allons bientôt en savoir plus puisque Microsoft va organiser une conférence le 24 juin 2021.

Notez bien cette date dans votre agenda : le 24 juin 2021, à 17h00 (heure de Paris). C'est à ce moment précis que commencera la conférence en ligne de Microsoft. Satya Nadella sera là, ainsi que le Chief Product Officer de chez Microsoft, Panos Panay.

Même si l'on ne connaît pas le contenu exact de cette conférence, on sait que Microsoft va présenter le futur de Windows. Depuis plusieurs mois, on parle de la mise à jour de fin 2021 qui devrait être une mise à jour majeure : cela pourrait bien se confirmer. Par ailleurs, on peut imaginer que les améliorations de l'interface seront évoquées, en lien avec les nouveautés présentées dans le cadre du projet "Sun Valley".

On sait aussi que Microsoft réfléchit depuis plusieurs mois à la restructuration du Microsoft Store car aujourd'hui il ne répond pas aux attentes, ni aux ambitions de la firme de Redmond. Microsoft devrait lui donner une place beaucoup plus importante dans Windows. Pour y parvenir, le Microsoft Store devra être plus ouvert et permettre à n'importe quel développeur de proposer une application. D'ailleurs lors de la conférence Build 2021, Satya Nadella a précisé que "[nous, Microsoft] accueillerons tous les créateurs qui cherchent la plateforme la plus innovante, ouverte et nouvelle pour bâtir, distribuer et monétiser leurs applications".

Bon, arrêtons de spéculer et attendons une petite vingtaine de jours pour, enfin, tout savoir (ou presque) sur le prochain Windows qui ne s'appellera peut-être plus Windows 10 ! Je vous donne déjà rendez-vous le 24 juin pour un récapitulatif des annonces de Microsoft dès la fin de la conférence !

The post Le 24 juin 2021, Microsoft va présenter la nouvelle génération de Windows first appeared on IT-Connect.

Les développeurs de Mozilla travaillent sur une nouvelle fonctionnalité qui permettra au navigateur Firefox de se mettre à jour tout seul, en arrière-plan. La fonction sera intégrée à Firefox 90.

Attendue au sein de Firefox 89, la fonctionnalité de mise à jour automatique de Firefox n'est finalement pas intégrée à la dernière version du navigateur de Mozilla. Il faudra patienter encore un petit peu et attendre la sortie de Firefox 90.

Sur son site, Mozilla a publié une version bêta de Firefox 90 où est il est précisé : "Les mises à jour en arrière-plan sont disponibles dès maintenant sur Windows. Cette fonctionnalité va permettre à Firefox de se mettre à jour, même quand il n'est pas en cours d'exécution. Cette nouveauté sera diffusée auprès de tous les utilisateurs au cours des prochains mois".

Kirt Steuber de chez Mozilla précise : "Jusqu'à maintenant, Firefox téléchargeait et installait les mises à jour seulement lorsque l'utilisateur le lançait. Ce qui implique que les utilisateurs qui n'utilisaient pas Firefox fréquemment, étaient régulièrement out-of-date". Il a bien résumé la situation et cela montre tout l'intérêt de cette nouvelle fonctionnalité !

La tâche planifiée qui sert à mettre à jour Firefox en arrière-plan sera exécutée toutes les 7 heures, quand le navigateur n'est pas en cours d'exécution. Ce processus sera automatique et ne nécessite pas d'action de la part de l'utilisateur. Le service Mozilla Maintenance Service est utilisé pour effectuer l'installation.

Si le navigateur est en cours d'exécution, la mise à jour ne sera pas lancée pour éviter de perturber l'utilisateur. D'après Nick Alexander, un ingénieur de chez Mozilla, il sera possible de désactiver la mise à jour automatique en arrière-plan dans les paramètres du navigateur. Pour les entreprises, il y aura un paramètre de GPO qui permettra de gérer les mises à jour automatique de Firefox (BackgroundAppUpdate).

Pour le moment, Mozilla va intégrer cette fonctionnalité sur Windows. Il n'est pas précisé s'il est prévu de faire la même chose sur Linux ou macOS. Chez la concurrence, Google et Edge s'appuient déjà sur un mécanisme de tâches planifiées pour effectuer des mises à jour automatiques.

Pour le moment, Mozilla vient de publier Firefox 89 : l'occasion de publier une nouvelle interface. Personnellement, je la trouve vraiment réussie, notamment avec les angles des fenêtres qui sont arrondis.

Source

The post Sur Windows, Firefox 90 pourra se mettre à jour tout seul, en arrière-plan first appeared on IT-Connect.

Plus de 17 000 sites sont vulnérables suite à la découverte d'une faille de sécurité Zero Day dans le plug-in Fancy Product Designer, compatible avec WordPress, WooCommerce et Shopify. Cette faille de sécurité est activement exploitée par les pirates et des scans de sites Internet sont en cours pour identifier de nouvelles cibles.

Le plug-in payant Fancy Product Designer s'intègre parfaitement aux boutiques en ligne qui tournent sous WordPress, WooCommerce (pour WordPress) ou Shopify. Il permet de mettre en place une interface de personnalisation des produits. À en croire les statistiques du plug-in, il représente plus de 17 000 installations. Même si elles ne sont pas forcément toutes actives, les sites actifs quant à eux sont vulnérables !

L'analyse en sécurité Charles Sweethill de chez Wordfence a fait la découverte de cette faille de sécurité dans Fancy Product Designer. Il précise que cette faille de sécurité est exploitable lorsque le plug-in est installé sur WordPress ou lorsqu'il est installé via WooCommerce. Par contre, les sites hébergés sur Shopify sont protégés grâce au contrôle d'accès strict qui est mis en place.

La vulnérabilité permet d'uploader un fichier PHP malveillant sur le serveur où sont installés le site et le plug-in Fancy Product Designer. Dans certains cas, lorsque l'attaque réussie on se retrouve avec un fichier PHP nommé avec un identifiant unique et que l'on peut retrouver dans un sous-dossier des dossiers "wp-admin/" ou "wp-content/plugins/fancy-product-designer/inc/". Par exemple, cela peut donner :

wp-content/plugins/fancy-product-designer/inc/2021/05/30/4fa00001c720b30102987d980e62d5e4.php

Pour le moment, l'éditeur du plug-in n'a pas communiqué et n'a pas publié de correctif. Pour se protéger, il faudrait désinstaller le plug-in par précaution, mais ce n'est pas si simple de retirer une fonctionnalité d'un site en pleine production ! D'après le rapport publié par Wordfence sur son site, la majorité des attaques sont effectuées depuis 3 adresses IP publiques, que vous pouvez bloquer dès à présent :

69.12.71.82
92.53.124.123
46.53.253.152

La faille est référencée avec le nom CVE-2021-24370 et le score CVSS de 9.8 qui lui est attribué montre qu'il s'agit bel et bien d'une vulnérabilité critique !

Source

The post WordPress : une faille Zero Day expose des milliers de sites e-commerce ! first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer une redirection HTTP vers HTTPS pour votre site Internet hébergé sur un serveur Apache.

Lorsque l'on configure un site sous Apache, soit l'on utilise un fichier de configuration, soit l'on utilise un fichier .htaccess, mais on peut aussi mixer les deux. Sur un hébergement mutualisé basique où l'on va héberger un site, nous n'avons pas accès directement à la configuration d'Apache, ce qui nécessite d'utiliser un fichier ".htaccess" à la racine du site pour apporter des modifications sur la configuration.

Pour rediriger automatiquement les flux HTTP vers HTTPS avec Apache, il va falloir réécrire les URL pour que "http" devienne "https" dans le but d'avoir une connexion sécurisée. Même si votre site est accessible en HTTP et en HTTPS, il est préférable de rediriger tout le trafic vers une connexion HTTPS.

L'utilisation du fichier .htaccess pour déclarer des règles de réécriture est une pratique courante.

Redirection HTTP vers HTTPS sous IIS

II. Redirection HTTP vers HTTPS avec .htaccess

Je vous invite à vous connecter en SSH sur votre serveur dans le but de créer un fichier .htaccess à la racine du site. Si vous avez déjà ce fichier, vous pouvez simplement l'éditer.

Je pars du principe que la racine de mon site est :

/var/www/html/

Pour créer le fichier et l'éditer à l'aide de nano, cela donne :

nano /var/www/html/.htaccess

Ensuite, dans ce fichier il va falloir ajouter quelques lignes :

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

La règle "RewriteEngine On" permet d'activer le module de réécriture d'URL d'Apache, c'est-à-dire mod_rewrite. Ensuite, on crée notre condition avec "RewriteCond" qui va déclencher la règle "RewriteRule" dans le cas où cela correspond. En fait, la règle va se déclencher si le client se connecte à notre site en utilisant le port 80, correspondant au http. 

Dans ce cas, on réécrit l'URL : on conserve la même URL complète, mais on utilise le préfixe "https://". En complément, le fait d'indiquer "R=301" précise qu'il s'agit d'une redirection permanente : une bonne pratique et une information importante à donner aux moteurs de recherche.

Il y a une autre façon de faire et qui est l'occasion aussi d'ajouter "www" avant le nom de votre domaine, si vous le souhaitez ! Ce qui est important c'est de ne pas utiliser les deux (avec ou sans "www"). Si vous utilisez le bloc ci-dessous, modifiez le nom de domaine.

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.it-connect.fr/$1 [R=301,L]

Ces règles doivent fonctionner dans la majorité des cas, mais je n'irais pas jusqu'à dire dans tous les cas. Si c'est sur votre propre serveur, ça devrait aller, mais parfois en fonction des hébergeurs il peut y avoir des restrictions.

Imaginons qu'il y ait un souci et que la règle ne fonctionne pas, essayez de remplacer "RewriteCond %{SERVER_PORT} 80" par la règle suivante :

RewriteCond %{HTTPS} !=on

III. Redirection HTTP vers HTTPS via le VirtualHost

Petit bonus, pour rediriger les flux HTTP vers HTTPS en modifiant directement la configuration d'Apache, c'est-à-dire la configuration de votre VirtualHost, il suffit d'indiquer cette règle :

Redirect permanent / https://www.it-connect.fr/

Bien sûr, modifiez avec votre nom de domaine . Même si c'est possible, il n'est pas nécessaire d'utiliser RewriteCond et RewriteRule dans ce cas.

The post Apache : redirection HTTP vers HTTPS avec un fichier .htaccess first appeared on IT-Connect.

I. Présentation

J’ai récemment réinstallé mon laptop avec la dernière version d’Ubuntu, et après avoir réinstallé mes outils fétiches, je souhaitais tester rapidement un nouveau container qui me faisait de l'œil via docker. Je lance donc le classique « docker run container:latest », et là : c'est le drame...

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json: dial unix /var/run/docker.sock: connect: permission denied

Bim ! Erreur dans ta face.

Il me semblait pourtant avoir tout bien fait lors de la réinstallation de docker. Mais apparemment non : j'ai dû louper quelque chose. C'est parti donc pour une séance d'investigation.

Et si vous ne faites pas attention lors de l’installation, ou si vous mettez à jour vos packages régulièrement, il y a des chances que ça vous arrive à vous aussi.

Laissez-moi vous expliquer comment régler ça.

II. Prérequis

• Une distribution Linux d’installé ou dispo sous WSL (le fameux sous-système Linux pour Windows). Personnellement, j'utilise Ubuntu 20.04 pour ce tuto.
• Docker installé

 

III. Un problème de droits… Manifestement

Revenons à notre erreur, plutôt explicite : il me manquerait des droits pour accéder à docker lorsque j’exécute une commande telle que docker pull ou docker run.

Alors, par où commencer ?

Et bien, lorsqu'il s'installe, docker est censé créer un groupe « docker » sur votre système Linux. Commencez par vérifier que ce groupe est bien présent :

cat /etc/group

On peut voir ici que non seulement le groupe docker est présent, mais qu'il contient également un utilisateur : thibault.

Pour vous en convaincre, j'ai créé un nouvel utilisateur "test", et l'ai ajouté au groupe docker.

Si je relance ma commande cat, on voit maintenant que mon groupe docker contient deux utilisateurs : thibault et test.

Si votre utilisateur n'est pas un membre du groupe, ajoutez-le sans attendre via la commande :

sudo usermod -aG docker <user>

Car oui, vous voulez être dans ce groupe, afin de pouvoir lancer sans sudo les commandes docker.

On va ensuite vérifier votre dossier .docker dans votre home directory, qui contient les paramètres docker, et notamment vos custom settings.

S’il est présent, vous allez le supprimer.

NOTE : pas de panique, votre dossier .docker va se recréer automatiquement. Vous perdrez cependant vos custom settings si vous en aviez : pensez donc à faire une copie de ce dossier afin de les conserver.

Bien, maintenant que ce dossier est supprimé, nous allons tester à nouveau de lancer un container, par exemple en effectuant :

docker run hello-world

Pour l'explication, on demande ici à docker de lancer un container qui s'appelle hello-world. Si l'image n'est pas présente sur notre machine, docker va alors télécharger l'image à partir du repository Docker hub.

Qu'est-ce que ce container hello-world ? Il s'agit d'un container minimaliste qui ne va faire qu'une seule chose : se démarrer et écrire "Hello world" dans votre terminal. Rien de plus. Mais c'est pratique pour tester le bon fonctionnement de docker.

Si à la suite de cette opération vous rencontrez l’erreur suivante, c’est presque fini.

WARNING: Error loading config file: /home/user/.docker/config.json -stat /home/user/.docker/config.json: permission denied

Il vous suffit alors de taper les commandes suivantes pour modifier les droits d’accès et le propriétaire du dossier .docker, et le tour est joué :

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R

sudo chmod g+rwx "$HOME/.docker" -R

Malgré cela, votre docker est toujours récalcitrant ?

Redémarrez-le en effectuant un :

sudo systemctl restart docker

Enfin, si malgré ces opérations docker ne veut toujours rien savoir, il reste une dernière étape : changer les droits du fichier /var/run/docker.sock :

sudo chmod 666 /var/run/docker.sock

Redémarrez à nouveau docker, et profitez enfin de ce container magique qu'est hello-world :

docker run hello-world

Votre docker est maintenant fonctionnel, et vous devriez obtenir le résultat suivant :

Et voilà, investigation clôturée, coupable appréhendé.

Il ne vous reste plus qu'à tester vos containers préférés sous docker.

The post Docker : résoudre l’erreur permission denied while connect to daemon socket first appeared on IT-Connect.