Archives de catégorie : Fixs

PayPal passage au certificat SHA-256

Beaucoup de nos clients ont reçu ce mail de Paypal:
Comme nous vous l’avons déjà annoncé, PayPal passe au certificat SHA-256 pour www.paypal.com. Ce point de terminaison est également utilisé par les marchands se servant du produit Notification instantanée de paiement (IPN).

Cette mise à niveau est prévue le 30/09/2015. Cependant, nous serons peut-être amenés à modifier cette date au pied levé pour respecter la norme de sécurité du secteur.

Vous recevez cette notification car vous avez été identifié comme un marchand ayant utilisé les points de terminaison IPN au cours de l’année passée. Si vous n’avez pas effectué les modifications nécessaires, nous vous invitons à procéder à ces changements immédiatement afin d’éviter toute interruption de votre service.
Les changements étant techniques, nous vous conseillons de consulter les personnes responsables de votre intégration PayPal. Elles pourront identifier les modifications nécessaires. Transférez-leur cet email, les liens hypertextes ci-dessous et les coordonnées de votre responsable technique pour évaluation.
L’un des meilleurs moyens de vous assurer que votre intégration fonctionne est de l’essayer dans l’environnement de test. Les points de terminaison de l’environnement de test ont été mis à jour de façon à accepter les connexions sécurisées via les certificats SHA-256.

Quel incidence sur le fonctionnement de vos modules Paypal chez Icodia ?

1/Sur la plateforme mutualisée

Vous n’avez strictement rien à faire, nos équipes techniques ont fait le nécessaire sur l’ensemble de la plateforme.

2/Sur la plateforme dédiée/vps

Si vous rencontrez des problèmes de validation Paypal, vous pouvez faire le test suivant en shell sur votre serveur:

curl https://www.paypal.com

Si vous obtenez « ÿÿ »,  aucun problème coté serveur.

Si vous obtenez un message d’erreur du type « certificate verify failed », nous vous invitons à mettre à jour openssl (ce qui mettra à jour votre liste de certificats racine) sur votre serveur et à relancer Apache.

Notre équipe technique peut intervenir sur demande sur votre serveur.

 

Installer MAGENTO 1.9 sur un forfait mutualisé ICODIA

magento Par défaut, Magento 1.9.x désactive des directives de sécurisation du serveur.

Certaines instructions de désactivation génèrent une erreur SSI car nous n’autorisons pas ces désactivations.

Il faut donc commenter les lignes correspondantes dans le fichier .htaccess en racine.

Pour commenter, il suffit d’ajouter un # en début de ligne.

Les directives concernées sont les suivantes :

  • SecFilterEngine Off
  • SecFilterScanPOST Off
  • SSLOptions StdEnvVars
  • Options +FollowSymLinks
  • RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* – [L,R=405]

Fix UnZip Prestashop

Ce problème est intervenu sur la version 1.5 et suivantes. Les archives mises à disposition par Prestashop pour le CORE comme pour les modules sont encapsulées avec des fichiers qui ont des droits en 644, et donc sans droit d’exécution. Quand PHP est en module d’Apache, cela ne pose pas de problème. Quand il est en CLI comme sur notre plateforme (seule réelle solution pour le sécuriser), c’est plus embêtant car les .PHP ne peuvent plus être exécutés. Il reste possible de mettre à jour les CHMOD après l’installation, mais chaque mise à jour de modules génère un nouveau problème de droits sans exécution, donc de script d’installation du module, pas de création des tables nécessaires au module, etc.

Nous proposons la modification suivante pour ces versions :

Dans le fichier /classes/Tools.php, fonction ZipExtract :

remplacer :

public static function ZipExtract($from_file, $to_dir)
	{
		if (!file_exists($to_dir))
			mkdir($to_dir, 0777);
		if (class_exists('ZipArchive', false))
		{
			$zip = new ZipArchive();
			if ($zip->open($from_file) === true && $zip->extractTo($to_dir) && $zip->close()){
				return true;
			}
			return false;
		}
		else
		{
			require_once(_PS_ROOT_DIR_.'/tools/pclzip/pclzip.lib.php');
			$zip = new PclZip($from_file);
			$list = $zip->extract(PCLZIP_OPT_PATH, $to_dir, PCLZIP_OPT_REPLACE_NEWER);
			foreach ($list as $file)
				if ($file['status'] != 'ok' && $file['status'] != 'already_a_directory')
					return false;
			return true;
		}
	}

Par :

public static function ZipExtract($from_file, $to_dir)
	{
		if (!file_exists($to_dir))
			mkdir($to_dir, 0777);
		if (class_exists('ZipArchive', false))
		{
			$zip = new ZipArchive();
			if ($zip->open($from_file) === true && $zip->extractTo($to_dir) && $zip->close()){
				// Debut fix ICODIA
				@Tools::chmodr($to_dir, 0777);
				// Fin fix ICODIA
				return true;
			}
			return false;
		}
		else
		{
			require_once(_PS_ROOT_DIR_.'/tools/pclzip/pclzip.lib.php');
			$zip = new PclZip($from_file);
			$list = $zip->extract(PCLZIP_OPT_PATH, $to_dir, PCLZIP_OPT_REPLACE_NEWER);
			foreach ($list as $file)
				if ($file['status'] != 'ok' && $file['status'] != 'already_a_directory')
					return false;
			return true;
		}
	}

Analyse des requêtes SQL sous Prestashop

Si votre boutique Prestashop est lente, il vous faut rapidement identifier l’origine de cette lenteur.

Cela peut parfois être, par exemple, une requête SQL qui pose problème.

Pour cela, une modification simple permet d’écrire dans un fichier (journal ou log) des informations sur les requêtes effectuées (requête, durée, nombre de requête total, durée totale cumulée de l’ensemble des requêtes, etc.).

Cette procédure est très utilisée par notre support pour identifier un problème et est évidement transposable à de nombreux autre CMS.

Elle est systématiquement déployée sur les environnements de développement ou de test sur les sites dont nous assurons l’infogérance, dans une version plus complexe, qui journalise les données par page, avec des contextes définis qui permettent de comparer des systèmes de cache par exemple, calcule des moyennes, etc.
En bref, elle donne de très nombreuses pistes d’optimisation de la boutique.

Il est indispensable de limiter la journalisation à une IP (la vôtre) si vous utilisez cette solution sur un environnement en production, car le journal peut très rapidement prendre du poids et parce que les données seront moins facile à exploiter avec plusieurs visiteurs simultanés. Il est également important de désactiver le système de journalisation et d’effacer le journal après les tests.

Dans le fichier /classes/Db.php, ligne 318 environ, remplacer la fonction query() par : 

public function query($sql)
	{
		if ($sql instanceof DbQuery)
			$sql = $sql->build();

		if($_SERVER["REMOTE_ADDR"]=="1.2.3.4") { // remplacer 1.2.3.4 par votre IP publique
			global $icochrono;
			$icochrono = microtime(true);
		}
		$this->result = $this->_query($sql);
		if($_SERVER["REMOTE_ADDR"]=="1.2.3.4") { // remplacer 1.2.3.4 par votre IP publique
			global $_SERVER,$icochrono, $iconbreq, $icototalreq;
			$iconbreq++;
			$chrono = microtime(true) - $icochrono;
			$build = $icochrono - $icochrono2;
			$icototalreq += $chrono;
			file_put_contents("icolog", "[".$iconbreq.". ".date("d/m/Y H:i:s")." / ".round($chrono*1000, 2)." ms / total : ".round($icototalreq*1000, 2). " ms] ".trim(str_replace("\n", " ", $sql))."\n", FILE_APPEND);
		}
		if (_PS_DEBUG_SQL_)
			$this->displayError($sql);
		return $this->result;
	}

Le fichier de journalisation est créé en racine du site, il s’appelle « icolog ».

Mise à jour de WordPress sans FTP

Nativement, WordPress requiert un accès FTP pour faire les mises à jour. Ce système perdure depuis toujours et pose un problème au niveau de la sécurité. 
Il y a cependant un moyen plus facile de corriger ce problème en utilisant la méthode « FS_METHOD » dans votre fichier wp-config.php. Avant de commencer, pensez à conserver une copie du fichier wp-config.php.
 
1. Ouvrir /wp-config.php
 
Tout d’abord, ouvrez le fichier wp-config.php situé à la racine de votre site au moyen de votre client FTP.
 
2. Ajouter FS_METHOD
 
Copiez la ligne ci-dessous dans votre fichier wp-config.php, de préférence après la dernière ligne du fichier.
 

define('FS_METHOD','direct'); 

 
2. Sauvegarder et envoyer sur le serveur
 
Lorsque la modification est faite, vous pouvez sauvegarder le fichier et l’envoyer sur votre serveur. Voilà tout ! Lors de vos prochaines mises à jour, vous n’aurez plus à renseigner vos identifiants.

Typo3 ne reconnait pas les bases de données à l’installation

Ce problème est lié au blocage de la fonction PHP mysql_list_dbs().

Dans le fichier t3lib/clss.t3lib_db.php,

Remplacer la fonction  admin_get_dbs par celle-ci :

function admin_get_dbs() {

$dbArr = array();
 $req = "SHOW DATABASES";
 $databases_query = mysql_query($req, $this->link);
 while($database = mysql_fetch_object($databases_query)){
 if($database->Database=="information_schema") continue;
 $dbArr[] = $database->Database;
 }
 /*
 $db_list = mysql_list_dbs($this->link);
 while ($row = mysql_fetch_object($db_list)) {
 if ($this->sql_select_db($row->Database)) {
 $dbArr[] = $row->Database;
 }
 }
 */
 return $dbArr;
 }

Mise à jour automatique de WordPress via FTP impossible

WordPress-logo-brokenLa mise à jour automatique de WordPress utilise le protocole FTP pour récupérer chaque dossier et fichier de la nouvelle version.

Cette action est effectuée dans un processus PHP unique et donc assez long.

De plus, un contrôle et une mise à jour des droits des fichiers copiés est systématiquement effectuée, ce qui allonge énormément le processus et qui est inutile.

Si la mise à jour est en échec sur votre CMS, vous pouvez modifier la methode « chmod » de la class. Voici comment procéder :

– Ouvrez le fichier « /wp-admin/includes/class-wp-filesystem-ftpext.php » dans votre editeur de code.
– en ligne 149 (pour la version 3.5 de WordPress) remplacez le code suivant :

function chmod($file, $mode = false, $recursive = false) {
if ( ! $mode ) {
if ( $this->is_file($file) )
$mode = FS_CHMOD_FILE;
elseif ( $this->is_dir($file) )
$mode = FS_CHMOD_DIR;
else
return false;
}

// chmod any sub-objects if recursive.
if ( $recursive && $this->is_dir($file) ) {
$filelist = $this->dirlist($file);
foreach ( (array)$filelist as $filename => $filemeta )
$this->chmod($file . '/' . $filename, $mode, $recursive);
}

// chmod the file or directory
if ( ! function_exists('ftp_chmod') )
return (bool)@ftp_site($this->link, sprintf('CHMOD %o %s', $mode, $file));
return (bool)@ftp_chmod($this->link, $mode, $file);
}

par :

function chmod($file, $mode = false, $recursive = false) {
return(true);
}

Si votre site passe en maintenance à la fin de la mise à jour, il faut supprimer le fichier .maintenance en racine de votre répertoire FTP.