mais quand je clique sur le lien et que je veux voir les variables de
session, aucune ne passe. De plus, le fichier de la session est vide
dans le cache (longueur = 0).
Est-ce que Joomla est cryptique au point d'avoir des sessions
(session_start me dit que la session est déjà lancée) mais sans qu'on
puisse utiliser ces sessions sans passer par Joomla ? Mon client veut
utiliser Joomla pour la gestion des abonnés mais je ne tiens pas à
passer 3 mois à décoder la documentation interne de Joomla d'autant
plus qu'elle est incomplète (aucun mot sur la reprise de session et
le relais vers une application externe depuis Joomla sauf le lien
simple sans passage de session, donc public).
Joomla crée pourtant un fichier de session dans le cache de EasyPHP,
donc je vois mal pourquoi on placerait les variables de session
ailleurs, surtout celles que je créé avec $_SESSION !!!
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Denis Beauregard
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard écrivait dans fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien hors-Joomla ?
Je dois interfacer une application existante depuis Joomla. Pour cette fin, j'ai créé un module contenant ces lignes :
...
J'ajoute que session_id() affiche quelque chose mais que SID est vide, ceci dans le module Joomla que j'ai écrit. Donc, au départ, il y a une anomalie !
Denis
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard
<denis.b-at-francogene.com.invalid@nospam.com.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien
hors-Joomla ?
Je dois interfacer une application existante depuis Joomla. Pour
cette fin, j'ai créé un module contenant ces lignes :
...
J'ajoute que session_id() affiche quelque chose mais que SID est
vide, ceci dans le module Joomla que j'ai écrit. Donc, au départ,
il y a une anomalie !
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard écrivait dans fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien hors-Joomla ?
Je dois interfacer une application existante depuis Joomla. Pour cette fin, j'ai créé un module contenant ces lignes :
...
J'ajoute que session_id() affiche quelque chose mais que SID est vide, ceci dans le module Joomla que j'ai écrit. Donc, au départ, il y a une anomalie !
Denis
Denis Beauregard
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard écrivait dans fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien hors-Joomla ?
J'ai découvert une partie de la réponse et elle ne me plaît pas beaucoup !
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Denis
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard
<denis.b-at-francogene.com.invalid@nospam.com.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien
hors-Joomla ?
J'ai découvert une partie de la réponse et elle ne me plaît pas
beaucoup !
Au lieu d'utiliser la session de PHP ou de laisser le développeur
le faire, on vide toutes les variables et on les place dans une
base de données (ce qui explique peut-être pourquoi joomla est si
lent).
Bon, maintenant, comment simuler une session quand session_start et
tout le mécanisme ne peut pas être utilisé ?
Le Tue, 29 Sep 2009 11:17:12 -0400, Denis Beauregard écrivait dans fr.comp.infosystemes.www.auteurs:
Bonjour,
Est-ce que Joomla détruit la session quand on clique sur un lien hors-Joomla ?
J'ai découvert une partie de la réponse et elle ne me plaît pas beaucoup !
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Denis
Mickaël Wolff
Denis Beauregard wrote:
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour qu'il utilises celui de Joomla.
Au lieu d'utiliser la session de PHP ou de laisser le développeur
le faire, on vide toutes les variables et on les place dans une
base de données (ce qui explique peut-être pourquoi joomla est si
lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
Bon, maintenant, comment simuler une session quand session_start et
tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour
qu'il utilises celui de Joomla.
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour qu'il utilises celui de Joomla.
Le Wed, 30 Sep 2009 00:35:22 +0200, Mickaël Wolff écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour qu'il utilises celui de Joomla.
J'avais pensé faire l'inverse, soit trouver comment Joomla gère ses sessions et adapter le code pour au moins prendre quelques variables (typiquement, le courriel et le numéro d'adhérent, le reste étant superflu pour mon application). Comme il s'agit de la consultation d'une base de données disponible depuis quelques années dans des bibliothèques publiques et privées, ce n'est pas aussi critique que toute la gestion du site. Donc, je n'utiliserais que 3 informations, le numéro de session et les courriels et numéros pris dans la table des sessions, puis je lancerais la session habituelle de PHP.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Denis
Le Wed, 30 Sep 2009 00:35:22 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> écrivait dans
fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
Au lieu d'utiliser la session de PHP ou de laisser le développeur
le faire, on vide toutes les variables et on les place dans une
base de données (ce qui explique peut-être pourquoi joomla est si
lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp
dont l'accès est plus rapide que des enregistrements dans une base
mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse
pas à d'autres sites sur le même serveur une porte ouverte sur nos
visiteurs.
Bon, maintenant, comment simuler une session quand session_start et
tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour
qu'il utilises celui de Joomla.
J'avais pensé faire l'inverse, soit trouver comment Joomla gère ses
sessions et adapter le code pour au moins prendre quelques variables
(typiquement, le courriel et le numéro d'adhérent, le reste étant
superflu pour mon application). Comme il s'agit de la consultation
d'une base de données disponible depuis quelques années dans des
bibliothèques publiques et privées, ce n'est pas aussi critique
que toute la gestion du site. Donc, je n'utiliserais que 3
informations, le numéro de session et les courriels et numéros pris
dans la table des sessions, puis je lancerais la session habituelle
de PHP.
Le hic, c'est que mon application sera limitée à la version courante
de Joomla (donc, si Joomla change sa façon de gérer les sessions, il
faudra modifier le code).
Le Wed, 30 Sep 2009 00:35:22 +0200, Mickaël Wolff écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
Au lieu d'utiliser la session de PHP ou de laisser le développeur le faire, on vide toutes les variables et on les place dans une base de données (ce qui explique peut-être pourquoi joomla est si lent).
Pas nécessairement. C'est une technique courante pour gérer les sessions.
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Bon, maintenant, comment simuler une session quand session_start et tout le mécanisme ne peut pas être utilisé ?
Tu peut personnaliser le gestionnaire de session natif de PHP pour qu'il utilises celui de Joomla.
J'avais pensé faire l'inverse, soit trouver comment Joomla gère ses sessions et adapter le code pour au moins prendre quelques variables (typiquement, le courriel et le numéro d'adhérent, le reste étant superflu pour mon application). Comme il s'agit de la consultation d'une base de données disponible depuis quelques années dans des bibliothèques publiques et privées, ce n'est pas aussi critique que toute la gestion du site. Donc, je n'utiliserais que 3 informations, le numéro de session et les courriels et numéros pris dans la table des sessions, puis je lancerais la session habituelle de PHP.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Denis
Mickaël Wolff
Denis Beauregard wrote:
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus rapide, il peut etre bloquant et entrainer des pertes de performances importantes. Avec une dizaine d'accès disque, on ne voit pas de différences. Mais dès que les utilisateurs sont nombreux, peut-etre 100k, le passage par une base de données réduirait le nombre d'accès disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut penser au cache de MySQL.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session étrangère.
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp
dont l'accès est plus rapide que des enregistrements dans une base
mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse
pas à d'autres sites sur le même serveur une porte ouverte sur nos
visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus
rapide, il peut etre bloquant et entrainer des pertes de performances
importantes. Avec une dizaine d'accès disque, on ne voit pas de
différences. Mais dès que les utilisateurs sont nombreux, peut-etre
100k, le passage par une base de données réduirait le nombre d'accès
disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut
penser au cache de MySQL.
Le hic, c'est que mon application sera limitée à la version courante
de Joomla (donc, si Joomla change sa façon de gérer les sessions, il
faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session
étrangère.
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus rapide, il peut etre bloquant et entrainer des pertes de performances importantes. Avec une dizaine d'accès disque, on ne voit pas de différences. Mais dès que les utilisateurs sont nombreux, peut-etre 100k, le passage par une base de données réduirait le nombre d'accès disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut penser au cache de MySQL.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session étrangère.
Le Fri, 02 Oct 2009 21:08:53 +0200, Mickaël Wolff écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus rapide, il peut etre bloquant et entrainer des pertes de performances importantes. Avec une dizaine d'accès disque, on ne voit pas de différences. Mais dès que les utilisateurs sont nombreux, peut-etre 100k, le passage par une base de données réduirait le nombre d'accès disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut penser au cache de MySQL.
Selon mon expérience sur un autre site (une autre association), il y aura autour de 100 utilisateurs par jour, avec éventuellement des pointes à 500 par jour (cas extrême). Sur mon site perso, autour de 500 à 1000 visiteurs par jour, j'utilise /tmp mais il n'y a pas de partie privée. Par contre, j'ai un anti-aspirateur (mon site perso a 90 000 documents html).
Cela dit, j'ai vu où Joomla plaçait ses sessions : dans une base SQL. En gros, ils ont le numéro de la session, le nom d'usager et son courrier, et les variables d'environnement. Pour mes besoins, je pourrais à la limite utiliser le numéro de session pour valider que c'est lancé depuis Joomla et non directement, mais il reste que ce sera limité à cette version. Avec un peu de chance, Joomla ne changera pas cette partie de façon importante durant les prochaines années.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session étrangère.
En fait, j'ai vu qu'ils avaient une alternative. Le code de Joomla est archi-compliqué avec des classes qui s'enchaînent et du code qui change à la volée (du style include($nom-du-module) ). Mon code est indépendant, une fois lancé.
Denis
Le Fri, 02 Oct 2009 21:08:53 +0200, Mickaël Wolff
<mickael.wolff@laposte.net> écrivait dans
fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp
dont l'accès est plus rapide que des enregistrements dans une base
mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse
pas à d'autres sites sur le même serveur une porte ouverte sur nos
visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus
rapide, il peut etre bloquant et entrainer des pertes de performances
importantes. Avec une dizaine d'accès disque, on ne voit pas de
différences. Mais dès que les utilisateurs sont nombreux, peut-etre
100k, le passage par une base de données réduirait le nombre d'accès
disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut
penser au cache de MySQL.
Selon mon expérience sur un autre site (une autre association), il
y aura autour de 100 utilisateurs par jour, avec éventuellement des
pointes à 500 par jour (cas extrême). Sur mon site perso, autour de
500 à 1000 visiteurs par jour, j'utilise /tmp mais il n'y a pas de
partie privée. Par contre, j'ai un anti-aspirateur (mon site perso
a 90 000 documents html).
Cela dit, j'ai vu où Joomla plaçait ses sessions : dans une base SQL.
En gros, ils ont le numéro de la session, le nom d'usager et son
courrier, et les variables d'environnement. Pour mes besoins, je
pourrais à la limite utiliser le numéro de session pour valider que
c'est lancé depuis Joomla et non directement, mais il reste que ce
sera limité à cette version. Avec un peu de chance, Joomla ne
changera pas cette partie de façon importante durant les prochaines
années.
Le hic, c'est que mon application sera limitée à la version courante
de Joomla (donc, si Joomla change sa façon de gérer les sessions, il
faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session
étrangère.
En fait, j'ai vu qu'ils avaient une alternative. Le code de Joomla
est archi-compliqué avec des classes qui s'enchaînent et du code qui
change à la volée (du style include($nom-du-module) ). Mon code
est indépendant, une fois lancé.
Le Fri, 02 Oct 2009 21:08:53 +0200, Mickaël Wolff écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard wrote:
En SQL ? Je m'attendrais à ce qu'on utilise des fichiers dans /tmp dont l'accès est plus rapide que des enregistrements dans une base mySQL. Mais c'est vrai que si on n'utilise pas /tmp, on ne laisse pas à d'autres sites sur le même serveur une porte ouverte sur nos visiteurs.
Il n'y a pas que ça. Si /a priori/ l'accès au fichier est plus rapide, il peut etre bloquant et entrainer des pertes de performances importantes. Avec une dizaine d'accès disque, on ne voit pas de différences. Mais dès que les utilisateurs sont nombreux, peut-etre 100k, le passage par une base de données réduirait le nombre d'accès disque à 3*nombre de tables pour des tables InnoDb. Et encore, il faut penser au cache de MySQL.
Selon mon expérience sur un autre site (une autre association), il y aura autour de 100 utilisateurs par jour, avec éventuellement des pointes à 500 par jour (cas extrême). Sur mon site perso, autour de 500 à 1000 visiteurs par jour, j'utilise /tmp mais il n'y a pas de partie privée. Par contre, j'ai un anti-aspirateur (mon site perso a 90 000 documents html).
Cela dit, j'ai vu où Joomla plaçait ses sessions : dans une base SQL. En gros, ils ont le numéro de la session, le nom d'usager et son courrier, et les variables d'environnement. Pour mes besoins, je pourrais à la limite utiliser le numéro de session pour valider que c'est lancé depuis Joomla et non directement, mais il reste que ce sera limité à cette version. Avec un peu de chance, Joomla ne changera pas cette partie de façon importante durant les prochaines années.
Le hic, c'est que mon application sera limitée à la version courante de Joomla (donc, si Joomla change sa façon de gérer les sessions, il faudra modifier le code).
Il faudra donc encapsuler correctement la consultation de la session étrangère.
En fait, j'ai vu qu'ils avaient une alternative. Le code de Joomla est archi-compliqué avec des classes qui s'enchaînent et du code qui change à la volée (du style include($nom-du-module) ). Mon code est indépendant, une fois lancé.
