Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.9.4.3
#~ Url du site :
#~ Hébergeur / Soft : OVH
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 1.9.4.2
#~ Installed Modules:
#~ CMSMailer: 2.0.1
#~ FileManager: 1.1.0
#~ MenuManager: 1.7.6
#~ ModuleManager: 1.4.2
#~ News: 2.11.3
#~ nuSOAP: 1.0.2
#~ Printing: 1.1.2
#~ Search: 1.6.10
#~ ThemeManager: 1.1.4
#~ TinyMCE: 2.9.1
#~ CGExtensions: 1.26.6
#~ CGSimpleSmarty: 1.4.8
#~ FrontEndUsers: 1.15.1
#~ CustomContent: 1.7.3
#~ CGBlog: 1.7.5
#~ SiteMapMadeSimple: 1.2.2
#~ CGFeedback: 1.3.5
#~ Uploads: 1.12
#~ Showtime: 2.0.4
#~ Config Information:
#~ php_memory_limit: 128M
#~ process_whole_template: false
#~ output_compression: false
#~ max_upload_size: 64000000
#~ default_upload_permission: 664
#~ url_rewriting: false
#~ page_extension:
#~ query_var: page
#~ image_manipulation_prog: GD
#~ auto_alias_content: true
#~ locale: fr_FR.utf8
#~ default_encoding: utf-8
#~ admin_encoding: utf-8
#~ set_names: true
#~ Php Information:
#~ phpversion: 5.2.17
#~ md5_function: On (Vrai)
#~ gd_version: 2
#~ tempnam_function: On (Vrai)
#~ magic_quotes_runtime: Off (Faux)
#~ E_STRICT: 0
#~ memory_limit: 128M
#~ max_execution_time: 120
#~ output_buffering: On
#~ safe_mode: Off (Faux)
#~ file_uploads: On (Vrai)
#~ post_max_size: 64M
#~ upload_max_filesize: 64M
#~ session_save_path: /tmp (1777)
#~ session_use_cookies: On (Vrai)
#~ xml_function: On (Vrai)
#~ Server Information:
#~ Server Api: cgi
#~ Server Db Type: MySQL (mysql)
#~ Server Db Version: 5.1.49
#~ ----------------------------------------------
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~
Bonjour à tous,
il n'aura pas fallu longtemps avant que je revienne vers vous avec un nouveau souci... :/
Celui-ci concerne le module FEU et l'expiration de session.
J'ai tenté différent réglages dans les paramètres de Session et Cookie, et cela fonctionne assez bien sur la gestion du temps de session.
Par contre, j'ai un gros problème lorsque on effectue la manip suivante :
- Connexion à la page d'accueil et saisie de l'identifiant et du mot de passe dans l'interface FEU.
- Connexion et identification réussies.
- Fermeture du navigateur.
- Reconnexion à la page d'accueil et nouvelle saisie de l'identifiant et du mot de passe dans l'interface FEU.
- Message d'erreur dans l'interface de FEU : "Cet utilisateur est déjà connecté"
Bref, si un utilisateur ferme son navigateur et qu'il revient sur le site il ne peut plus se reconnecter car sa session reste active...
Alors j'ai du surement encore raté un truc, mais après recherche dans les forums FR et US, épluchage de l'aide du module, je n'ai pas trouvé de réponse à ce problème.
Une bonne âme pour aiguiller mes recherches et réflexions ?!?
Puisqu'il est déjà connecté, pourquoi veux-tu qu'il se reconnecte ? Ses droits lui restent acquis. Il n'a pas besoin de passer à nouveau par l'identification.
Et bien lorsque je ferme (quitte) le navigateur, le module me redemande une authentification...
Bon sinon, j'ai temporairement résolu le problème en activant l'option "autoriser plusieurs connexions", mais mon client préfèrerait que cette option ne soit pas active.
La question reste donc posée
exact, il te manque sans doute une condition :
{if non connecté}
{formulaireFEU}
{else}
...
{/if}
Bess, lorsque je relance le navigateur (après l'avoir complètement fermé) et que j'arrive sur ma page d'accueil j'ai bien le gabarit de connexion, comme dans le cas d'une première connexion... mais la connexion ne s'effectue pas car il considère que cet utilisateur est toujours connecté. :|
c'est ce que je te disais non?
toi tu dois pas avoir le test de "si l'utilisateur est déjà connecté dans la base de donnée alors je ne lui affiche pas le formulaire"
je suis certain que tu as seulement : "dans tous les cas j'affiche le formulaire"
Je suis d'accord avec toi sur le principe... mais y'a quelque chose qui m'échappe ! Je ne dois pas avoir les neurones azimutés aujourd'hui...
ou alors je me suis mal exprimé pour décrire mon problème.
Le module fait parfaitement ce que tu décris lorsque je me contente de fermer juste l'onglet (en laissant donc mon navigateur ouvert), et de rouvrir une nouvelle page sur la page d'accueil.
Là, le module me considère comme déjà connecté et me le signifie en affichant mon identifiant et un lien pour me déconnecter (pas le gabarit de connexion).
Jusque-là, tout va bien...
Mon problème survient lorsque je ferme
complètement mon navigateur (quitter l'appli).
Il n'y a, normalement, plus aucune donnée conservée dans son cache (au navigateur).
Donc, logiquement, à ma prochaine tentative de reconnexion le module est censé me proposer de me logger, non ?
Jusque-là c'est ce qu'il se passe...
Mais lorsque je tente de me relogger avec les mêmes identifiant et pass, il refuse car il considère que cet utilisateur est toujours connecté. (vrai, puisque vérifié dans l'interface admin du module)
Ma question (reformulée) est donc la suivante :
N'y a t-il pas moyen de faire en sorte qu'une session ne reste pas active si un utilisateur perd la connexion au site ?
Bon, au final je ne sais pas si j'ai été plus clair...
Citation :Mon problème survient lorsque je ferme complètement mon navigateur (quitter l'appli).
Il n'y a, normalement, plus aucune donnée conservée dans son cache (au navigateur).
Donc, logiquement, à ma prochaine tentative de reconnexion le module est censé me proposer de me logger, non ?
tu as tord et le tord tue ninja
les cookies et le cache de ton navigateur vivent même lorsque celui ci est fermé.
le meilleur exemple ? ce forum tu y accèdes bien sans devoir te reconnecter à chaque fois ?
seule solution pour t'assurer d'avoir un navigateur clean sans passer par vidage des cookies & co : utiliser un autre navigateur. Pas un onglet, pas une fenetre, un AUTRE navigateur
Je viens de tester... aucune différence !
Je me suis connecté au site avec FF = OK
Je me suis identifié comme utilisateur = OK
Je me suis retrouvé dans la partie privée du site = OK
Puis j'ai fermé FF...
Je me suis connecté au site avec Chrome = OK
Je me suis identifé comme utilisateur = Cet utilisateur est déjà connecté
Anyway, je ne pense pas que le souci vienne de mon navigateur ou de la façon dont il est réglé puisque je n'ai aucun problème de ce genre sur les autres sites. L'exemple de ce forum en est la parfaite démonstration...
De plus, j'ai fait un test en me connectant à l'administration du site à partir de Safari (sans passer par le site et une quelconque identification d'utilisateur), en ayant bien pris soin de laisser fermés FF et Chrome.
Dans l'interface de gestion des utilisateurs de FEU, mon utilisateur était toujours indiqué comme "connecté" alors que non... :/ :/
Pourquoi ne penses-tu pas qu'il s'agisse d'un problème de session venant des réglages du module ? :|
et tu as pensé a voir l'aide du module, parcourir les paramètres du modules, ce genre de chose :
Citation :3. “Allow Users to Login More Than Once”
This setting indicates that the same user may log into the website from two
machines (or two browsers on the same machine) at the same time. This option
could be used for shared accounts, etc.
trouvé en 30s sur la documentation à droite sur cette page :
comment faire une partie privée dans cmsms
c'est l'option que j'ai activée (message #3 de ce post, trouvé en 10s
) en attendant d'avoir une solution au problème que j'expose ici...
Comme cité plus haut, mon client préfèrerait que cette option ne soit pas valide...
:lol:
bon blague a part, je penses que tu as la réponse maintenant
Citation :3. “Allow Users to Login More Than Once”
This setting indicates that the same user may log into the website from two
machines (or two browsers on the same machine) at the same time. This option
could be used for shared accounts, etc.
pas possible de désactiver cette option & bénéficier du multi-connexion
Ben si tu m'assures qu'il n'y a pas de moyen de s'en passer, ni de contourner la limite de temps de session pour permettre à un utilisateur (qui fermerait "malencontreusement" la fenêtre de son navigateur) de pouvoir s'y reconnecter sans devoir attendre l'expiration de session, alors oui j'ai ma réponse... ce n'est pas faisable !
Reste à voir, maintenant, si mon client acceptera que les utilisateurs puissent faire de multiples connexions.
Merci pour tes réponses
Je ne suis pas en mesure de t'assurer quoi que ce soit, je n'ai pas le code source sous les yeux et je ne suis pas l'auteur de ce module
mais les indications que j'ai trouvé me semble pourtant attester mon raisonnement.
maintenant il faut que je comprenne pourquoi ton client bloque sur ce sujet
C'est simplement que le contenu de son site est un peu sensible, et que sa volonté de tout verrouiller fait qu'il bloque sur des détails à la c** comme ici... :/
Pour illustrer mon propos, je citerais sa dernière demande en date : modifier le nom du dossier "admin" du CMS afin de rendre le hack de son site plus compliqué. :| :| :|
Vu comme je vous casse déjà les pieds avec mes soucis de compréhension des différentes interactions entre CMSMS et les modules, je n'avais pas encore osé évoquer cette question ici !
ulee a écrit :Pour illustrer mon propos, je citerais sa dernière demande en date : modifier le nom du dossier "admin" du CMS afin de rendre le hack de son site plus compliqué. :| :| :|
Et il a raison !
Voir wiki :
http://wiki.cmsmadesimple.org/index.php/...mall_Guide
Citation :Rename admin directory with a fake name (e.g. "admin39xRlklkLK3d"). Don’t use a name easy to guess. Remember to change also /config.php with your new name $config['admin_dir'] ="admin39xRlklkLK3d"
Protect admin directory with a password. Many host provider offers a way to do this in their webpage. If you are enabled by your host provider modify apache SSL config using this setting:
Oui, dans l'absolu je suis d'accord avec toi... Après ce n'est pas le site de la CIA son truc non plus ! :lol:
Y'a des limites à la paranoïa ^^
Et sinon, tu saurais comment il faut s'y prendre pour effectuer un tel changement ?
J'ai trouvé des réponses sur le déplacement du CMS d'un répertoire à un sous répertoire (et inversement), mais rien de très probant sur le changement de nom du dossier "admin"...
Voir lien dans post précédent.
Modifier le config.php :
#Name of the admin directory
$config['admin_dir'] = 'admin';
ulee a écrit :Oui, dans l'absolu je suis d'accord avec toi... Après ce n'est pas le site de la CIA son truc non plus ! :lol:
Y'a des limites à la paranoïa ^^
Le problème n'est pas au niveau de sécurité des données, mais pour rendre le site plus difficile à cracker.
Pas besoin d'être la CIA pour se faire pirater son site.
Jean le Chauve a écrit :ulee a écrit :Oui, dans l'absolu je suis d'accord avec toi... Après ce n'est pas le site de la CIA son truc non plus ! :lol:
Y'a des limites à la paranoïa ^^
Le problème n'est pas au niveau de sécurité des données, mais pour rendre le site plus difficile à cracker.
Pas besoin d'être la CIA pour se faire pirater son site.
Oui, et oui....
Alors je viens de tester la méthode que tu as décrite (j'avais déjà testé, mais m'étais retrouvé avec plein d'erreurs php) et là ça fonctionne au poil !
Je ne comprend pas pourquoi ça n'avait pas fonctionné avant... l'essentiel étant que maintenant ça marche nickel.
Encore merci
Citation :Pas besoin d'être la CIA pour se faire pirater son site.
cmsms.fr déjà piraté en novembre 2010 ... la joie dans mon coeur
quel intérêt à me pirater ? aucun ... alors dans l'absolu j'ai renommé l'admin de ce site comme tu pourras le voir... ne néglige pas ce genre de détail surtout si ton client te le propose direct, la plupart ne comprendrais même pas l'intérêt de cette modif.
concernant la possibilité de se reconnecter ... a mon avis c'est plus une incompréhension de sa part sur les conséquences de cette fonction que de la paranoïa pure... mais bon c'est toi qui gère, pas moi