Identification sous GRR 4.0.2

Bonjour,
la différence de comportement entre 4.0.3 et 3.5.1 vient du fait que la connexion est par défaut obligatoire pour la première et non pour la seconde.
Le problème est donc le même : vous n'êtes pas connecté bien que vos données soient reconnues comme valables (elles sont insérées dans la table grr_log).
Votre authentification se fait-elle sur la base locale, ou un serveur CAS ou LDAP ?
Cordialement,
YN

Base locale, avec l'utilisateur administrateur qui est créé pendant l'installation automatique
Je ne peux pas choisir le mot de passe azerty qui était apparemment le mot de passe par défaut à une époque, car il faut saisir 8 caractères

Je ne vois pas comment je pourrais tester un autre compte, ou encore l'authentification ldap car je n'ai accès à aucun menu d'administration

Bonjour,
il n'y a plus de mot de passe par défaut, il faut effectivement en définir un lors de l'installation et la longueur minimale est de 8 caractères.
La connexion sur la base locale échoue... ce sera plus simple à résoudre.
C'est vraisemblablement un problème de configuration de GRR sur le serveur.
Puisque vous avez accès à la base, que donne la lecture de grr_utilisateurs ?
Quel hébergement avez-vous ? Machine locale ou serveur partagé ?
Cordialement,
YN

Ci-dessous l'export de la table grr_utilisateurs
J'ai installé l'application sur une VM dans mon infra, la base et l'application sont sur le même serveur


-- phpMyAdmin SQL Dump
-- version 5.0.4deb2+deb11u1
-- www.phpmyadmin.net/
--
-- Hôte : localhost:3306
-- Généré le : mar. 23 mai 2023 à 21:22
-- Version du serveur : 10.5.15-MariaDB-0+deb11u1
-- Version de PHP : 7.4.33

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

--
-- Base de données : `grr`
--

--

---

--
-- Structure de la table `grr_utilisateurs`
--

CREATE TABLE `grr_utilisateurs` (
`login` varchar(190) NOT NULL DEFAULT '',
`nom` varchar(30) NOT NULL DEFAULT '',
`prenom` varchar(30) NOT NULL DEFAULT '',
`password` varchar(200) NOT NULL DEFAULT '',
`changepwd` tinyint(1) NOT NULL DEFAULT 0,
`email` varchar(100) NOT NULL DEFAULT '',
`statut` varchar(30) NOT NULL DEFAULT '',
`etat` varchar(20) NOT NULL DEFAULT '',
`default_site` smallint(6) NOT NULL DEFAULT 0,
`default_area` smallint(6) NOT NULL DEFAULT 0,
`default_room` smallint(6) NOT NULL DEFAULT 0,
`default_style` varchar(50) NOT NULL DEFAULT '',
`default_list_type` varchar(50) NOT NULL DEFAULT '',
`default_language` char( NOT NULL DEFAULT '',
`source` varchar(10) NOT NULL DEFAULT 'local'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

--
-- Déchargement des données de la table `grr_utilisateurs`
--

INSERT INTO `grr_utilisateurs` (`login`, `nom`, `prenom`, `password`, `changepwd`, `email`, `statut`, `etat`, `default_site`, `default_area`, `default_room`, `default_style`, `default_list_type`, `default_language`, `source`) VALUES
('ADMINISTRATEUR', 'Administrateur', 'grr', '$2y$10$JH3t1JNw/CBiG6bQ8w5I4ul42FR/mA9/UNRatEWDEQ/P0lULthyEq', 0, '', 'administrateur', 'actif', 0, 0, 0, 'default', 'item', 'fr', 'local');

--
-- Index pour les tables déchargées
--

--
-- Index pour la table `grr_utilisateurs`
--
ALTER TABLE `grr_utilisateurs`
ADD PRIMARY KEY (`login`);
COMMIT;

/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Bonjour,
je dois humblement reconnaître que je sèche.
Les éléments que vous donnez indiquent que le mot de passe est bien enregistré au nouveau format dans la base de données.
Et si tout se passe sur la même machine, même virtuelle, je ne comprends pas ce qui fait que l'ouverture de session ne se fait pas.
Autre piste : avez-vous essayé la version 3.4.3 ? C'est un peu la tentative du désespoir, mais sait-on jamais ?
Cordialement,
YN

La version 3.4.3c fonctionne !
Je ne vois pourtant aucune différence dans les tables utilisateurs des différentes versions

Bonjour,
c'est une bonne nouvelle !
Cela suggère donc que votre serveur est bien fonctionnel.
Aurait-on un problème avec l'encodage des mots de passe ?
Si vous en avez le temps, pouvez-vous tester la version 3.5.0 ? La différence majeure entre 3.5.0 et 3.5.1 est justement l'encodage des mots de passe dans la base de données. Les données sont identiquement encodées en UTF-8.
Cordialement,
YN

J'ai testé la version 3.5.0d qui fonctionne

Bonjour,
merci pour votre retour.
Ce que je constate à l'usage, c'est que l'authentification avec le nouvel encodage des mots de passe nécessite deux tentatives lors de la conversion de l'ancien au nouveau codage. Avez-vous fait deux essais successifs avec la v3.5.1 ?
Cordialement,
YN

J'ai fait de nombreux essais oui mais cela n'a jamais fonctionné à partir de la version 3.5.1
Le comportement est différent quand le mot de passe est mauvais alors je sais quand le bon mot de passe est reconnu
Le hash du mot de passe fait 50 ou 60 caractères, la limite du champ et à 200 je crois