Initialer Login schlägt fehl

steffen1

Hallo,

Ich kann mich mit den vorbetankten Logins nicht anmelden. Hab die Hinweise in den FAQ's durchgearbeitet, komme aber nicht mehr weiter:
Installation auf Suse10.1

2. MySQL-Setting für Password Backward-Compatibilät, OK - passt:
| old_passwords | ON

ja jetzt wirds sportlich - wuerde mich über Hinweise im Forum freuen, könnt mir vorstellen das vielleicht ein bestimmtes crypt-PHP-Modul fehlt oder?
bcmath
bz2
calendar
ctype
curl
date
dbase
dom
exif
filepro
ftp
gd
gettext
gmp
hash
iconv
imap
ldap
libxml
mbstring
mcrypt
mhash
mysql
mysqli
ncurses
odbc
openssl
pcntl
pcre
PDO
pgsql
posix
pspell
Reflection
session
shmop
SimpleXML
snmp
soap
sockets
SPL
SQLite
standard
sysvmsg
sysvsem
sysvshm
tokenizer

vg, Steffen

ds

Hi,

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?

steffen1

Danke für die Antwort,

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.

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

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.