wir haben ein ähnliches Problem. wir können uns nicht mit admin:admin anmelden.

die SQL Abfrage

SELECT isys_person_intern__id, isys_person_intern__title
FROM isys_person_intern
WHERE isys_person_intern__title = 'admin'
AND isys_person_intern__user_pass = '21232f297a57a5a743894a0e4a801fc3';

gibt den admin User zurück:

15  admin

auch in den debug-log dateien kann man nicht viel erkennen. Der einzige Eintrag dort ist jedes mal nur:

(7.03@17:27:16) Debug  : Connection closed (idoit_sys).

Mehr wird nicht ausgegeben. Die anderen Logs zeigen aber, dass eine Kommunikation mit der DB stattfindet.
Kann uns jemand weiterhelfen, wie wir dem Problem auf den Grund gehen können bzw. dieses beheben?

Grüsse…

ich hatte auch obiges Problem mit SUSE Enterprise 10. Irgendwie wird bei der webbasierten Installation die Tabelle isys_mandator nicht mit gefüllt. In dieser stehen die Daten, die zum Zugriff auf die Mandantendatenbank notwendig sind. Nachdem ich sie manuell füllte klappte es auch mit dem Login. Anbei ein Beispiel:

Ausschnitt aus der Installationsanleitung: …
<isys_mandator><isys_mandator__id>1</isys_mandator__id>
<isys_mandator__title>Your company name</isys_mandator__title>
<isys_mandator__description>description</isys_mandator__description>
<isys_mandator__dir_cache>cache_your_company</isys_mandator__dir_cache>
<isys_mandator__dir_tpl>default</isys_mandator__dir_tpl>
<isys_mandator__db_host>localhost</isys_mandator__db_host>
<isys_mandator__db_port>3306</isys_mandator__db_port>
<isys_mandator__db_name>idoit_data</isys_mandator__db_name>
<isys_mandator__db_user>i-doit</isys_mandator__db_user>
<isys_mandator__db_pass>we-doit</isys_mandator__db_pass>
<isys_mandator__sort>1</isys_mandator__sort>
<isys_mandator__default_lang_const>ISYS_LANGUAGE_GERMAN</isys_mandator__default_lang_const>
<isys_mandator__default_language_short>de</isys_mandator__default_language_short></isys_mandator>
...

mysql --user=i-doit --password=we-doit idoit_sys;

INSERT INTO isys_mandator (isys_mandator__title, isys_mandator__description, isys_mandator__dir_cache, isys_mandator__dir_tpl, isys_mandator__db_host, isys_mandator__db_port, isys_mandator__db_name, isys_mandator__db_user, isys_mandator__db_pass, isys_mandator__sort, isys_mandator__default_lang_const, isys_mandator__default_language_short) VALUES ('MANDANT1 (DE)', 'MANDANT1', 'cache_MANDANT1', 'default', 'localhost', '3306', 'idoit_data', 'i-doit', 'we-doit', '1', 'ISYS_LANGUAGE_GERMAN', 'de');

Das es an einem PHP Bug im MD5 liegt, wie Dennis meint, glaub ich nicht.

ACK
zum testen:

Ich schnüffel diesem Problem mal hinterher, momentan weiss ich schon das gar keine MySQL Verbindung aufgebaut wird. Die Abfrage mittel mysql client funktioniert also ist dazwischen irgendwo das Problem.
Mal sehen ob ich die Nuss knacken kann.
cya

Das es an einem PHP Bug im MD5 liegt, wie Dennis meint, glaub ich nicht. Wir haben den gleichen Effekt mit Fedora 5 (anderes 5er PHP)  und Suse 9.3 (compiliertes 5.1.4-8er PHP). Ausserdem sind auf gleichen Maschinen andere PHP basierende Anwendungen, welche auch eine Authentifizierung machen und die gehashten Credentials ebenfalls in einer MySQL Datenbank liegen. D.h. I-DoIT teilt sich hier gleichen Application-Stack mit funktionierenden Opensource Anwendungen,

vg. Steffen

Danke fürs schauen, hier die Ergebnisse:

( echo "SELECT

isys_person_intern__id,
    isys_person_intern__title
  FROM
    isys_person_intern
  WHERE
    isys_person_intern__title='reader' AND
    isys_person_intern__user_pass='1de9b0a30075ae8c303eb420c103c320';
"; ) | mysql -uadmin -pxxxxxx idoit
isys_person_intern__id  isys_person_intern__title
11      reader

PHP 5.1.2 (cli) (built: May  2 2006 09:30:07)
Copyright 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

vg, Steffen

aus Sicherheitsgründen haben wir die SQL Statements im Debug Log, die den Login betreffen, deaktiviert.
Deshalb kommt lediglich eine Meldung wie: (10.11@15:54:34) Notice : Could not log in with username 'guest' and password 'guest'!, ohne den zugehörigen SQL-Code.

Der Code fuer den Login lautet folgendermaßen:
SELECT
    isys_person_intern__id,
    isys_person_intern__title
  FROM
    isys_person_intern
  WHERE
    isys_person_intern__title='reader' AND
    isys_person_intern__user_pass='1de9b0a30075ae8c303eb420c103c320';

Schau bitte einmal, ob du im mysql client ein gültiges Ergebnis bekommst.

Sag mir ausserdem bitte einmal deine php Version.
Da wir den md5 hash des vom User eingetippten Passworts in php und nicht mysql erzeugen, könnte dies ja eventuell das Problem sein.
Es gab da nämlich einen php Bug im Zusammenhang mit der md5 Funktion.

Gruss,
Dennis

Danke für den Debug-Tip, darin sieht man im Wesentlichen, dass er beim Login eine Query an die isys_mandator
Table stellen will, welche aber lehr ist.

isys_person_extern, isys_person_intern_iop  ist lehr
isys_person_intern (txt=sql), debug (png=tgz) siehe upload

vg, Steffen

idoit-debug.png
idoit_person_intern.txt

gibt es hier schon Erkenntnisse ?
ich stehe vor dem selben Problem, alle Module installiert
SuSe 10.0
mysql-Max-4.1.13-3.8
php5-mysql-5.0.4-9.20

old_password ist auch gesetzt

Ich habe auch schon einenen neuen User angelegt, aber auch mit dessen daten kann ich mich nicht anmelden.

Gibts noch ideen ??

Vielen Dank

Sind diese in der Liste aufgeführten extensions bei dir alle installiert, dann sollte es keine Probleme geben.
Ja, die zu 2. gezeigten extensions sind auf dieser i-doit-Installation real existierend installiert.

Befinden sich die angegebenen Benutzer in der Tabelle "isys_person_intern" in der Mandanten Datenbank?
Ja, die zu 1. gezeigten MD5 hashs waren aus entsprechendem select von der i-doit-Installation eingepastet.

| information_schema |
| cacti              |
| idoit              |
| mysql              |
| ndo                |
| test              |
| tmp                |
mysql> use idoit
mysql> show tables like '%person_intern';
+–--------------------------------+
| Tables_in_idoit (%person_intern) |
+----------------------------------+
| isys_group_2_isys_person_intern  |
| isys_person_intern              |
+----------------------------------+

• siehe 1. post

Wenn ja, was fuer eine Meldung genau kommt beim Login in i-doIT?
Username or Password invalid!
ich habe aber keine dicken Finger:), egal ob admin:admin,guest:guest etc.

kann man auf CLI den Anmeldeprosess simulieren? Kann man i-doit loggen, debuggen?

Steffen

Sollte eine der von i-doIT benötigten extensions fehlen, wird ein startup error gezeigt der ungefähr so aussieht: "not all extensions installed.. i need : extension_1 extension_2 …". Sind diese in der Liste aufgeführten extensions bei dir alle installiert, dann sollte es keine Probleme geben.

Befinden sich die angegebenen Benutzer in der Tabelle "isys_person_intern" in der Mandanten Datenbank?
Wenn ja, was fuer eine Meldung genau kommt beim Login in i-doIT?