Bonjour,
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est
à dire telle que sa création entraîne soit un avertissement, soit la
fermeture des autres sessions.
Le besoin est de réaliser l'interface d'administration d'un système qui
ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une
extension php qui communique avec d'autres processus dans la machine
serveur).
Merci d'avance.
--
Forje
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
John GALLET
Bonjour,
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est à dire telle que sa création entraîne soit un avertissement, soit la fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa session est soit de faire avant toute vérification/ouverture un delete gérant non seulement le time-out, mais aussi le login, ou alors de mettre une clef unique sur le login de la session, selon ce qu'on veut (un duplicate key donnant un warning, ou une fermeture automatique).
Le besoin est de réaliser l'interface d'administration d'un système >qui ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une extension php qui communique avec d'autres processus dans la machine serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas à être multithread si elle est utilisée avec apache 1.3 ou en prefork. Tout dépend bien sûr de ce qu'elle fait et des contraintes externes, mais si elle doit *vraiment* être mono-utilisateur sous risque de totu planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un bon vieux sémaphore là où il faut.
a++; JG
Bonjour,
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est
à dire telle que sa création entraîne soit un avertissement, soit la
fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa
session est soit de faire avant toute vérification/ouverture un delete
gérant non seulement le time-out, mais aussi le login, ou alors de
mettre une clef unique sur le login de la session, selon ce qu'on veut
(un duplicate key donnant un warning, ou une fermeture automatique).
Le besoin est de réaliser l'interface d'administration d'un système >qui
ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une
extension php qui communique avec d'autres processus dans la machine
serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension
avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas
à être multithread si elle est utilisée avec apache 1.3 ou en prefork.
Tout dépend bien sûr de ce qu'elle fait et des contraintes externes,
mais si elle doit *vraiment* être mono-utilisateur sous risque de totu
planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un
bon vieux sémaphore là où il faut.
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est à dire telle que sa création entraîne soit un avertissement, soit la fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa session est soit de faire avant toute vérification/ouverture un delete gérant non seulement le time-out, mais aussi le login, ou alors de mettre une clef unique sur le login de la session, selon ce qu'on veut (un duplicate key donnant un warning, ou une fermeture automatique).
Le besoin est de réaliser l'interface d'administration d'un système >qui ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une extension php qui communique avec d'autres processus dans la machine serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas à être multithread si elle est utilisée avec apache 1.3 ou en prefork. Tout dépend bien sûr de ce qu'elle fait et des contraintes externes, mais si elle doit *vraiment* être mono-utilisateur sous risque de totu planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un bon vieux sémaphore là où il faut.
a++; JG
Forje
Bonjour,
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est à dire telle que sa création entraîne soit un avertissement, soit la fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa session est soit de faire avant toute vérification/ouverture un delete gérant non seulement le time-out, mais aussi le login, ou alors de mettre une clef unique sur le login de la session, selon ce qu'on veut (un duplicate key donnant un warning, ou une fermeture automatique).
J'ai fini par gérer mes sessions à l'aide d'une table MySQL (comme décrit ici http://www.zend.com/zend/spotlight/code-gallery-wade8.php?article=code-gallery-wade8). ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session. En complément un aléa est généré au login, stocké dans la table de session et au même moment dans un cookie. Au chargement des pages, le cookie et la variable de session correspondante sont comparés, de mon cas, si identique, on continue c'est bien ici que cela à commencé, sinon on arrête tout, la session (utilisateur) est terminée.
Le besoin est de réaliser l'interface d'administration d'un système >qui ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une extension php qui communique avec d'autres processus dans la machine serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas à être multithread si elle est utilisée avec apache 1.3 ou en prefork. Tout dépend bien sûr de ce qu'elle fait et des contraintes externes, mais si elle doit *vraiment* être mono-utilisateur sous risque de totu planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un bon vieux sémaphore là où il faut.
Vous avez raison, la technique de l'extension n'est pas la source du besoin d'exclusivité mais bien l'action qu'elle mène, qui elle se doit d'être mono utilisateur.
Merci pour votre éclairage utile. -- Forje
Bonjour,
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est
à dire telle que sa création entraîne soit un avertissement, soit la
fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa
session est soit de faire avant toute vérification/ouverture un delete
gérant non seulement le time-out, mais aussi le login, ou alors de
mettre une clef unique sur le login de la session, selon ce qu'on veut
(un duplicate key donnant un warning, ou une fermeture automatique).
J'ai fini par gérer mes sessions à l'aide d'une table MySQL (comme
décrit ici
http://www.zend.com/zend/spotlight/code-gallery-wade8.php?article=code-gallery-wade8).
ses_id est forcé à une constante. Virtuellement, tous les connectés
partage les mêmes variables de session.
En complément un aléa est généré au login, stocké dans la table de
session et au même moment dans un cookie.
Au chargement des pages, le cookie et la variable de session
correspondante sont comparés, de mon cas, si identique, on continue
c'est bien ici que cela à commencé, sinon on arrête tout, la session
(utilisateur) est terminée.
Le besoin est de réaliser l'interface d'administration d'un système >qui
ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une
extension php qui communique avec d'autres processus dans la machine
serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension
avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas
à être multithread si elle est utilisée avec apache 1.3 ou en prefork.
Tout dépend bien sûr de ce qu'elle fait et des contraintes externes,
mais si elle doit *vraiment* être mono-utilisateur sous risque de totu
planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un
bon vieux sémaphore là où il faut.
Vous avez raison, la technique de l'extension n'est pas la source du
besoin d'exclusivité mais bien l'action qu'elle mène, qui elle se doit
d'être mono utilisateur.
Connaissez-vous le moyen habituel de rendre une session exclusive, c'est à dire telle que sa création entraîne soit un avertissement, soit la fermeture des autres sessions.
Un moyen extrêmement simple quand on utilise une table pour gérer sa session est soit de faire avant toute vérification/ouverture un delete gérant non seulement le time-out, mais aussi le login, ou alors de mettre une clef unique sur le login de la session, selon ce qu'on veut (un duplicate key donnant un warning, ou une fermeture automatique).
J'ai fini par gérer mes sessions à l'aide d'une table MySQL (comme décrit ici http://www.zend.com/zend/spotlight/code-gallery-wade8.php?article=code-gallery-wade8). ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session. En complément un aléa est généré au login, stocké dans la table de session et au même moment dans un cookie. Au chargement des pages, le cookie et la variable de session correspondante sont comparés, de mon cas, si identique, on continue c'est bien ici que cela à commencé, sinon on arrête tout, la session (utilisateur) est terminée.
Le besoin est de réaliser l'interface d'administration d'un système >qui ne peut avoir qu'un seul utilisateur à la fois (nous avons réalisé une extension php qui communique avec d'autres processus dans la machine serveur).
Accessoirement, je ne vois pas en quoi le fait que ce soit une extension avec de l'IPC implique qu'elle soit mono utilisateur. Elle n'a même pas à être multithread si elle est utilisée avec apache 1.3 ou en prefork. Tout dépend bien sûr de ce qu'elle fait et des contraintes externes, mais si elle doit *vraiment* être mono-utilisateur sous risque de totu planter sinon, j'aurais plutôt tendance, dans l'extension, à mettre un bon vieux sémaphore là où il faut.
Vous avez raison, la technique de l'extension n'est pas la source du besoin d'exclusivité mais bien l'action qu'elle mène, qui elle se doit d'être mono utilisateur.
Merci pour votre éclairage utile. -- Forje
John GALLET
Bonjour,
ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session.
Je n'ai rien compris ces deux phrases.
JG
Bonjour,
ses_id est forcé à une constante. Virtuellement, tous les connectés
partage les mêmes variables de session.
ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session.
Je n'ai rien compris ces deux phrases.
JG
Forje
Bonjour,
ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session.
Je n'ai rien compris ces deux phrases. Oui, c'est un peu vite résumé...
En fait mon objectif est d'avoir un et un seul utilisateur à la fois. À la création de session sont donc installé de nouvelles fonctions pour _read, _write, etc... (avec session_set_save_handler) dans lesquelles j'utilise mysql pour stocker les infos de sessions et dans lesquelles je force la valeur de ses_id à une constante. Ainsi quand une session est démarrée elle aura tjrs le même id. En complément, dans mes scripts : - au démarrage d'une session (au login) un alea est stocké dans le tableau $_SESSION et dans un cookie du client. - pour chaque autre script, les deux valeurs précédentes sont comparées, si elles sont égales on est bien dans la continuité ; sinon cela signifie soit que l'on commence une page sans être passé par le login, soit qu'un second connecté a fait un login et donc détruit la première session. Bref, on peut sans doute faire moins tordu mais en tout cas, il y a bien exclusivité (au profit du dernier connecté, mais ça me suffit). -- Forje
Bonjour,
ses_id est forcé à une constante. Virtuellement, tous les connectés
partage les mêmes variables de session.
Je n'ai rien compris ces deux phrases.
Oui, c'est un peu vite résumé...
En fait mon objectif est d'avoir un et un seul utilisateur à la fois.
À la création de session sont donc installé de nouvelles fonctions pour
_read, _write, etc... (avec session_set_save_handler) dans lesquelles
j'utilise mysql pour stocker les infos de sessions et dans lesquelles je
force la valeur de ses_id à une constante. Ainsi quand une session est
démarrée elle aura tjrs le même id.
En complément, dans mes scripts :
- au démarrage d'une session (au login) un alea est stocké dans le
tableau $_SESSION et dans un cookie du client.
- pour chaque autre script, les deux valeurs précédentes sont comparées,
si elles sont égales on est bien dans la continuité ; sinon cela
signifie soit que l'on commence une page sans être passé par le login,
soit qu'un second connecté a fait un login et donc détruit la première
session.
Bref, on peut sans doute faire moins tordu mais en tout cas, il y a bien
exclusivité (au profit du dernier connecté, mais ça me suffit).
--
Forje
ses_id est forcé à une constante. Virtuellement, tous les connectés partage les mêmes variables de session.
Je n'ai rien compris ces deux phrases. Oui, c'est un peu vite résumé...
En fait mon objectif est d'avoir un et un seul utilisateur à la fois. À la création de session sont donc installé de nouvelles fonctions pour _read, _write, etc... (avec session_set_save_handler) dans lesquelles j'utilise mysql pour stocker les infos de sessions et dans lesquelles je force la valeur de ses_id à une constante. Ainsi quand une session est démarrée elle aura tjrs le même id. En complément, dans mes scripts : - au démarrage d'une session (au login) un alea est stocké dans le tableau $_SESSION et dans un cookie du client. - pour chaque autre script, les deux valeurs précédentes sont comparées, si elles sont égales on est bien dans la continuité ; sinon cela signifie soit que l'on commence une page sans être passé par le login, soit qu'un second connecté a fait un login et donc détruit la première session. Bref, on peut sans doute faire moins tordu mais en tout cas, il y a bien exclusivité (au profit du dernier connecté, mais ça me suffit). -- Forje
