Anomalie #587
fermé
pb token sur change_passwd
100%
Description
à la demande de reset apres perte du mot de passe, la génération du lien est fait, mais celui-ci est invalide même pendant sa durée de validitée
Mis à jour par chrristian gamache il y a environ 11 ans
sébastien baudoin a écrit :
à la demande de reset apres perte du mot de passe, la génération du lien est fait, mais celui-ci est invalide même pendant sa durée de validitée
Même choses ici. :
"_Ce lien n'est plus valide. Vous devriez demander la récupération de votre mot de passe à nouveau_"
Galette 0.7.4 chez ovh mutualisé.
Galette version: v0.7.4
PHP version: 5.4.6
PHP/Web: cgi-fcgi
Database: mysql
OS: Linux web245.1000gp.ha.ovh.net 3.2.37-uid-limit2-mutu-grs-ipv6-64 #1 SMP Sun Jan 27 07:40:58 CET 2013 x86_64
Browser: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; ARM; Trident/6.0; Touch)
Modules:
OK:
module « gd »
l'un des pilotes PDO « mysql », « pgsql » ou « sqlite »
module « curl »
module « gettext »
module « mbstring »
support « openssl »
May:
module « tidy »
Should:
Missing:
Plugins:
PHP loaded modules:
Core
date
ereg
libxml
openssl
pcre
sqlite3
zlib
bcmath
bz2
calendar
ctype
curl
dba
dom
hash
fileinfo
filter
ftp
gd
gettext
gmp
SPL
iconv
session
intl
json
mbstring
mcrypt
mysql
mysqli
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
standard
posix
pspell
Reflection
imap
SimpleXML
soap
sockets
Phar
exif
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
memcache
cgi-fcgi
mhash
Mis à jour par sébastien baudoin il y a environ 11 ans
En regardant dans la BDD, la génération du MDP temporaire est correcte, la génération de la création de la date aussi.
Je sêche sur où et quoi regarder d'autre ... vous auriez des pistes ?
Mis à jour par chrristian gamache il y a environ 11 ans
sébastien baudoin a écrit :
En regardant dans la BDD, la génération du MDP temporaire est correcte, la génération de la création de la date aussi.
Je sêche sur où et quoi regarder d'autre ... vous auriez des pistes ?
Peut-être le timezone du serveur serveur hébergeant vs le timezone du serveur BDD vs le timezone du client ?
Ou encore les format de date par défaut de la BDD ou du serveur hébergeant la BDD ou du serveur hébergeant le www vs celui du poste client ?
Comment est contrôler le token ? par procédures stockés ?
Simples pistes à explorer.
Mis à jour par Johan Cwiklinski il y a environ 11 ans
- Statut changé de Nouveau à Commentaire
Je ne parviens pas à reproduire le problème.
Il faudrait s'assurer que le paramétrage de la timezone est correcte ; mais puisque seule celle du serveur entre en compte je ne pense pas que ça puisse réellement jouer.
Il faudrait également voir ce que disent les logs de Galette et ceux du système (voir la faq pour afficher les erreurs si ces derniers ne sont pas accessibles).
chrristian gamache a écrit :
Comment est contrôler le token ? par procédures stockés ?
C'est déjà bien assez périlleux d'avoir de simples requêtes SELECT fonctionnelles entre les différents moteurs pour ne pas utiliser ce genre de choses...
Le token stocké en base est envoyé tel quel à l'adresse mail de l'adhérent, qui doit l'utiliser dans le temps imparti ; le seul pépin connu, ce sont les caractères spéciaux dans l'URL (confer 7aaebdf740), corrigé en 0.7.4.
Mis à jour par sébastien baudoin il y a presque 11 ans
Bonjour,
Je n'ai rien dans les logs, le display_erros '1' ne sort rien non plus, le timezone est correct et défini dans le php.ini (j'ai même fait une syncro au cas où ...).
Adresse du galette en question : http://gestion.asso.ceve.fr
Mis à jour par sébastien baudoin il y a presque 11 ans
sébastien baudoin a écrit :
Bonjour,
Je n'ai rien dans les logs, le display_erros '1' ne sort rien non plus, le timezone est correct et défini dans le php.ini (j'ai même fait une syncro au cas où ...).
Adresse du galette en question : http://gestion.ceve.asso.fr
Mis à jour par sébastien baudoin il y a presque 11 ans
Apparement c'est l'url encode/decode qui pose problème :
en passant le token en brut, la demande est acceptée.
en cliquant sur le lien générer, donc avec le token encodé ( %24 <=> $ ) ça ne fonctionne pas.
Par contre je trouve pas le paramètre encode() dans les scripts d'emails.
Mis à jour par Johan Cwiklinski il y a presque 11 ans
Le token a été encodé justement car ça ne fonctionnait pas... Quel est le navigateur utilisé ? L'instance est-elle accessible que je puisse faire un essai de mon côté ?
Mis à jour par Pascal CORVISIER il y a presque 11 ans
Bonjour
même probleme chez moi. %24 a la place du $.
je suis chez 1and1
Galette version: v0.7.4
PHP version: 5.4.14
PHP/Web: cgi-fcgi
Database: mysql
OS: Linux infong 2.4 #1 SMP Thu Feb 14 13:02:49 CET 2013 i686 GNU/Linux
Browser: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Mr les pro une solution SVP ;-)
je galere depuis une semaine.
Merci a vous.
Mis à jour par Pascal CORVISIER il y a presque 11 ans
suite.
je viens de m'apersevoir que dans la table " tmppasswds " que le champ " tmp_passwds " été en varchar(40) rectifier en varchar(60)
mes lien marche a présent.
a tester pour ceux qui ont le meme probleme.
bon 1er mai a tous.
Mis à jour par sébastien baudoin il y a presque 11 ans
Pascal CORVISIER a écrit :
suite.
je viens de m'apersevoir que dans la table " tmppasswds " que le champ " tmp_passwds " été en varchar(40) rectifier en varchar(60)
mes lien marche a présent.a tester pour ceux qui ont le meme probleme.
bon 1er mai a tous.
Idem ici => pb réglé. :D
J'étais loin de penser à aller vérifier la structure des tables... Merci !
Bon 1er Mai.
Mis à jour par chrristian gamache il y a presque 11 ans
Merci pour l'information
je vais tester des aujourd'hui !
Bon 1er à tous aussi
Pascal CORVISIER a écrit :
suite.
je viens de m'apersevoir que dans la table " tmppasswds " que le champ " tmp_passwds " été en varchar(40) rectifier en varchar(60)
mes lien marche a présent.a tester pour ceux qui ont le meme probleme.
bon 1er mai a tous.
Mis à jour par Pascal CORVISIER il y a presque 11 ans
suite suite
aprés analyse des sources
c'est quand la base est creer avec la v0.7.4 mais pas si c'est une MAJ.
@+
Mis à jour par Johan Cwiklinski il y a presque 11 ans
- Tracker changé de Assistance à Anomalie
Mis à jour par Johan Cwiklinski il y a presque 11 ans
- Version utilisée mis à 0.7.4
- Assigné à mis à Johan Cwiklinski
- Statut changé de Commentaire à In Progress
- Catégorie mis à Database
En effet, les scripts d'installation n'ont pas été mis à jour... Merci.
Mis à jour par Johan Cwiklinski il y a presque 11 ans
- % réalisé changé de 0 à 100
- Statut changé de In Progress à Résolu
Appliqué par commit 308872dae7163c3a2935165b1b12261c3c3f8104.