Suppression des moteurs d'urls
Michael Mortchelewicz
Tout d'abord si j'ai bien compris, Laurent tu voudrais n'utiliser que significant mais est ce que ça veut dire que simple ne marchera plus ?
Pourrais tu nous donner des précisions sur l'idée que tu as en tete ?
--
Laurent Jouanneau
oui, il n'y aurait plus de moteur "simple" ni de "basic_significant".
Bref, plus de notion de moteur d'URL en fait. Il ne resterait donc que
le moteur "significant". On renomera ce composant "moteur d'URL" ou
encore "Routeur d'url". Sachant aussi que l'on pourra définir des urls
comme dans basic_significant, c'est à dire avoir la possibilité de
définir des urls génériques qui contiendrait le nom du module, du
controleur et de l'action, évitant ainsi à devoir définir des urls
pour chaque action (ce qui n'est pas nécessaire pour des backoffice
par exemple).
Et sachant qu'il n'y aura plus cette notion de plugin de moteur d'url,
on va pouvoir y gagner un petit peu en perf par rapport au moteur
"significant" d'aujourd'hui.
La suppression du moteur "simple" te posera-t-il problème ?
Michael Mortchelewicz
index.php en significant
admin.php en simple
la raison est simple, je suis en php5_cgi (ovh release 2) et il gere mal le pathinfo donc j'utilise le petit truc du
RewriteRule ^(.*)$ index.php?jpathinfo=/$1 [L,QSA]
et donc sur admin.php je ne peux pas avoir de rewrite puisque tout vas sur index.php et donc je passe par simple.
En plus simple a plusieurs avantages:
- j'ai pas a configurer quoi que ce soit çà fonctionne naturellement puisque c'est dur pur GET et personnellement je trouve dommage de perdre même 5min a
configuré des urls pour un backoffice puisque de toute façon ce n'est pas fais pour être vu par Google.
- Il ne necessite pas mod_rewrite
Tu ne crois pas que justement le simple de part sa simplicite doit être gardé ?
--
manooweb
tu es certain ?
Parce tout ce que je fais (en grande partie) est sur du mutualisé OVH
(donc CGI) et je n'ai noté aucun pb.
Je mais les BO sur un sous-domaine et le FO sur le sous-domaine www
par exemple avec Jelix entre les 2. Je ne mélange pas les points
d'entrée il est vrai.
Le BO en basic_significant pour avoir un minimum des urls cool et le
FO en significant en utilisant au max jUrl et le plugin jfullurl dans
les templates.
çà marche impec et c'est royal comme çà. Simplissime pour le BO et
optimisé pour le référencement côté FO.
SI çà va encore dans le sens de la simplification en gardant les
avantages, çà n'est que mieux !
Michael Mortchelewicz
oui effectivement si tu fais comme ca tu n'a pas de probleme car tu as donc plusieurs htaccess mais moi vu que j'ai qu'un seul htaccess qui pointe sur index, je suis oblige d'utiliser admin en simple mais c'est pas un mal car je ne me soucie pas des urls dans le backoffice.
--
Laurent Jouanneau
> en fait oui, car voila comment je configure la plupart de mes sites:
>
> index.php en significant
> admin.php en simple
>
> la raison est simple, je suis en php5_cgi (ovh release 2) et il gere mal le
> pathinfo donc j'utilise le petit truc du
> RewriteRule ^(.*)$ index.php?jpathinfo=/$1 [L,QSA]
>
> et donc sur admin.php je ne peux pas avoir de rewrite puisque tout vas sur
> index.php et donc je passe par simple.
Avec les r�gles de r��criture, tu peux � mon avis te d�brouiller pour
faire en sorte que les urls commencant par admin/, tu redirige vers
admin.php, et le reste vers index.php.
>
> En plus simple a plusieurs avantages:
> - j'ai pas a configurer quoi que ce soit �� fonctionne naturellement
> puisque c'est dur pur GET et personnellement je trouve dommage de perdre
> m�me 5min a
> configur� des urls pour un backoffice puisque de toute fa�on ce n'est pas
> fais pour �tre vu par Google.
je pense que la configuration sera vraiment vite faite, puisque le
urls.xml sera cr�e avec le minimum � la creation de l'appli.
> - Il ne necessite pas mod_rewrite
non plus sur des confs serveur plus classique...
>
> Tu ne crois pas que justement le simple de part sa simplicite doit �tre
> gard� ?
vu les probl�mes que �a pose actuellement, �a n'est pas si simple que
�a, vu les nombreuses questions qu'il y a sur le sujet.
Et puis il y a des limitations � avoir plusieurs moteurs d'url. Un
exemple, tu ne peux pas utiliser jUrl::get pour r�cup�rer une url du
point d'entr�e index.php � partir de admin.php et vice versa.
Laurent
>
> 2012/1/11 Laurent Jouanneau<ljoua...@gmail.com>
>
>> Le 11 janvier 2012 16:52, Michael Mortchelewicz<mor...@gmail.com> a
>> �crit :
>>> Le thread concernant les am�liorations � apporter � Jelix �tant un peu
>>> confus, j'ouvre une nouvelle discussion.
>>>
>>> Tout d'abord si j'ai bien compris, Laurent tu voudrais n'utiliser que
>>> significant mais est ce que �a veut dire que simple ne marchera plus ?
>>>
>>> Pourrais tu nous donner des pr�cisions sur l'id�e que tu as en tete ?
>>>
>>
>> oui, il n'y aurait plus de moteur "simple" ni de "basic_significant".
>> Bref, plus de notion de moteur d'URL en fait. Il ne resterait donc que
>> le moteur "significant". On renomera ce composant "moteur d'URL" ou
>> encore "Routeur d'url". Sachant aussi que l'on pourra d�finir des urls
>> comme dans basic_significant, c'est � dire avoir la possibilit� de
>> d�finir des urls g�n�riques qui contiendrait le nom du module, du
>> controleur et de l'action, �vitant ainsi � devoir d�finir des urls
>> pour chaque action (ce qui n'est pas n�cessaire pour des backoffice
>> par exemple).
>>
>> Et sachant qu'il n'y aura plus cette notion de plugin de moteur d'url,
>> on va pouvoir y gagner un petit peu en perf par rapport au moteur
>> "significant" d'aujourd'hui.
>>
>> La suppression du moteur "simple" te posera-t-il probl�me ?
>>
>
>
>
Vincentv
Laurent Jouanneau
Vincentv
Charles
utilisant pleinement les points d'entrées notamment pour séparer le
front du back entre autre, j'aurai voulu savoir pourquoi il ne faut
pas le faire (j'ai cherché dans la documentation mais rien trouvé) ???
Sinon, comme suggestion concernant le prochain moteur d'url, ce serait
de permettre de localiser facilement les urls comme je l'explique
ici : http://jelix.org/forums/forum/1-jelix-general/posts/9261-8998-url-significant-et-locale
Depuis l'écriture de mon message sur le forum, je me suis fait un
plugin d'url significant_locale qui me permet d'avoir des urls dans
les langues utilisées par l'application, ça fonctionne parfaitement
bien et c'était vraiment un manque que je n'avais pas pu combler
autrement...
++
> j'y ai pensé, mais pour jelix2 parce que là ça casse beaucoup de choses :-)
>
Florent Marbot
Bonjour moi j'ai trouvé celà :
http://jelix.org/articles/fr/manuel-1.3/creer-application/creer-administration
Je cite :
"[...]Important : pour des raisons de sécurité, de facilité d'utilisation du framework etc, il est fortement recommandé de créer une application spécifique pour une interface d'administration. [...]"
Sachant que l'on peut configurer un jAuth pour chaque entrypoint, je me pose la même question.
Cordialement,
Florent
Laurent Jouanneau
Plusieurs raisons de séparer back et front, donc faire deux applis distincts.
1) pour moi, une interface d'admin n'a rien à faire sur un site
"public". Mettre le back office sur un sous domaine spécifique (voir
un autre domaine), sécurise l'application dans une certaine mesure. Il
devient plus difficile pour un "pirate" de trouver comment accéder à
l'admin (quoique, si vous le mettez sur un sous domaine "admin" ;-) ).
Regardez vos logs apaches en production, vous trouverez plein de bots
qui tentent d'accéder à des urls comme admin.php, administrator.php
etc... (au passage, si vous avez du phpmyadmin, vous avez interêt à ne
pas le mettre dans un répertoire nommé "phpmyadmin" ou autre nom
approchant).
Bref, mettre l'admin sur un autre domaine, donc une autre appli,
"cache" un peu plus l'admin.
2) cela permet d'avoir une conf apache particulière pour le site
d'admin : authentification apache (en plus de l'authentification
jelix), autoriser l'accés à partir de certaines ip, HTTPS etc etc...
Idem pour le front : permettre d'avoir une conf apache particulière elle-aussi.
C'est d'autant plus vrai pour les sites qui ont pas mal de trafic. On
mettra en place alors des solutions comme du reverse proxy / load
balancing etc.. Une interface d'admin n'a pas besoin de ça.
3) à l'usage, et à la lecture des questions sur le forum, on se rend
compte qu'avoir plusieurs points d'entrées n'est pas si trivial que
ça. ça peut poser des problèmes pour l'authentification, pour les urls
etc.. et d'un point de vue général, au niveau de la configuration,
avec les scripts en ligne de commande etc. Et c'est d'ailleurs pour ça
que je me pose la question, pour jelix2, de voir si on continue à
permettre plusieurs points d'entrées ou pas.
4) en fin de compte, une admin, c'est une application à part entière
d'un point de vue fonctionnel. Donc avoir une application jelix dédié
est logique, sachant que rien n'empêche d'avoir des modules en commun
avec le front.
Le but de tout ça, est de simplifier l'utilisation du framework. Mais
si il y a trop de gens qui veulent garder les moteurs d'url etc,
discutons-en :-) (peut être garder ça pour jelix 2 ?)
Charles
Rien ne m'empêche de restreindre l'accès à mon point d'entrée admin à
un domaine particulier, ainsi, il est totalement bloqué du public,
avec Apache, ça se fait simplement, idem pour Nginx et co...
On se sert aussi des points d'entrée pour les web services et c'est
vraiment super pratique de pouvoir avoir une configuration différente,
exemple : nous avons pu mettre en place une autre méthode
d'authentification différente, désactiver autolocale pour l'api, etc..
Enlever les points d'entrée serait vraiment une grosse perte pour
Jelix, je me vois très mal créer une nouvelle application pour tous
les points d'entrées actuels, en bref, ce serait bloquant pour notre
appli...
Concernant le moteur d'url, j'ai abordé le sujet dans mon précédent
message, oui, il a des lacunes et j'espère que l'on pourra voir un
moteur d'url gérant les urls en plusieurs langues...
>
>
>
>
>
>
>
>
>
> > Bonjour moi j'ai trouvé celà :
> > Je cite :
> > "[...]Important : pour des raisons de sécurité, de facilité d'utilisation du
> > framework etc, il est fortement recommandé de créer une application
> > spécifique pour une interface d'administration. [...]"
>
> > Sachant que l'on peut configurer un jAuth pour chaque entrypoint, je me pose
> > la même question.
>
> > Cordialement,
>
> > Florent
>
> > Le 17/01/2012 14:54, Charles a écrit :
>
> > Salut,
> > utilisant pleinement les points d'entrées notamment pour séparer le
> > front du back entre autre, j'aurai voulu savoir pourquoi il ne faut
> > pas le faire (j'ai cherché dans la documentation mais rien trouvé) ???
> > Sinon, comme suggestion concernant le prochain moteur d'url, ce serait
> > de permettre de localiser facilement les urls comme je l'explique
> > ici :