Final Version 0.9 Anmelde Probleme

jknuth

session.save_path
kannst du das mal setzten ? z.b. session.save_path = c:\temp
und dann die rechte auch so setzten das der entsprechende user dort lesen/schreiben kann

LiesJa · Windows 2003 Server / Apache 2.2.3/ PHP 5.1.6 / MySQL 5.0.24

Bei mir steht das so drin.

session.save_path = "D:\it-infrastruktur/php-5.1.4/sessiondata"
Ich weiß jetzt aber nicht, ob \ oder / okay ist oder ob das egal ist!!

ändere jetzt mal alles auf \

Bis gleich

Probiert:
Keine Veränderung, es wird auch fleißig was reingespeichert.

In dem Bereich wurde ja auch nichts geändert!!!!

Noch mal zu info es hat ja mit der Beta gefunzt!!!

broesel

@LiesJa:

Ach Jörg, hast du die Installerversion von der Beta genommen oder manuell auf ein vorhandenes System (Welche Versionen Apache,php, mysql ?)

Installer Version, zum Testen war ich zu faul alles von Hand zu machen ;-))

Ich kann dir morgen mal meine Datei schicken

LiesJa · Windows 2003 Server / Apache 2.2.3/ PHP 5.1.6 / MySQL 5.0.24

Ja wäre mal nett

bis morgen

Jan

npotthast

Hi, ich melde mich auch noch einmal zu Wort.

Bei einer geposteten config.inc.php ist mir aufgefallen, dass zum einen "theme" => "redbox" und zum anderen "debugging" => false eingestellt war. Das erste könnte man testweise mal auf "default" setzen und das zweite auf "true". Dadurch kann man sich bei Fehlern die letzten Debug-Meldungen anschauen.

broesel

Anbei meine funktionierende config.inc.php

Gruss

Jörg

config.inc.php.txt

ChristianB

Ich habe jetzt mal mit der php.ini rumgespielt und auch mal mit einer anderen php Installation verglichen. Alles ohne Erfolg. Die config.inc.php habe ich auch nochmal kontrolliert jedoch glaube ich nicht das dort der Fehler zu finden ist. Das Hauptproblem scheint hier die php Installation zu sein. Da ich von Anfang an nur die final Version probiert habe werde ich jetzt mal testweise die Beta installieren und schauen ob es damit funktioniert wie LiesJa meint. Dann bräuchte man vielleicht nur noch die Unterschiede bei der Anmeldung zwischen den beiden Versionen vergleichen.

ChristianB

Der Passwort Fehler ist jetzt weg ich habe jetzt einen neuen! Ich habe in der php.ini mit den session Variablen gespielt. Mein Eintrag sieht jetzt so aus:```
; The domain for which the cookie is valid.
session.cookie_domain =


isys_exception_database : Query error: 'INSERT INTO isys_group_2_isys_user_session (isys_group_2_isys_user_session__id, isys_group_2_isys_user_session__isys_group__id, isys_group_2_isys_user_session__isys_user_session__id) SELECT '%', isys_group_2_isys_person_intern__isys_group__id, isys_user_session__id FROM isys_group_2_isys_person_intern LEFT JOIN isys_user_session ON isys_user_session__isys_person_intern__id=isys_group_2_isys_person_intern__isys_person_intern__id WHERE isys_group_2_isys_person_intern__isys_person_intern__id='15'': Out of range value adjusted for column 'isys_group_2_isys_user_session__id' at row 1 (Extended Information: array ( 'server' => '5.0.27-community-nt', 'host' => '127.0.0.1 via TCP/IP', 'client' => '5.0.22', 'proto' => 10, ))

**Fatal error:** Uncaught Exception occured in (C:\Inetpub\wwwroot\idoit\src\classes\components\isys_component_dao.class.php:212): isys_exception_dao : DAO Exception: Running transaction has been canceled. Could not isys_component_dao::update() : INSERT INTO isys_group_2_isys_user_session (isys_group_2_isys_user_session__id, isys_group_2_isys_user_session__isys_group__id, isys_group_2_isys_user_session__isys_user_session__id) SELECT '%', isys_group_2_isys_person_intern__isys_group__id, isys_user_session__id FROM isys_group_2_isys_person_intern LEFT JOIN isys_user_session ON isys_user_session__isys_person_intern__id=isys_group_2_isys_person_intern__isys_person_intern__id WHERE isys_group_2_isys_person_intern__isys_person_intern__id='15' (Extended Information: 0) thrown in C:\Inetpub\wwwroot\idoit\src\classes\components\isys_component_dao.class.php on line 212

PHP Fatal error: Uncaught Exception occured in (C:\Inetpub\wwwroot\idoit\src\classes\components\isys_component_dao.class.php:212): isys_exception_dao : DAO Exception: Running transaction has been canceled. Could not isys_component_dao::update() : INSERT INTO isys_group_2_isys_user_session (isys_group_2_isys_user_session__id, isys_group_2_isys_user_session__isys_group__id, isys_group_2_isys_user_session__isys_user_session__id) SELECT '%', isys_group_2_isys_person_intern__isys_group__id, isys_user_session__id FROM isys_group_2_isys_person_intern LEFT JOIN isys_user_session ON isys_user_session__isys_person_intern__id=isys_group_2_isys_person_intern__isys_person_intern__id WHERE isys_group_2_isys_person_intern__isys_person_intern__id='15' (Extended Information: 0) thrown in C:\Inetpub\wwwroot\idoit\src\classes\components\isys_component_dao.class.php on line 212

Ich glaube ihn stören die SELECT '%', angaben. Derselbe Fehler kommt in beta und final Version.

jknuth

kannst du mir mal eine phpinfo ausgabe zukommen lassen ? vielleicht fällt einen ja da was auf

LiesJa · Windows 2003 Server / Apache 2.2.3/ PHP 5.1.6 / MySQL 5.0.24

Hallo zusammen,

Vielen Dank an Jörg, ich habe deine Config.inc.php genommen und meine Pfade und Passwörter angepasst.

–---> und es geht !!!!!!! ;)? warum nur???

Ich sehe keinen nennenswerten unterschied!?!?!

Vielleicht kann mir das mal einer erklären.

anbei die beiden Configs

Gruß und Danke Jan

config.inc.php.meine mit der es nicht geht.txt
config.inc.php.von broesel mit Änderungen mit der es geht.txt

ChristianB

Ich habe die Ausgabe der phpinfo mal anonymisiert und angehangen. Ich werde mir auch gleich mal die config-Datei von Jörg anschauen und testen.

[edit]Das mit der Config Datei hat nichts gebracht.[/edit]

phpinfo.html.txt

ChristianB

Ich habe jetzt mal den debug Modus aktiviert und die zwei generierten Dateien wo der Fehler aufgezeichnet wird angehängt. Bei der debug.txt habe ich nur die letzten paar Zeilen genommen.

Edit:
Ich habe jetzt mal den Query gesucht der hier anscheinend falsch zusammengestellt wird. Ich bin in der Datei src/classes/rights/isys_rs_system.class.php ab Zeile 466 fündig geworden. Der Query sieht so aus:```
$l_q =
"INSERT INTO " .
"isys_group_2_isys_user_session " .
"(" .
"isys_group_2_isys_user_session__id, " .
"isys_group_2_isys_user_session__isys_group__id, " .
"isys_group_2_isys_user_session__isys_user_session__id" .
") " .
"SELECT " .
"'%', " .
"isys_group_2_isys_person_intern__isys_group__id, " .
"isys_user_session__id " .
"FROM " .
"isys_group_2_isys_person_intern " .
"LEFT JOIN " .
"isys_user_session " .
"ON isys_user_session__isys_person_intern__id=isys_group_2_isys_person_intern__isys_person_intern__id " .
"WHERE " .
"isys_group_2_isys_person_intern__isys_person_intern__id='" . $p_person_id . "'";

$this->m_dao_group->update($l_q);

?>
Ich habe den mal geändert und siehe da es funktioniert:
$l_q =
"INSERT INTO " .
"isys_group_2_isys_user_session " .
"(" .
"isys_group_2_isys_user_session__isys_group__id, " .
"isys_group_2_isys_user_session__isys_user_session__id" .
") " .
"SELECT " .
"isys_group_2_isys_person_intern__isys_group__id, " .
"isys_user_session__id " .
"FROM " .
"isys_group_2_isys_person_intern " .
"LEFT JOIN " .
"isys_user_session " .
"ON isys_user_session__isys_person_intern__id=isys_group_2_isys_person_intern__isys_person_intern__id " .
"WHERE " .
"isys_group_2_isys_person_intern__isys_person_intern__id='" . $p_person_id . "'";

$this->m_dao_group->update($l_q);

?>

Von der Variante das auto_increment Felder mit "%" automatisch gefüllt werden können habe ich ja noch nirgends was gelesen. Ist das eine versteckte Funktion von MySQL 4?

[debug.txt](/uploads/_imported_attachments/migrated/46_debug.txt)
[debug_request_10316540.txt](/uploads/_imported_attachments/migrated/47_debug_request_10316540.txt)

lhendrichs

Ich kann den Fehler bei mir so nachstellen.. mit einem W2K, XAMPP System (frisch aufgesetzt)

Mit der Config von Brösel gehts dann auch.. jetzt müssen wir mal sehen wo da die Unterschiede sind.

CU

Lars

npotthast

Der Standardeintrag bei mysql für solche Felder sollte in der Tat eher "DEFAULT" lauten und nicht "'%'".

AEckert

3 Seiten an Infos. Was ist nun die Loesung? Ich habe naemlich genau das gleiche Problem.

LiesJa · Windows 2003 Server / Apache 2.2.3/ PHP 5.1.6 / MySQL 5.0.24

Hi,

Was ist nun die Loesung?

Das kommt drauf an, würde ich sagen.
Erstens ist wichtig welche Systemumgebung du hast.

Wenn es ähnllich ist wie meine, dann würde ich einfach meine o. a. config.inc.php nehmen und deine Pfade anpassen, dann sollte es gehen!!

Gruß

Jan

will_idoit_soon

ich habe ebenfalls dieselbe Meldung bekommen (nach admin/admin Eingabe–> Mandantenauswahl --> no password specified! ), sowohl auf IIS6 als auch mit Apache 2.2.3, jeweils auf Windows Server 2003 mit MySQL 5.0.27, PHP 5.2.0, kein Upgrade von Beta, sondern Neuinstallation. Soweit zu kommen war schon ein kleiner Kampf, aber jetzt würde ich gerne auch noch zum Ziel kommen, diese neue Version zum Laufen zu bekommen... also, wenn die Entwickler config files oder anderes brauchen, einfach schreien... und ich schick sie...

Merci

will_idoit_soon

Hallo,

gibt es eigentlich nun jemanden, der die finale Version so richtig zum Laufen gebracht hat??
Ich habe alles von diesen Seiten hier ausprobiert, Files ersetzt, editiert usw. aber ich komme nicht über
die sch…...rottige Fehlermeldung "No password specified!" heraus.
Habe wie ChristianB mit der php.ini gespielt, ohne Erfolg.
Habe Brösels config.inc.php verwendet (natürlich mit Pfad- und Benutzeranpassung usw.), ohne Erfolg
Habe md5 admin Eintrag gelöscht, wie oben beschrieben... usw und so fort... alles nichts gebracht.

Hat noch jemand n Tip oder seid ihr auch am Ende mit Eurem Latein??

Will-I-do-IT, soon ????

LiesJa · Windows 2003 Server / Apache 2.2.3/ PHP 5.1.6 / MySQL 5.0.24

Ja bei mir läuft es wie oben beschrieben!!

Aber es kann ja eigentlich nicht sein, das dieser Fehler bei (fast) allen auftaucht, und die Entlickler das nicht in den griff bekommen haben innerhalb eines Monats!! :((((

npotthast

Hi an alle,

ich habe mir noch einmal ein Testsystem aufgesetzt und endlich auch den "Weißer Bildschirm"-Bug sowie den "No password specified"-Bug reproduzieren können. Ersterer Bug deutet auf einen Ausgabefehler hin, der durch die Ausgabe eines Headers hervorgerufen wird, nachdem aber anscheinend schon etwas ausgegeben wurde. Lange Rede kurzer Sinn, wer ein System hat in dem diese Fehler noch auftreten, mag doch bitte einmal die Dateien in der unten stehenden URL in sein i-doit Verzeichnis packen. Es werden die index.php und die hypergate.inc.php überschrieben, diese sollten also vorher gebackupped werden.
Ich bitte danach zu berichten

http://www.i-doit.org/downloads/patch_2357.tar