Initialer Login schlägt fehl

lilgrisu

Hallo,

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

npotthast

Ich würde mir gerne mal den Inhalt der %person_intern Tabellen ansehen, kannst du die mal anhängen?
Ansonsten, steh vielleicht was in den Debug-logs. Das Debugging kannst du auch in der config.inc.php einschalten, woraufhin dann die entsprechenden *.txt Dateien generiert werden.

steffen1

Hallo,

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

ds

Hi,

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

steffen1

Hallo Denis,

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

steffen1

Ich wollte mich noch mal zu diesem Thema melden, weil ich immer noch keine Lösung selber gefunden habe und ohne Eure Hilfe mich wahrscheinlich unter Linux nie in I-DoIT einloggen können werde:

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

fnord

Gleiches Problem unter Debian sarge
@steffen1:

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

marceroo

Hallo,

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');

shark

Hallo,

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…

npotthast

Um welche Version handelt es sich? Die aktuelle Revision schreiben wir in die Datei REVISION im root Verzeichnis.