Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjours,
Encore un probleme....
Je souhaiterai inclure mes classes.
Mes classe se situent dans
library/MyClass
Donc j'ai creer une classe Char.php
Et j'essaye de l'inclure
<?php $char = MyClass_Char_Char;
Voici ma classe
<?php class MyClass_Char_Char { // }
Ou est ce que j'ai commis une erreur ?
Je tiens a preciser, j'appel ma classe dans la vue, je sais pas si sa change quelque chose...
Merci
Dernière modification par thebarbarius (21-07-2011 01:07:33)
Hors ligne
Bonjour,
Le fait d'appeler la classe dans la vue ne change rien, hormis la maintenabilité de ton application.
Il faut que tu dises à l'autoload de chercher MyClass. Pour celà, dans ton application.ini tu peux définir :
autoloaderNamespaces[] = "MyClass_"
Hors ligne
Géniale sa fonctionne !
Hors ligne
Il est possible de faire la même chose avec une méthode dans le bootstrap, mais le ini est recommandé pour faciliter les migrations en version 2 du framework.
Hors ligne
C'est marrant, moi je suis en de train de tous migrer dans le bootsrap...
Je prefere.
C'est au niveau de la securité que j'ai psa vraiment confiance au application.ini.
D'ailleurs j'aimerai le securiser.
Hors ligne
Euh ? J'ai pas tout compris là...
Si la personne a accès à ton application.ini, elle a aussi accès à ton Bootstrap.php, donc je ne vois pas trop en quoi le Bootstrap.php est plus sûr...
Si ton serveur web et ton vhost sont bien configurés, aucun des deux fichiers n'est accessible sans passer par Zend.
Hors ligne
@Ender : +1 mieu vaut utiliser le application.ini
Hors ligne
Concernant le fichier application.ini, je ne vois pas en quoi il serait moins sécurisé que le reste...
L'avantage, dans le cas où tu utilises la structure de base du framework, c'est que ton application.ini, ton bootstrap.php et tout le reste des fichiers hors de ceux contenus dans public (ou peu importe comment il est nommé dans ton archi à toi), ce qui fait que normalement par défaut tu es plus sécurisé que sur la plupart des sites.
Hors ligne
Dison que si il y a une faille, et que quelqu'un arrive a aller sur ....app/configs/application.ini toute la onfig est en clair...
En revanche si quelqu'un arrive sur bootstrap.php, il n'en tirera rien, vue que c'est un language server et que le client n'aura pas le code source, et par consequent la page sera blanche...
Simple precaution.
Hors ligne
Je vois pas comment tu pourrais avoir une faille à ce niveau mise a part avec un gros probleme de conception...mais la c’est plutôt le développeur qui aurait une faille dans sa tête xD
Mais meme en admettant une faille permettant l'accès à ce fichier tu aurais accès au répertoire application/ et donc un simple clic droit 'enregistrer sous' sur le bootstrap et y'à plus du tout d'histoire de fichier interprété par le serveur.
Hors ligne
Non on parle pas de la meme chose.
Accede a :
http://tonsite/application/configs/application.ini
et a :
http://tonsite/application/Bootstrap.php.
Regarde bien, ce que sa affiche, et ta beau faire enregistrer sous, le bootstrap ne donnera rien.... tandis qie le ini tu peux.
Hors ligne
Ce que dit Shadypierre, c'est que si tu vas sur http://tonsite/application/configs/ ou http://tonsite/application/, tu auras la liste des fichiers et là tu peux faire un clic droit et enregistrer sous.
D'un autre côté, comme je le faisais remarquer, tu n'as normalement pas accès à tes fichiers par une adresse dans ce genre, ton document root étant le dossier public.
Le seul risque dans cette architecture serait l'inclusion de ton application.ini dans une vue à l'aide d'une faille xss.
Hors ligne
Oui, fait un enregistrer sous sur bootstrap.php en allant dans http://tonsite/application/ et regarde ce que obtiens... rien
Sur le application.ini tu obtiens tous !!!!
De ce faite, pourquoi ne pas limiter une faille ? plutot que d'en ouvrir une autre avec le .ini
Hors ligne
...Tu as un très gros probleme de conception... Tu ne dois en aucun cas pouvoir accéder à http://tonsite/application/configs/application.ini
C’est pas une faille de pouvoir accéder à ce dossier c’est une bêtise de conception. La je sais pas quoi dire de plus car tu semble pas vouloir entendre raison. Même si je comprend bien ce que tu veux dire, tu ne comprend simplement pas qu'il ne s'agit pas d'une faille, mais simplement d'une incompréhension de ta part dans la manière de configurer ton site.
Hors ligne
Et imagines t'oublies d'activer PHP sur ton serveur ? Le mec il peut voir le code de tes fichiers... Sans compter si t'oublies de mettre un mot de passe au compte root...
Je te taquine ne le prends pas mal. C'est simplement pour te montrer qu'avec ta logique on peut remonter très très loin...
La parano c'est bien mais il y a des limites.
La on est en train de te dire que les fichier INI seront encore plus présents dans la V2 de Zend. Les architectes de Zend sont pas débiles, si y'avait un risque de faille quelque part, je ne pense pas qu'ils auraient choisi cette option...
Dernière modification par Ender (22-07-2011 14:38:14)
Hors ligne
la seule vrai solution c'est de faire comme je fais, mettre les .INI en dehors de l'architecture du root.
Après chaqu'un est vixé sur son avis donc je pense qu'on va arrêter d'en débattre..
Dernière modification par thebarbarius (22-07-2011 21:44:38)
Hors ligne