Final Version 0.9 Anmelde Probleme
-
Noch was, beim Update wird ja die Config.inc.php geändert. Allerdings wird der Eintrag für "Job Control System Settings" nicht übernommen.
hab es jetzt manuell aus der .old genommen:
PS: /* The JCS user must have admin rights to the i-doIT system! */ –-> ist da ein User erforderlich ???
/* JOB CONTROL SYSTEM SETTINGS Variables for the Job Control System. Please care, that crontab_path is writable by the apache user, so the i-doIT Framework can write its changes. On Windows, the crontab file MUST be in the system32-directory, since the CRON Service can only read from this path. On Unix-systems, you should make a soft link from /etc/cron.d/i-doit or whatever your cron directory is to webroot/i-doit/cron/crontab. Also make sure, that you are allowed to use the crontab command, normally you must write your username into /etc/cron.allow */ $g_jcs = array ( /* The JCS user must have admin rights to the i-doIT system! */ "username" => "", "password" => "", /* Windows systems */ "crontab_path" => "C:\\WINDOWS\\SYSTEM32\\crontab", "cronwin_path" => "C:\\WINDOWS\\SYSTEM32\\crons.exe", /* Unix systems */ "crontab_path" => "C:\\WINDOWS\\SYSTEM32\\crontab", // CRONTAB File path "croncmd_path" => "/usr/sbin/crontab", // CRONTAB Control program /* i-doIT doesn't try to automatically evaluate the process ID of crond, enter the path into cronunix_pid */ "cronunix_pid" => "/var/run/crond.pid", "default" => array( "hour" => 10, "minute" => 30, /*10:30*/ "dow" => 0) /*0=sunday,...,7=saturday*/ ); -
die art wie php eingebunden ist sollte nicht das problem sein. könntest du mir mal deine komplette config.inc.php als pm schicken ?
-
jep erledigt ( PM versendet ) an jknuth
-
jep erledigt
Dann verat uns doch mal woran es lag.
Ich hab leider das gleiche Problem.
Jörg
-
das versuchen wir gerade rauszufinden
kannst du uns ein paar infos zu deinen system geben ?
( update/neuinstall , os , php version , etc … ) -
das versuchen wir gerade rauszufinden
kannst du uns ein paar infos zu deinen system geben ?
( update/neuinstall , os , php version , etc … )// MD5-hashed password for administrative use (current pass is 'admin')
"adminpass" => "21232f297a57a5a743894a0e4a801fc3" // md5('admin')Ich hab einfach diesen Teil " // md5('admin') " gelöscht und schon ging es.
Gruss
Jörg
-
// MD5-hashed password for administrative use (current pass is 'admin')
"adminpass" => "21232f297a57a5a743894a0e4a801fc3" // md5('admin')das klingt schon mal super, hast du alles gelöscht oder nur
// md5('admin')
bei mir klappt das leider nicht!!
-
Ich hab nur den Teil " // md5('admin') " gelöscht.
Allerding nicht mit Notepad/wordpad sondern mit einem HTML Editor.
Beim Speichern der Datei mit Note/Wordpad hat sich die Struktur der Datei verändert und
es ging garnichts mehr.Achso, alles unter Windows, erst die Beta2 installiert dann update auf final.
Gruss
Jörg
-
HAllo Jörg,
tja genauso hab ich es auch gemacht, und bei mir ist immer noch der gleiche fehler.
habe auch die cache-verzeichnisse
- src/themes/default/smarty/templates_c/
- src/themes/default/smarty/cache/
- temp/
geleert, ohne erfolgt.!!
Langsam verzweifel ich
Ach Jörg, hast du die Installerversion von der Beta genommen oder manuell auf ein vorhandenes System (Welche Versionen Apache,php, mysql ?)
-
kannst du mal probieren das mit edit.com zu löschen , das macht aus meiner erfahrung an wenigsten probleme mit linebreaks
-
Hi, habe es mit Notepad ++ geändert, das ist auch ein top tool, mit den zeilenumbrüchen habe ich kein Problem!! es kommt nur immernoch: "No password specified" auch nach der änderung wie Jörg es gemacht hat.
Ich befürchte, das da irgendwas mit der MD5 Verschlüsselung nicht hin haut, doch warum geht es mit der Beta auf dem gleichen system?
Oder es liegt an der Datenbank!?!? ich weiß ja nicht warum diese meldung erst nach dem ich den Mandanten ausgewählt habe kommt. Ich denke mal es wird dann in der Mandantentabelle nach dem User gesucht, aber nicht gefunden!?!? Warum nur? ich habe dem user I-doit schon angepasst und die berechtigungen erneut vergeben, aber alles ohne resultat!!!
Jan
-
Ich bin nach einer kleinen Odysee jetzt ebenfalls bei diesem Problem angelangt. Ich befürchte das das Passwort nicht richtig weitergeleitet wird. In der Datei src/hypergate.inc in Zeile 51 tritt der Fehler auf. Dort wird nachgeschaut ob das Passwort per POST übergeben wurde oder bereits in der SESSION vorhanden ist. Das ist anscheinend nicht der Fall also wird der Fehler wohl auf der ersten Seite liegen, da wo man das Passwort eingibt.
Hier nochmal meine aktuelle Konfig: Windows 2000 SP4 Server, IIS5, PHP 5.2.0, MySQL 4.1.22, Internet Explorer 6 SP1
-
Nach einigem rumprobieren bin ich auf eine neue Fehlerquelle gestoßen. Anscheinend speichert php das Passwort nicht in einer Session. Ich kann mich dunkel erinnern das man unter Windows in der php.ini ein bisschen mit den tmp und session Variablen probieren muss und php auch Schreibrechte in den Verzeichnissen benötigt. Ich habe da schon ein wenig rumprobiert aber noch nichts brauchbares herausgefunden.
-
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 -
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!!!
-
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
-
Ja wäre mal nett
bis morgen
Jan
-
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.
-
-
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.
