Fonction mcrypt_encrypt disparue ou dépréciée à partir de PHP 7.1

Re,

J'ai dit une bêtise : sur Wampserver64 l'extension est dispo : il faudra que mette de nouveau les mains de le cambouis pour trouver une équivalence sauf si comme je l'ai dit une âme charitable me donne un petit coupe de main.
Remarque : je n'utilise pas de CMS, je développe tout moi même, je ne suis pas professionnel en informatique.
Merci d'avance

si une fonction est déprécié en 7.1, l'annonce et les warnings datent de bien plus tôt
et c'est le job du developpeur de suivre ça
puis effacée dans les versions suivantes

surtout quand ça concerne la **sécurité**

tu peux ne pas suivre, mais c'est ta responsabilité

peg_match? https://www.php.net/manual/fr/function.preg-match.php -> historique
je doute que Pcre soit abandonné un jour...

si tu dev une mise à jour, utilise 7.3 la version stable en cours

> Je cherche depuis 3 jours des alternatives à mcrypt RIJNDAEL 256
Wampserver

et si tu utilisais un environnement linux de production au lieu d'un truc un peu exotique?
à mon avis tu aurais plus de chance sur stackoverflow.com

Ok,

Merci pour ta réponse je vais voir sur les sites cités car maintenant je sais que la bibliothèque (extension) SODIUM peut être activée sur Wampserver .

Puisque tu es programmeur, tu n'as pas une alternative à ma demande avec l'extension SODIUM ?

Pour preg_match je suis en train de trouver la parade : plus d'erreur mais pas encore eu le temps de tester le regex modifié avec les caractères d'échappement.

Avec la fuite en avant, je passe plus de temps avec html, javascript, php, css ouf .. que dans mon environnement stable bien conçu et avec un IDE au top.
Le web c'est du bricolage avec un morceau de ci d'un côté puis un autre morceau de l'autre à la suite et attention à l'ordre ... C'est pas très propre comme principe : ce n'est que mon avis .

Pour linux, tous les bureaux d'étude utilisent Windows : je ne vais pas développer en .net pour linux et pour qui ?

je ne suis pas compétent devant tant de certitudes et de connaissances, puisque seul les BE existent ;)
(c'est ma formation,métier de base pourtant :/)

si j'avais des solutions alternatives potentielles, je te les aurais données

tu compares peut-être des choses sans rapport pour tirer des conclusions, mais si ça te fait du bien...

Tu dis :
"je ne suis pas compétent devant tant de certitudes et de connaissances, puisque seul les BE existent ;) (c'est ma formation,métier de base pourtant :/)
si j'avais des solutions alternatives potentielles, je te les aurais données"

Même toi qui est certainement un professionnel, tu n'as pas un début de solution (mais ce n'est pas de ta faute). Je plains les professionnels qui doivent passer leur temps à écrire et réécrire des lignes de code qui fonctionnaient très bien : que de temps perdu pour la productivité !

**Je suis un autodidacte** ( j'ai commencé en 1984 à programmer en assembleur sur 6502 (1 Mhz !) :
Je n'ai pas de certitudes sinon je ne serai pas sur ce forum et suis surtout mécontent de cette fuite effrénée en avant me laissant sur le carreau sans vergogne :
C'est malheureusement cela le logiciel libre ...
Heureusement que ce n'est pas avec mon logiciel de CAO que je gagne ma vie !

Bonjour à tous et surtout à kyodev (infatigable et très patient ...),

J'ai enfin réussi à trouver une solution qui m'oblige à tout réécrire (comme je disais, les programmeurs n'ont que çà à faire : découvrir après tant d'années qu'une fonction fait défaut 'mcrypt_encryt' et la supprimer relève d'une légèreté sans pareil même si PHP est du domaine libre mais pourtant c'est un des moteur des fournisseurs d'accès : cherchez l'erreur).
_Si les constructeurs d'avion faisaient pareil, il y aurait plus d'avions au sol qu'en vol_ !

**Je donne le lien même si cela ne concerne pas à proprement parler une problème direct d'hébergement comme le précise si bien OVH** :
https://odan.github.io/2017/08/10/aes-256-encryption-and-decryption-in-php-and-csharp.html
Les codes fonctionnent bien en PHP (openssl_encrypt) et en Vb .net après transposition du C vers Vb .net avec bien sur le même résultat de cryptage.

Je tiens à dire merci à **kyodev** qui a essayé de m'aider.

**N.B: Enfin pour clore le sujet, si je veux utiliser cette fonction dépréciée _libre à moi_ puisque cela relève de _MA RESPONSABILITÉ_.**

Pascal

depuis 2002 où j'ai intégré un projet libre, ça me fait un peu mal de lire ça ;/

il faut aussi partir du principe que les développeurs ne sont pas des chieurs et que parfois ils peuvent avoir des raisons solides pour varier, cela fait partie de l'évolution (je ne suis pas compétent pour juger PHP)
ça peut tout simplement être une raison de sécurité à la base
ou un gain de performances, php 7 n'arrête pas d'évoluer
(https://kinsta.com/fr/blog/comparaison-php/)

> cette fonction dépréciée libre à moi puisque cela relève de MA RESPONSABILITÉ.

tu peux, mais tu sais que tu utilises alors des versions PHP périmées, plus maintenues
et que les utilisateurs à terme devront faire un choix, car ils auront tendance à suivre les versions officielles (par sécurité)

Re,

Je vais de force mettre à jour de 7.0 vers 7.2 ou 7.3 ou suivant puisque je suis l'auteur des lignes que j'écris m'obligeant toujours à adapter mon code. Il faut croire que c'est volontaire et voulu pour alimenter le business de la programmation.

Pour la sécurité, ****je suis assez grand pour décider tout seul** et on n'a pas à m'imposer cette situation** : il fallait tout simplement un peu moins de légèreté quand les lignes de la fonction mcrypt ont été écrites.
De plus, je rigole au sujet de la sécurité car quelque soit le code quelque soit le cryptage, il sera cassé tôt ou tard ...
Une protection ne tient que si personne ne prend la peine de la casser.
En aes-256-cbc, je vais certainement devoir encore changer car ce sera encore déprécié dans quelques temps : c'est lassant et consternant.

La performance pour PHP ... bof... _pour les quelques lignes en PHP sur mon site_, il n'y a pas de quoi fouetter un chat : Je n'ai pas mesuré mais je dois gagner peut-être quelques millisecondes et encore.

C'est vrai que je n'utilises pas les **CMS tous faits qui sont d'ailleurs la _cause de la saturation d'OVH_** .
N'importe qui aujourd'hui peut maintenant installer une solution toute faite sans connaissance préalable et se croire devenu Webmaster. A voir les appels à l'aide sur ce forum je les plains !

Pascal