Discussion :

[gargarrel]

Bonjour,

dans le cadre d'un projet je souhaite proposer un traitement à mes clients sans bien sur qu'il puisse récupérer mon code.

Vu que mon code doit leur fournir certaines informations à afficher, l'appel à mon traitement ne peut être asynchrone et leur process doit donc attendre la fin du mien pour continuer.

Je commence à bien toucher ma bille en php, mais la gestion de la sécurité et des accès distants est un domaine qui reste obscur !

Quel doit être la solution à utiliser comme appel ?
require , readfile , include ?

Sachant que mes prerogatives sont :
- Rassurer au maximum le client, car executer un script distant me semble dangereux, une de ses fonctions est elle plus securisé pour le client ?
- Mon code source php doit absolument être protégé.


Par avance merci

[stealth35]

pourquoi script distant ? c'est le client qui fait un include sur son serveur ?

[gargarrel]

oui effectivement c'est le client qui sur son serveur fait un appel vers mon script.

Et comme je le disais precedement, j'ai du mal avec la gestion des fichiers distants et la sécurité.

Je n'ai pas l’expérience ni la tournure d'esprit pour imaginer quel pourrait être les actions que l'on peut effectuer avec des appels à des scripts distants.

Donc si je veux arriver à vendre ma solution à des clients, je dois pouvoir leur assurer qu'il ne craigne rien. Tout en gardant precieusement mon code à l'abri !

C'est possible ou bien je reve un peu

[stealth35]

si tu veux qu'il fasse un include, ton code la source du code doit être visible, et il sera exécuter coté client, la sécurité ne viens pas de ton coté mais du leur, puisque ton script agira directement sur leurs serveur

[gargarrel]

Merci de ton attention à mon probleme !

Mais je pense que je n'ai pas été trés clair :

Je veux proposer à des clients une solution à leur problème, la generation automatique d'image et de document qui serait disponible sur mon serveur.

Donc sur mon serveur j'ai un script en php autonome que mes clients pourront appeler avec certains paramètres :

Donc sur le serveur de mes futurs clients :

leur code => appel de mon code => leur code pour récupérer les documents générés sur mon serveur .

Donc j'ai commence à farfouiller et je pense que la fonction readfile répond à mon problème.

L'essentiel est de pouvoir rassurer mes clients qui ne me connaisse pas encore d'accepter de faire un appel à mon script.
Je pense qu'avec readfile le script est uniquement interprété sur mon serveur et qu'il n'y a pas d'information de session qui peuvent transiter entre les serveurs.

Mais n'ayant jamais vraiment cogité sur ces problèmes j'aurais voulu savoir si il y avait des failles ou des hacks auquel je n'aurais pas pensé !

Et la suite est de savoir si les clients peuvent récupérer mon code source, ce que je cherche à éviter histoire de vendre ma solution à d'autres clients !

[stealth35]

si c'est juste ça, fait du REST ou n'importe quel autre webservice

[RunCodePhp]

la sécurité ne viens pas de ton coté mais du leur

Le risque ne serait il présent pour les 2 parties ?

Pour récupérer un code Php sur un serveur pour l’exécuter sur le sien (le client en faite) il faut activer la directive allow_url_fopen il me semble.

Du coup, n'importe qui aura l'occasion de récupérer n'importe quel contenu sur le serveur, à défaut de limiter ça (.htaccess par exemple).
Une erreur ou un oubli est toujours possible, et rien ne dit qu'un plus malin que les autres parvient à récupérer un contenu plus ou moins confidentiel.
(fichier config, ou autre).


Un autre moyen serait de créer un WebService (ou plusieurs), comme par exemple Google, Facebook (pour les plus connues).
Ces Webservices peuvent se faire de plusieurs manières, d'une simple requête HTTP (genre Ajax) en passant par des solutions plus évoluées comme REST, SOAP (du XML en gros).

L'idée générale est de fournir des données plus ou moins bruts, et c'est au client d'adapter son code pour consommer les différents services.
Ceci dit il vrai que créer des WebServices n'est pas simple (SOAP par exemple).
Mais c'est en général plus cadré, grosso modo, ne sera fourni que ce qui est autorisé (il peu avoir une authentification, du SSL, etc ...).

Théoriquement il n'y aura pas plus de risque qu'un site Web.

[stealth35]

Le risque ne serait il présent pour les 2 parties ?

Pour récupérer un code Php sur un serveur pour l’exécuter sur le sien (le client en faite) il faut activer la directive allow_url_fopen il me semble.

non juste du coté du include, puisque au final tu récupérés qu'un fichier texte avec du PHP dedans

[gargarrel]

Pour récupérer un code Php sur un serveur pour l’exécuter sur le sien (le client en faite) il faut activer la directive allow_url_fopen il me semble.

Du coup, n'importe qui aura l'occasion de récupérer n'importe quel contenu sur le serveur, à défaut de limiter ça (.htaccess par exemple).
Une erreur ou un oubli est toujours possible, et rien ne dit qu'un plus malin que les autres parvient à récupérer un contenu plus ou moins confidentiel.
(fichier config, ou autre).

La directive allow_url_fopen permet à des services php sur un serveur d'acceder à des fichiers via des urls et pas uniquement en interne.
Sinon effectivement ça transformerait ton serveur en passoire en une seconde

Je ne connaissais pas REST et en lisant justement une autre discussion sur le forum j'ai du mal à voir la subtilité et la difference par rapport à un protocole http classique.
Il semblerait que l'url permette un appel direct à des fonctions mais dans ce cas je ne vois pas trop la difference avec l'url rewriting sous apache

Desolé de rester aussi evasif sur mon projet mais j'ai pas mal de contraintes professionnelles ce qui ne favorise pas la discussion

Il me faut une technique qui soit vraiment le plus simple à installer chez le client (une seule ligne de code à installer c'est un sacré argument commercial)
et que la suite du déroulement du code chez le client attende absolument la fin de mon script !
Et je me demande si les webservices ne sont pas asynchrone justement.

De plus je suis entrain d'y réfléchir mais si php est installé sur mon serveur, et apache correctement paramétré il me parait impossible de pouvoir récupérer du code source php !

Merci encore de prêter attention à mes petits soucis !

[stealth35]

Non c'est pas une passoire le allow_url_fopen, mais il faut que le client fasse confiance au serveur (donc à toi)

Le REST utilise HTTP pour le CRUD, donc GET, POST, PUT, DELETE ....
Par contre si ton service fait de l'asynchone c'est plus compliquer coté client, puisqu'il va falloir checker le status

[gargarrel]

Bon je vais aller voir du cote du REST (on dirait le SPECTRE de james bond mais du cote PHP)

Je vous remercie encore pour vos contributions

[RunCodePhp]

La directive allow_url_fopen permet à des services php sur un serveur d'acceder à des fichiers via des urls et pas uniquement en interne.
Sinon effectivement ça transformerait ton serveur en passoire en une seconde

J'avais cru que tu fonctionnais comme ça.

Ceci dit, fournir un contenu Php brut, même quelque peu cadrer, dans tous les cas le contenu passe par HTTP.
Ca reste un moyen quelque peu détourné du allow_url_fopen.
Personnellement je le perçois ainsi.


C'est toute la différence avec un WebService qui lui prévoit (théoriquement) que de fournir des données brut venant de sa Bdd par exemple, et non du code à exécuter par le client.
C'est franchement pas la même chose.
(A moins de fournir du code Php à faire exécuter par le client, ce qui équivaut à un retour à la case départ, mais c'est pas le but justement)

[gargarrel]

Bon, je crois que définitivement on ne parle pas de la même chose.

Le code PHP sur mon serveur ne renvoit aucune information, il génère juste des fichiers sur mon serveur. Ces mêmes fichiers que mon client pourra utiliser ou afficher sur son site.

Je ne renvois aucune information de base de données, aucune instruction d'aucune sorte.

A ce moment là, je pense que le client ne peut pas avoir accés au code source de mon fichier PHP, il peut l'executer mais pas le voir (vous m'arretez si je me trompe)

Donc je reviens une fois de plus sur mon problème d'un point de vue commerciale :
Puis je affirmer au client que par exemple en utilisant la fonction readfile("http://monserveur.com/mon-code"), il ne me transmet pas de variable ni de variable de session et que donc SON serveur ne craint absolument rien !

On va y arriver

[stealth35]

C'était plus par rapport a ce que tu disais que ça portait a confusion sur le allow_url_fopen, c'est pour ça qu'on te le proposais, ce que tu cherche a faire s'appelle un WebService, à toi ensuite du choisir le techno que tu veux, regarde aussi vers le SOAP, coté client ça sera assez simple

[RunCodePhp]

Bon, je crois que définitivement on ne parle pas de la même chose.

Oui et non

Je rejoins stealth35 que ce que tu veux faire c'est ni plus ni moins un Webservice, c'est la manière de faire qui est différente.

Les Webservices reposant sur REST ou SOAP se basent sur des techniques plus ou moins connues, cadrées.
Le gros avantage si c'est bien fait c'est que ce Webservice pourra être exploité par n'importe quel client, quelque soit le langage utilisé (Php, Asp, etc ...), c'est donc nettement plus ouvert.

A l'inverse, ce que tu fais risque fort d'être très spécifique, beaucoup moins standard voir pas du tout.
Par conséquent il sera plus difficile de faire un code client suffisamment standard lui aussi pour répondre à des besoins plus ou moins communs.


C'est là où il peu avoir un gros frein, car développer un Webservice peu être un énorme travail.
Développer un Webservice qui pourra être exploité par 1 ou 2 client ça ne vaut peut être pas le coup.
Par contre le faire pour 10, 100, 1000 clients (ou par millions comme GG, FB) là ça vaut le coup.

Sans compter que la plupart des sites qui proposent des Webservice fournissent de la doc et même les codes coté clients afin de favoriser leur exploitation (voire nous rendre dépendant).

Rajouter à cela l'évolution, la maintenance du Webservice sans que les codes clients qui le consomme ne "plantent" pas, ça rajoute de la complexité.


Bref ... il faut standardiser pour que le travail soit rentable.
D'où SOAP, REST, etc ...


Tout ça sauf erreur.

[gargarrel]

Je comprends bien mieux, effectivement les webservices vont me permettre le multi-plateforme, et une gestion des erreurs plus precises, et ne pas avoir besoin d'un paramétrage spécifique comme allow_url_fopen

Je viens de commencer à mettre le nez dedans, tudieu, ça m'a l'air bien rigolo

Ma solution va avoir pour client de nombreux site de ecommerce, donc je pense que dans l'ensemble la solution utilisé sera PHP.

Et en regardant un peu il semblerait qu'il existe des solutions permettant une installation legere du cote client (exemple NuSOAP) .. Car demander à un client de modifier le parametrage ou l'installation de son serveur, commercialement ça va etre rock and roll !

Edit : Il semblerait que REST soit encore plus simple.

En tout cas je vous remercie grandement pour toutes vos reponses et votre patience !

Bonne fin de week end

[stealth35]

Et en regardant un peu il semblerait qu'il existe des solutions permettant une installation legere du cote client (exemple NuSOAP) .. Car demander à un client de modifier le parametrage ou l'installation de son serveur, commercialement ça va etre rock and roll !

Y'a deja l'extension SOAP dans PHP, et elle est dans tout les distrib standard