Discussion :

[jimmyneutron]

Bonjour,

je développe depuis quelques années avec les technologies HTML/PHP/MYSQL/CSS/JS/FLASH...

J'ai un projet à venir qui m'impose la création d'une application web sur un serveur local. De plus je dois probablement restreindre les actions utilisateurs (droits d'impressions, d'enregistrements, ...).

Je me demande vers quelle solution m'orienter.

Développer mon application locale en PHP. Utilisation d'un serveur Apache/MySQL (phpMyAdmin, Wamp) ...

Pour les mises à jour, je peux créer une page dans l'interface admin de l'application, qui permettrait de télécharger les nouveaux fichiers sur mon serveur en écrasant les anciens fichiers locaux.
OU
Paramétrer un serveur FTP pour écraser les fichiers manuellement à distance
...

Dans ce cas, les fichiers sont visibles par le client. J'ai vu qu'il y a des solutions d'encodages comme Zend Guard mais 600€ la licence (uniquement pour Guard) ce n'est pas dans mes moyens.
Je peux peut-être empêcher l'accès au root puisque je suis administrateur du serveur. Mais après je risque dans bloquer l'accès à l'application elle même.

C'est pourquoi, je me suis dit qu'il est peut-être préférable de s'orienter vers une autre solution.
Là je n'y connais pas grand chose. J'ai vu que Python était une bonne alternative à PHP et qu'il se compilait. Mais je vais peut-être passer beaucoup de temps à maitriser ce nouveau language.

Merci pour vos conseils.

[Marc3001]

J'ai un projet à venir qui m'impose la création d'une application web sur un serveur local. De plus je dois probablement restreindre les actions utilisateurs (droits d'impressions, d'enregistrements, ...).

La création d'une appli web oui mais quoi exactement??

Développer mon application locale en PHP. Utilisation d'un serveur Apache/MySQL (phpMyAdmin, Wamp) ...

C'est pas mal.

Pour les mises à jour, je peux créer une page dans l'interface admin de l'application, qui permettrait de télécharger les nouveaux fichiers sur mon serveur en écrasant les anciens fichiers locaux.
OU
Paramétrer un serveur FTP pour écraser les fichiers manuellement à distance
...

Décrit un peu plus ton appli. Mais j'pencherais plus sur l'idée d'une interface plutot que ftp.

Dans ce cas, les fichiers sont visibles par le client. J'ai vu qu'il y a des solutions d'encodages comme Zend Guard mais 600€ la licence (uniquement pour Guard) ce n'est pas dans mes moyens.
Je peux peut-être empêcher l'accès au root puisque je suis administrateur du serveur. Mais après je risque dans bloquer l'accès à l'application elle même.

Une solution ftp peut être mise en place sans donner l'accès aux sources de l'appli. C'est d'ailleurs préférable sinon c'est une belle faille de sécu....

C'est pourquoi, je me suis dit qu'il est peut-être préférable de s'orienter vers une autre solution.
Là je n'y connais pas grand chose. J'ai vu que Python était une bonne alternative à PHP et qu'il se compilait. Mais je vais peut-être passer beaucoup de temps à maitriser ce nouveau language.

PHP semble une bonne solution. Si tu ne connais pas d'autre langage axé web, je te conseille de rester sur cette option qui doit pouvoir combler tes besoins.

Détaille quand même ce que tu veux développer parceque là c'est flou...

[jimmyneutron]

La création d'une appli web oui mais quoi exactement??

Grosso modo il s'agit d'une interface de gestion de fichiers clients. Basé sur les activités de mon client, l'application doit pouvoir répondre à ses besoins : mailing, prises de RDV, suivi commercial, facturation, statistiques, ...
Nous développons l'application de A à Z car une solution Open Source, bien que très performante, ne répondra pas 100% à la demande du client.

Décrit un peu plus ton appli. Mais j'pencherais plus sur l'idée d'une interface plutot que ftp.

L'application va évoluer fortement dans le temps puisqu'elle va être créée en plusieurs fois.
Exemple :

• Phase 1 : BDD consultation/modification/suppression de fiches, ...
• Phase 2 : gestion des factures, édition des devis, intégration de documents comemrciaux, contrats, ...
• Phase 3 : gestion des RDV, rappel du planning, ...

Il faudra donc pouvoir mettre à jour les fichiers sur le serveur du client puisque l'application est 100% locale.

Voilà pourquoi je pensais faire un choix entre :

• Interface Web (téléchargement des nouveaux fichiers et copie sur le serveur)
• Serveur FTP

Une solution ftp peut être mise en place sans donner l'accès aux sources de l'appli. C'est d'ailleurs préférable sinon c'est une belle faille de sécu....

Je ne vois pas bien ce que tu décris. Pour moi les fichiers PHP de l'application se situerons dans la racine des dossiers configurés dans Apache. De fait, le client aura accès à ces fichiers, non? Car si je bloque l'accès à ces dossiers, ne vais-je pas bloquer les accès //192.168.0.1/monapplication/ aux PC connectés à l'application ?

Une contrainte est aussi de rendre cette application disponible (de manière restreinte) à distance.

[Marc3001]

Nous développons l'application de A à Z car une solution Open Source, bien que très performante, ne répondra pas 100% à la demande du client.

Ah ouais?

Il faudra donc pouvoir mettre à jour les fichiers sur le serveur du client puisque l'application est 100% locale.

Ca veux dire quoi locale? Si c'est une appli web, elle n'est pas hébergée sur le client mais sur un serveur.

Je ne vois pas bien ce que tu décris. Pour moi les fichiers PHP de l'application se situerons dans la racine des dossiers configurés dans Apache. De fait, le client aura accès à ces fichiers, non? Car si je bloque l'accès à ces dossiers, ne vais-je pas bloquer les accès //192.168.0.1/monapplication/ aux PC connectés à l'application ?

Les services Web (Apache) et FTP sont tout à fait distincts. Tu peux très bien héberger dans un répertoire tes fichiers web (/var/www par défaut pour Apache sous Debian) et tes fichiers du ftp sous une autre arbo complètement indépendante (/srv/ftp par exemple). C'est d'ailleurs préférable.

Je reste persuadé que de développer une petite IHM pour uploader des fichiers via ton appli sera plus sexy et en adéquation avec le reste de l'appli.

[jimmyneutron]

Ah ouais?

Oui. Sugar, Dolibarr, ... c'est bien mais le client veut des fonctionnalités spécifiques. Une ergonomie perso...

Ca veux dire quoi locale? Si c'est une appli web, elle n'est pas hébergée sur le client mais sur un serveur.

Comme je le disais plus haut, mon client a un serveur dans ses locaux. Donc c'est une application qui va tourner en "local" ou autrement dit Intranet.

Les services Web (Apache) et FTP sont tout à fait distincts. Tu peux très bien héberger dans un répertoire tes fichiers web (/var/www par défaut pour Apache sous Debian) et tes fichiers du ftp sous une autre arbo complètement indépendante (/srv/ftp par exemple). C'est d'ailleurs préférable.

Quelle différence entre mes fichiers WEB et FTP ?
Mes fichiers, essentiellement des fichiers PHP, sont les fichiers composants l'application elle même.
Je supposais l'installation d'un FTP pour gérer le dossier WWW, comme c'est le cas sur un serveur traditionnel. Afin de faire la mise à jour du programme à distance.

Je reste persuadé que de développer une petite IHM pour uploader des fichiers via ton appli sera plus sexy et en adéquation avec le reste de l'appli.

Entendu que dans fichiers je parle des fichiers composants le programme : les PHP et autres... et non les fichiers PDF, JPG qui correspondent aux factures, devis, documents divers que mon client va exploiter dans le programme

[Marc3001]

Oui. Sugar, Dolibarr, ... c'est bien mais le client veut des fonctionnalités spécifiques. Une ergonomie perso...

Et pourquoi ne pas partir d'un projet existant le plus proche possible du besoin et éventuellement d'en modifier que les spécificités ?

Comme je le disais plus haut, mon client a un serveur dans ses locaux. Donc c'est une application qui va tourner en "local" ou autrement dit Intranet.

Ah OK en intranet...

Quelle différence entre mes fichiers WEB et FTP ?
Mes fichiers, essentiellement des fichiers PHP, sont les fichiers composants l'application elle même.
Je supposais l'installation d'un FTP pour gérer le dossier WWW, comme c'est le cas sur un serveur traditionnel. Afin de faire la mise à jour du programme à distance.

OK je comprends mieux ce que tu décris. Oui ftp ou sftp est une bonne solution pour mettre à jour ton application sur le serveur du client.
Si c'est un serveur du client, oui, il aura accès aux sources du programme.

Cela est-il vraiment génant? De quoi as-tu peur ?
Au pire tu blindes le contrat et n'effectue du support que si le client n'effectue aucune modification du code...

Entendu que dans fichiers je parle des fichiers composants le programme : les PHP et autres... et non les fichiers PDF, JPG qui correspondent aux factures, devis, documents divers que mon client va exploiter dans le programme

Ok comme dit plus haut FTP ou SFTP est une bonne solution pour la mise à jour de l'appli. Cela ne change rien par rapport à une solution hébergée à cela près que la machine est physiquement chez le client.

[jimmyneutron]

Et pourquoi ne pas partir d'un projet existant le plus proche possible du besoin et éventuellement d'en modifier que les spécificités ?

Parce que je ne connais pas suffisamment ces projets. Les appréhender et les modifier risque de me prendre beaucoup de temps sans que je sache vraiment si à un moment ou à un autre je ne vais pas être bloqué en fonction de la demande du client. Il a vraiment des besoins très variés.

Cela est-il vraiment génant? De quoi as-tu peur ?
Au pire tu blindes le contrat et n'effectue du support que si le client n'effectue aucune modification du code...

Je n'ai pas peur particulièrement. Je voulais juste qu'il ne fouille pas dedans au risque effectivement d'y faire une bêtise... aussi pour protéger mon travail ...