Quick links: Content - sections - sub sections
EN FR
Quick Search Advanced search
 
Page

  [Opened] URL Rewriting / significant

Posted by avamac on 10/27/2011 01:23

Bonjour à tous, je suis en train de développer une application avec 3 entrées différentes :

  • index.php
  • backend.php
  • admin.php

J'ai besoin d'accéder à jAuth avec les entrées backend.php et admin.php

<code>
	<entrypoint name="index" default="true">
		<url pathinfo="url1/" module="monmodule" include="urls.xml" />	 
		...
	</entrypoint>
	 
	<entrypoint name="backend" >		
		<url pathinfo="url2/" module="monmodule" include="urls.xml" />	 
		<url pathinfo="jauth/" module="jauth" include="urls.xml" />
		...
	</entrypoint>
		
	<entrypoint name="admin">
		<url pathinfo="url3/" module="monmodule" include="urls.xml" />	 
		<url pathinfo="jauth/" module="jauth" include="urls.xml" />
		...
	</entrypoint>
</code>

Voici le problème : Chaque fois que je souhaite me connecter sur admin.php, l'application me redirige sur backend.php / quand j'inverse la déclaration des points d'entrée 'admin' et 'backend' dans urls.xml, le problème s'inverse backend.php me redirige sur admin.php (Il n'y a que la première déclaration d'url de prise en compte).

Les urls déclarées sont fonctionnelles : dans mon exemple, avec le module 'monmodule' les urls suivantes sont fonctionnelles :

  • domain.tld/index.php/url1/
  • domain.tld/backend.php/url2/
  • domain.tld/admin.php/url3/

Mais toutes les urls générées par le module renvoie sur le point d'entrée index.php

Est-ce un problème de paramétrage à votre avis ?

Quand j'utilise le moteur 'simple' ou 'basic_significant' avec le paramétrage des points d'entrée dans les fichiers config je n'ai pas ce problème.

J'utilise la version 1.3 de Jelix. Merci ;)

  [Opened] URL Rewriting / significant

Bonjour,

Ce comportement est normal. Au final, tu as plusieurs URL pour une même action. Le système ne peut alors pas savoir laquelle prendre quand on lui demande l'url de tel action, il prend alors la première qui correspond.

De plus, ce n'est pas normal, de mon point de vue, d'avoir dans une même application, plusieurs pages d'authentifications.

à ta place, je ferais deux applications, bien distincts. Une pour le front, une pour le backend (et une pour l'admin ?). D'autant plus qu'au niveau sécurité, ça serait mieux, puisqu'on peut mieux cloisonner, on peut paramétrer chaque application de manière plus précise, chacune ayant à priori des requis différents en terme de sécurité.

Il faut utiliser plusieurs points d'entrées, seulement quand on veut cloisonner l'application en terme d'url ou de module, ou de type de service. ex : un point d'entrée dédié à un ou quelques modules particuliers. Ou encore, un point d'entrée dédié au services web soap, d'autres aux services web json etc. ça ne sert pas à créer plusieurs applications.

  [Opened] URL Rewriting / significant

Reply #2 Posted by avamac on 10/27/2011 15:51

Merci, j'avais déjà lu ça sur un topic du forum où tu évoquais le même type de logique mais cela me pose un problème au niveau de l'accès à mes ressources (images / sons / vidéos / etc... ).

Dans mon application j'ai 3 types de modules, par exemple :

  • metier
  • metier_admin
  • metier_superadmin

Effectivement la création d'applications multiples par site me permettrait plus de souplesse pour le développement :

  • Je pense que cela doit être possible en mettant le www commun aux trois applications, est-ce judicieux ?
  • Sinon, comment puis-je accéder à mes ressources avec 3 applications différentes ?

  [Opened] URL Rewriting / significant

Reply #3 Posted by laurentj on 10/27/2011 16:51

Je pense que cela doit être possible en mettant le www commun aux trois applications, est-ce judicieux ?

Oui, c'est une chose envisageable.

Attention cependant, elles vont du coup partager la même session. Et comme l'authentification stocke des choses en session, tu peux avoir des problèmes de sécurité si tu passes d'une appli à une autre. Un solution serait alors de mettre les points d'entrées dans des sous répertoires différents, et ainsi les cookies de sessions seront différents à cause du chemin.

Sinon, comment puis-je accéder à mes ressources avec 3 applications différentes ?

Le partage d'un www étant un peu risqué, il est préférable que chaque appli ait son propre www, (document root). Et pour partager des ressources, rien n'empêche alors de créer une constante dans le application.init.php par exemple (ou encore sous forme d'option dans la config de l'appli), indiquant le chemin des ressources (pointant alors, j'imagine, dans vers un répertoire du www de l'appli front). Et utiliser alors cette constante dans les chemins de fichiers pour manipuler les fichiers. Tu peux même avoir deux constantes : une qui définit l'URL du répertoire en question, une autre qui définit le chemin physique du répertoire.

C'est ce que j'ai fait dans un module de gestion d'images (qu'il faudrait que je publie d'ailleurs.. :) ).

  [Opened] URL Rewriting / significant

Reply #4 Posted by avamac on 10/27/2011 17:32

Je pense avoir rencontré ce cas avec ma config avec les entrypoints : D'un point d'entrée à l'autre (passage admin => superadmin et superadmin => admin). L'authentification sur l'un des deux points me donner accès à l'autre.

J'avais résolu ça en changeant le "name_session" dans le fichier de configuration auth, en changeant le "JELIX_USER" par défaut avec un nom spécifiques à chaque point d'entrée.

  • C'est ce qu'il risque de se passer ?
  • Il y a d'autres informations en sessions risquant de rentrer en conflit ?

  [Opened] URL Rewriting / significant

Reply #5 Posted by lucky on 10/27/2011 19:03

En aparte : est-ce volontaire ou as-tu oublié la Jelix 1.3 debug bar sur ton site de prod ?

  [Opened] URL Rewriting / significant

Reply #6 Posted by avamac on 10/27/2011 19:38

Oui et non - C'est juste un petit site de présentation avec pas grand chose d'important dessus. Il me sert à faire mes tests sur Jelix avec une version 'developper'. Je l'ai activé dans la journée pour essayer de comprendre mon problème et je ne l'ai pas désactivée.

C'est fait ;) je ne le ferais plus :p / donc c'était volontaire mais je sais c'est pas bien ;)

En tout cas merci de ton attention :)

 
Page
  1. URL Rewriting / significant