Nous sommes le Ven 19 Juil, 2019 14:05
Supprimer les cookies

Page 4 sur 6Précédent 1, 2, 3, 4, 5, 6 SuivantWebApps : bugs et features requests

Support et Développement des applications web portables

Mar 21 Juil, 2009 09:15

Salut,

Je ne sais pas si je suis dans le bon topic pour cela mais en créant ma Webapp je rencontre une difficulté a ce niveau là du tuto:

Code: Tout sélectionner
[UpdateMySQLPort]
Name=Update Eskuel Port
Description=Update Eskuel config with the Open MySQL Port
Type=REPLACE
File={$root_path_absolute}\App\{$ApplicationPath}\inc\config.php
SearchPattern=define\('DC_DBHOST','localhost(:\d*)?'\);
ReplaceValue=define('DC_DBHOST','localhost:{$mysql_port}');


En fait j'ai bien modifié les 3 dernières lignes en fonction de ma webapp. Le "File" pointe bien vers le fichier de config, d'ailleurs il y a bien un accès dessus (cf date de modif du fichier) donc mon chemin est correct.

Par contre le remplacement ne se fait pas, malgré le fait que j'ai bien adapté mes 2 dernières lignes au fichier de config:

config.php
Code: Tout sélectionner
// Paramètres SQL
define('DB_HOST','localhost:XXXX');
define("DB_USER","root");
define("DB_MDP","");


Lignes du startup.ini:
Code: Tout sélectionner
SearchPattern=define\('DB_HOST','localhost(:\d*)?'\);
ReplaceValue=define('DB_HOST','localhost:{$mysql_port}');


Je m'arrache les cheveux dessus depuis 1h... La solution est peut être toute bête mais je vois pas...
Merci pour vos réponses.

______________________________________
m0c
http://www.ouapi.org
m0c

Mar 21 Juil, 2009 09:54

je ne me souviens plus trop de comment est fichue le traitement de l'expression régulière (et je manque de temps pour vérifier), mais cela provient peut être des guillemets simples...

Autre piste : quand tu mets
Code: Tout sélectionner
define('DB_HOST','localhost:XXXX');

On est bien d'accord que tu n'as pas rééllement "XXXX" mais bien 4 chiffres ?
Car la ligne :
SearchPattern=define\('DB_HOST','localhost(:\d*)?'\);
cherche "(:\d*)'". C'est à dire "deux points suivi de plusieurs chiffres suivis d'un guillemet simple". Si tu as des "XXXX" dans ton config.ini, la recherche ne sera pas valide.

Bref, dans ton config.ini, mets
Code: Tout sélectionner
define('DB_HOST','localhost:0000');

(par exemple), et si ça ne marche pas, simplifie la recherche avec
Code: Tout sélectionner
SearchPattern=localhost(:\d*)
ReplaceValue=localhost:{$mysql_port}
*Nouveau venu ? Lisez les règles d'utilisation de ce forum
*Une question à poser ? Assurez vous qu'on vous répondra
*Soutenir Framasoft ? Participez à l'annuaire !
*"T'es où ?" Inscrivez vous sur la FramaMap
pyg

Avatar de l’utilisateur
Messages : 7858
Géo : Lyonnais

Mer 22 Juil, 2009 08:43

Merci beaucoup, c'était bien ça !

__________________________
m0c
http://www.ouapi.org
m0c

Ven 12 Nov, 2010 14:30

Plutôt que d'appeler x fois le Framakey Webapps Manager pour lancer x webapps je me suis dit qu'il serait peut-être plus simple de n'installer qu'une fois le FWM et de laisser les dossiers concernant les webapps autonome.

En définitive rien ne nous interdit par exemple de copier le dossier JoomlaPortable/App/data/joomla (la base de donnée) dans FluxBBPortable/App/data et le dossier JoomlaPortable/App/joomla (les pages web) dans FluxBBPortable/App pour avoir des webapps portables multiples.
Il ne reste que les scripts au démarrage à faire suivre en fonction des webapps pour que ça fonctionne quelque soit la machine où s'il y a déjà des ports occupés.

Dans la nouvelle mouture, on pourrait donc mettre le FWM dans le dossier Framakey et ne garder dans le dossier de la webapp que 4 dossiers (à adapter pour le mettre au format PAc) : app, mysql, www et scripts.
Le lanceur de la webapp vérifierait si le FWM existe à l'emplacement prévu (sinon message d'info sur comment l'installer) et si oui le lancerait (s'il n'est pas déjà actif) et ouvrirait la page de la webapp avec Framafox (ou avec le navigateur par défaut du système sinon).
Le dossiers de la webapp serait du coup beaucoup plus "lisible" pour celui qui apprend à faire des sites web (ou des webapps portables ;) ).

Comme il n'y a qu'un seul FWM on évite les problèmes de configuration des ports zwms et mysql, on facilite la mise à jour du FWM, on corrige plus rapidement les problèmes de virus, on s'économise 32Mo par webapp (23*32 = 736 Mo) et ça devrait donner la sensation d'avoir des webapps un peu plus réactives quand plusieurs tournent en même temps.

On pourrait envisager d'avoir un FWM qui détecte quelles sont les webapps installées et qui modifie le menu en ajoutant autant de sous-menu qu'il y a de webapps.
Par rapport à ça
Image
ça donnerait un sous menu FluxBB tout en haut avec Ouvrir FluxBB, Aide, Application et Scripts spécifiques (Config avancée serait dans la zone avec Infos)
idem avec un sous-menu Joomla, etc.

Au démarrage du FWM on met à jour les config de chaque webapps comme c'est déjà le cas actuellement mais plutôt que d'écrire dans chaque fichier de config, paramètre de la bdd, etc on vérifierait si les ports de la config antérieure sont bons pour gagner du temps.
Comme les config des webapps ne sont plus croisées, il fort probable que le port reste toujours le même d'une machine à l'autre à moins d'avoir un serveur web déjà installé sur la machine ou une config particulière.

Maintenant, je ne sais pas si c'est faisable facilement.
J'imagine que la partie détection des webapps ne serait pas simple, mais plutôt que de faire travailler une moulinette à chaque démarrage, je pense qu'il faudrait au premier clic sur le lanceur de la webapp que la webapp s'ajoute elle-même au catalogue des webapps connues du FWM (il faudrait aussi une options pour les supprimer proprement du coup).
JosephK

Avatar de l’utilisateur
Messages : 2221

Sam 13 Nov, 2010 21:06

Bon, en y réfléchissant un peu je me rend compte qu'il y a de gros problème au niveau de l'organisation des dossiers. Je pensais qu'on pouvait spécifier plusieurs dossiers distincts pour l'accès aux bases de données mais ça n'a pas l'air d'être aussi simple à mettre en œuvre...
(le problème est le même avec les pages web)

Sinon, je viens de découvrir que les webapps ne sont vraiment pas sécurisés pour une utilisation en production : la page d'index à la racine permet d'arrêter zmws et mysql ou d'accéder à eskuel évidemment mais ça reste assez simple de modifier le fichier App/index.php pour être tranquille ; par contre c'est très facile d'accéder au dossier data depuis le navigateur sur une autre machine et donc de copier la base de donnée pour l'exploiter sur un autre serveur...
Donc les webapps avec plusieurs utilisateurs type prométhée ou pmb deviennent difficilement intéressantes en version portable.
JosephK

Avatar de l’utilisateur
Messages : 2221

Dim 14 Nov, 2010 01:00

JosephK a écrit:Sinon, je viens de découvrir que les webapps ne sont vraiment pas sécurisés pour une utilisation en production...

Et que disais-je il y a un an et demi ? : http://www.framablog.org/index.php/post ... tion#c9096

Faut que j'écoute plus mon instinct :twisted:
Vécu : "J'ai une version crackée d'OpenOffice, c'est pour ça qu'elle est en anglais"
fat115

Avatar de l’utilisateur
Messages : 930
Géo : Ardèche ... du nord

Dim 14 Nov, 2010 02:17

En production, c'est clairement pas sécurisé comme vous venez de le dire. Mais il faut voir aussi que les web apps portables n'ont pas forcément la seule vocation à être utilisée en production.
Ce sont de très bons supports de démonstration, de test, d'habillage, de formation ou simplement de bidouillage.

Alors, dire que les apps ne sont pas à utiliser en production avec des données sensibles, c'est clairement quelque chose que j'incite à faire figurer sur le site même. Mais ce n'est pas pour ça qu'il faudrait trouver les applications même multi-utilisateurs inutiles. Elles peuvent très bien arriver à convaincre un maire ou un président de conseil général avec une démo in situ sur son propre PC. :)
Y'en a Debian ! Y'en a Debiaaaaaaan !
Lolo le 13

Avatar de l’utilisateur
Messages : 594

Dim 14 Nov, 2010 11:28

fat115 a écrit:Et que disais-je il y a un an et demi ? : http://www.framablog.org/index.php/post ... tion#c9096

:D Du coup je ne comprend pas trop comment pyg peut tenir ces propos vu qu'il a codé la page index.php à la racine et qu'il y est écrit en toute lettre de lister les dossiers sauf les dossiers data et AppInfo... et après on dit que les problème de sécurité sont entre la chaise et le clavier mais si on attend les Papy Jeannot en embuscade...

Lolo le 13 a écrit:Elles peuvent très bien arriver à convaincre un maire ou un président de conseil général avec une démo in situ sur son propre PC.

Telles quelles j'en doute et si celui qui présente sa webapp doit faire un travail de personnalisation, d'intégration de données, etc... alors ça ne rentre plus dans le cadre d'une utilisation simple de nos webapps : quand on en est bidouiller c'est qu'on doit être capable d'installer soi-même la webapp sur un serveur web et donc un ZWMS portable devrait suffire amplement non ?
En tout cas je n'ai personnellement pas attendu l'arrivée de SPIP portable pour créer le prototype du site de mon ancien lycée.
Ce sont de très bons supports de démonstration, de test, d'habillage, de formation ou simplement de bidouillage.

Après s'il s'agit de s'entrainer oui ça apporte un petit plus par rapport aux sites de démo vu qu'on peut modifier les fichiers sources, patouiller dans la base de donnée sans craindre de faire des bêtises, etc mais alors ça reste assez limité comme fonctionnalité.
Je trouve même que c'est assez pernicieux de les proposer comme bac à sable pour devenir webmaster parce que nos webapps ont une configuration très particulière qui n'a presque rien à voir à leur mise en situation sur un serveur dédié ou mutualisé...
JosephK

Avatar de l’utilisateur
Messages : 2221

Dim 14 Nov, 2010 14:32

JosephK a écrit:Telles quelles j'en doute et si celui qui présente sa webapp doit faire un travail de personnalisation, d'intégration de données, etc... alors ça ne rentre plus dans le cadre d'une utilisation simple de nos webapps : quand on en est bidouiller c'est qu'on doit être capable d'installer soi-même la webapp sur un serveur web et donc un ZWMS portable devrait suffire amplement non ?
En tout cas je n'ai personnellement pas attendu l'arrivée de SPIP portable pour créer le prototype du site de mon ancien lycée.

Oui. Quand je pensais présentation, je pensais à la présentation du travail d'intégration et de personnalisation d'une extension ou d'un design spécifique pour un client, par exemple.
J'ai toujours l'idée qu'il vaut mieux 20g de clef USB dans la poche qui viendra sur un PC local avec un écran ou un video projecteur qu'un netbook 12" où on ne voit pas grand chose du travail de design.
Après, du côté "in the cloud", c'est certain qu'il vaut encore mieux un hébergement à soi qui soit accessible de n'importe quel accès internet.
JosephK a écrit:Après s'il s'agit de s'entrainer oui ça apporte un petit plus par rapport aux sites de démo vu qu'on peut modifier les fichiers sources, patouiller dans la base de donnée sans craindre de faire des bêtises, etc mais alors ça reste assez limité comme fonctionnalité.
Je trouve même que c'est assez pernicieux de les proposer comme bac à sable pour devenir webmaster parce que nos webapps ont une configuration très particulière qui n'a presque rien à voir à leur mise en situation sur un serveur dédié ou mutualisé...

Les modifications sont dans le code de l'application elle même ou c'est une différence dans l'hébergement et dans l'utilisation de ZMWS ?
Y'en a Debian ! Y'en a Debiaaaaaaan !
Lolo le 13

Avatar de l’utilisateur
Messages : 594

Dim 14 Nov, 2010 17:49

Lolo le 13 a écrit:Les modifications sont dans le code de l'application elle même ou c'est une différence dans l'hébergement et dans l'utilisation de ZMWS ?

Ben, on utilise eskuel alors que la majorité des hébergements mutualisés proposent phpmyadmin donc en soi ça peut déjà être perturbant.
Après il y a toute l'organisation des dossiers : sur serveur dédié ou perso avec ubuntu par exemple tu auras le dossier contenant les bases de données dans le dossier /var/lib/mysql, le dossier pour les pages web dans /var/www faut s'adapter à la nouvelle organisation.
Le serveur web sera probablement apache au lieu de ZWMS, il faudra gérer les droits d'accès, etc...

Et concernant la webapp à proprement, soit il faudra analyser les "scripts spécifiques" (ceux qui nous servent à modifier automatiquement la config en fonction des ports au démarrage du FWM) pour n'avoir que quelques modifs à faire et un simple copier coller au passage en production ; soit refaire l'installation à partir de la méthode officielle et n'uploader que les fichiers qui auront été personnalisés... bref dans les deux cas c'est loin d'être à la portée de Papy Jeannot et finalement je pense que la suppression de l'étape "configuration mysql de la webapp" ne rend pas vraiment service à celui qui débute.

Après je ne dis pas que les webapps portable ne servent à rien mais pour certaines d'entre elle l'intérêt est franchement réduit si ce n'est pas utilisable comme un serveur web de production facile à installer.
JosephK

Avatar de l’utilisateur
Messages : 2221

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit