Oulà! Non non non! PHP est un programme à part entière!
Apache reçoit la requête d'une page PHP, il regarde alors si PHP se trouve sur le serveur. S'il l'est, il envoie la page à l'exécutable PHP, qui lui la traite et la transforme en Html et l'envoie ensuite à Apache, qui finit par envoyant finalement la page au client.
Aussi, il est impossible de pouvoir crypter les page Html que le client reçoit. Comment les navigateurs pourraient-ils alors afficher la page si eux-mêmes ne la comprennent pas?
PHP Like
-
Kwai chang caine
- Messages : 6989
- Inscription : sam. 23/sept./2006 18:32
- Localisation : Isere
Re: PHP Like
D'accord, c'est a peu pres ce que j'en avais deduit :
Navigateur ==> APACHE ==> PHP ==> APACHE ==> Navigateur
C'est vrai que ça semble logique
Ce que tu dis conforte aussi ce que j'ai lu et ce que j'ai vu et essayé
J'ai vu des exe dans le rep de PHP, j'ai essayé de les virer alors que APACHE etait en fonction, et ça a marché
Alors "j'm'ai dit" c'est qu'ils sont pas utilisés.
Deduction apparement correcte, car quand j'ai lu ce que j'ai mis juste au dessus, il y a deux methodes pour faire fonctionner PHP
La premiere la plus utilisée et aussi celle qui est la moins gourmande en ressources, comme une DLL, on charge PHP au lancement d'APACHE et je suppose qu'ils discutent ensemble comme on discute avec une DLL en appellant directement ses fonctions en interne.
C'est pour cela que j'ai pu virer les EXE
La seconde comme un exe, un peu comme les script CGI, on le lance en lui envoyant je suppose la page PHP reçue, et c'est la que je ne sais pas vraiment comment, mais peut etre un peu la meme methode que DJES a donné le lien
Cette methode lance X process, un par appel, et je pense qu'elle n'est pas viable pour un gros serveur.
La methode EXE sert aussi a faire autre chose que du HTML, a gerer son serveur, car apparement PHP a plein d'autres fonctions qui le permettent
En y reflechissant tu as raison, comment un navigateur comprendrais un texte crypté ??
Il faudrait lui insérer un plug in, ce qui reviens a ajouter chez le client un programme, ce que je ne voulais pas faire, car a ce moment la, autant creer comme l'a dit DOBRO le client et le serveur en crypté et basta
Pour le cryptage, moi je ne le voyais pas au retour, car tu as raison, maintenant que j'y reflechis en te lisant, le retour doit etre en clair pour retourner justement l'effet escompté.
Moi je le voyais a l'aller, crypter une requette PHP, mais avec les balises soit <? ?> soit d'autres.
APACHE verrait que c'est du PHP, enverrait ça à PHP, et c'est la qu'il aurait fallu décrypter avant de le transmettre a PHP.
Seulement voila, si c'est en interne, ça m'etonnerais que APACHE est prevu une sortie et une entrée afin d'y inserer un programme.
A moins que APACHE puisse accepter plusieurs "redirections" ???
Ca serait cool, a ce moment la, style on appellerait la requette en .pbhp et APACHE enverrait une requette comme en CGI a mon exe PB
Ou alors si il ne fait qu'une seule redirection et si c'est en externe, ce serait beaucoup plus facile, car il suffirait de bidouiller en renommant PBHP.exe en PHP.exe de recuperer les informations de APACHE, les decrypter, puis les envoyer au vrai PHP comme si de rien etait.
Pour la sortie on la laisserait en clair, car comme tu le dit ça retourne via APACHE au navigateur donc doit rester en clair.
C 'est cette methode qu'utilisent les bidouilleurs de VB6 pour essayer de lui faire produire des DLL standard, on renomme le linker et on le remplace par un programme qui s'intercale, ça c'est de la bidouille, ou j'my connait pas
un programme comme ça ouvrirait noir de possibilitées, on pourrait commander notre serveur avec un simple navigateur, mais en mode protégé, encore mieux qu'un mot de passe car toute la requette serait cryptée.
Ca pourrait aussi empecher les LAMER qui auraient acces au serveur physiquement, de copier ton code PHP que tu t'es fait un Q gros comme ça a coder, et se l'approprier.
Et aussi ça permettrait de rajouter ses propres commandes perso, qui ne serait pas dans PHP.
Et peut etre d'autres avantages que je ne mesure pas encore actuellement (Vous allez me dire :"Kcc qu'est ce que tu mesures actuellement ???"
)
Encore une fois cela existe car je suis tombé a paris sur des programmeurs qui se sont cassé le nez sur un code source PHP crypté.
Ils voulaient copier le source d'un programme PHP pour l'adapter et se l'approprier.
Et bien ils avaient le source mais illisible, il a bien fallu qu'il demande au vrai codeur qui avait été viré du poste, de leur donner les sources en clair.
Il l'a fait, forcé il a donné la clef USB en main propres, mais bon....si il avait voulu...il l'avalais ..et c'est le cas de le dire, les LAMER aurait été dans la merde pour avoir les sources, car il n'y aurait eu que la, qu'il les auraient trouvées
En tout cas merci beaucoup de ton aide WARKERING, car dans ce domaine encore plus que beaucoups d'autres, j'en ai grand besoin
Je reste a croire que pour l'instant c'est un sujet qui m'interesse fortement, car c'est quand meme la base de tout ce que nous utilisons actuellement et meme celle avec laquelle nous avons la chance de nous connaitre et nous parler tous les jours
Ca merite de s'y intérésser non ???
Et PB, il merite pas aussi ce venir chatouiller le grand PHP dont tout le monde vante la qualité
Ca tombe bien PHP/APACHE sont de qualité, alors PB a largement sa place a coté, car il ne fera pas tache
Et puis au niveau pédagogique c'est intéréssant aussi, non ???
Bon arrive le fameux HTML 5 qui y parait fera le lait, le beurre et le ...de la fermiere.
Alors peut etre que lui remplacera PHP ????
Mais bon...on verra a ce moment la
Navigateur ==> APACHE ==> PHP ==> APACHE ==> Navigateur
C'est vrai que ça semble logique
Ce que tu dis conforte aussi ce que j'ai lu et ce que j'ai vu et essayé
J'ai vu des exe dans le rep de PHP, j'ai essayé de les virer alors que APACHE etait en fonction, et ça a marché
Alors "j'm'ai dit" c'est qu'ils sont pas utilisés.
Deduction apparement correcte, car quand j'ai lu ce que j'ai mis juste au dessus, il y a deux methodes pour faire fonctionner PHP
La premiere la plus utilisée et aussi celle qui est la moins gourmande en ressources, comme une DLL, on charge PHP au lancement d'APACHE et je suppose qu'ils discutent ensemble comme on discute avec une DLL en appellant directement ses fonctions en interne.
C'est pour cela que j'ai pu virer les EXE
La seconde comme un exe, un peu comme les script CGI, on le lance en lui envoyant je suppose la page PHP reçue, et c'est la que je ne sais pas vraiment comment, mais peut etre un peu la meme methode que DJES a donné le lien
Cette methode lance X process, un par appel, et je pense qu'elle n'est pas viable pour un gros serveur.
La methode EXE sert aussi a faire autre chose que du HTML, a gerer son serveur, car apparement PHP a plein d'autres fonctions qui le permettent
En y reflechissant tu as raison, comment un navigateur comprendrais un texte crypté ??
Il faudrait lui insérer un plug in, ce qui reviens a ajouter chez le client un programme, ce que je ne voulais pas faire, car a ce moment la, autant creer comme l'a dit DOBRO le client et le serveur en crypté et basta
Pour le cryptage, moi je ne le voyais pas au retour, car tu as raison, maintenant que j'y reflechis en te lisant, le retour doit etre en clair pour retourner justement l'effet escompté.
Moi je le voyais a l'aller, crypter une requette PHP, mais avec les balises soit <? ?> soit d'autres.
APACHE verrait que c'est du PHP, enverrait ça à PHP, et c'est la qu'il aurait fallu décrypter avant de le transmettre a PHP.
Seulement voila, si c'est en interne, ça m'etonnerais que APACHE est prevu une sortie et une entrée afin d'y inserer un programme.
A moins que APACHE puisse accepter plusieurs "redirections" ???
Ca serait cool, a ce moment la, style on appellerait la requette en .pbhp et APACHE enverrait une requette comme en CGI a mon exe PB
Ou alors si il ne fait qu'une seule redirection et si c'est en externe, ce serait beaucoup plus facile, car il suffirait de bidouiller en renommant PBHP.exe en PHP.exe de recuperer les informations de APACHE, les decrypter, puis les envoyer au vrai PHP comme si de rien etait.
Pour la sortie on la laisserait en clair, car comme tu le dit ça retourne via APACHE au navigateur donc doit rester en clair.
C 'est cette methode qu'utilisent les bidouilleurs de VB6 pour essayer de lui faire produire des DLL standard, on renomme le linker et on le remplace par un programme qui s'intercale, ça c'est de la bidouille, ou j'my connait pas
un programme comme ça ouvrirait noir de possibilitées, on pourrait commander notre serveur avec un simple navigateur, mais en mode protégé, encore mieux qu'un mot de passe car toute la requette serait cryptée.
Ca pourrait aussi empecher les LAMER qui auraient acces au serveur physiquement, de copier ton code PHP que tu t'es fait un Q gros comme ça a coder, et se l'approprier.
Et aussi ça permettrait de rajouter ses propres commandes perso, qui ne serait pas dans PHP.
Et peut etre d'autres avantages que je ne mesure pas encore actuellement (Vous allez me dire :"Kcc qu'est ce que tu mesures actuellement ???"
)Encore une fois cela existe car je suis tombé a paris sur des programmeurs qui se sont cassé le nez sur un code source PHP crypté.
Ils voulaient copier le source d'un programme PHP pour l'adapter et se l'approprier.
Et bien ils avaient le source mais illisible, il a bien fallu qu'il demande au vrai codeur qui avait été viré du poste, de leur donner les sources en clair.
Il l'a fait, forcé il a donné la clef USB en main propres, mais bon....si il avait voulu...il l'avalais ..et c'est le cas de le dire, les LAMER aurait été dans la merde pour avoir les sources, car il n'y aurait eu que la, qu'il les auraient trouvées
En tout cas merci beaucoup de ton aide WARKERING, car dans ce domaine encore plus que beaucoups d'autres, j'en ai grand besoin
Je reste a croire que pour l'instant c'est un sujet qui m'interesse fortement, car c'est quand meme la base de tout ce que nous utilisons actuellement et meme celle avec laquelle nous avons la chance de nous connaitre et nous parler tous les jours
Ca merite de s'y intérésser non ???
Et PB, il merite pas aussi ce venir chatouiller le grand PHP dont tout le monde vante la qualité
Ca tombe bien PHP/APACHE sont de qualité, alors PB a largement sa place a coté, car il ne fera pas tache
Et puis au niveau pédagogique c'est intéréssant aussi, non ???
Bon arrive le fameux HTML 5 qui y parait fera le lait, le beurre et le ...de la fermiere.
Alors peut etre que lui remplacera PHP ????
Mais bon...on verra a ce moment la
Re: PHP Like
..................
Dernière modification par Backup le sam. 01/oct./2011 9:48, modifié 1 fois.
-
Kwai chang caine
- Messages : 6989
- Inscription : sam. 23/sept./2006 18:32
- Localisation : Isere
Re: PHP Like
Merci DOBRO de tes explications
Coooool !!! j'avais pas compris qu'on envoyait bettement en parametre la page PHP complete a l'executable
Par contre dans ce cas, comme tu le dit, il le parse, le traite, mais comment il retourne quelque chose, par quel biais ??
Coooool !!! j'avais pas compris qu'on envoyait bettement en parametre la page PHP complete a l'executable
Par contre dans ce cas, comme tu le dit, il le parse, le traite, mais comment il retourne quelque chose, par quel biais ??
Re: PHP Like
Pareil. Entrées-sorties.
Re: PHP Like
...............
Dernière modification par Backup le sam. 01/oct./2011 9:49, modifié 1 fois.
-
Kwai chang caine
- Messages : 6989
- Inscription : sam. 23/sept./2006 18:32
- Localisation : Isere
Re: PHP Like
Je suppose que tu parles de RunProgramdjes a écrit :Pareil. Entrées-sorties.
http://www.purebasic.com/french/documen ... index.html
Faut dire que le mode console, je ne l'utilise jamais
En regardant, y'a noir de trucs intéressants, dans cette rubrique:
EnvironmentVariableName
EnvironmentVariableValue
ExamineEnvironmentVariables
GetEnvironmentVariable
Merci DJES, de ta réponse
@DOBRO
Cool cette extension, apparemment tout en PHP et open source
Encore un qu'a été plus rapide que moi
Merci beaucoup a toi de ce lien c'est tres intéréssant