Exploit

Now I have had a look at the HTTP requests. What happens is not the same as when I try to log in with the wrong password. In summary, the following happens: Request: POST index.php, what is striking here is the cookie line of the request, in which the PHPSESSID variable is set twice with two different values! Response: 302 to customer_index.php, Set-Cookie: PHPSESSID=(new value) Request: customer_index.php, Cookie: PHPSESSID set twice again Response: 302 to index.php No error message appears, as after entering an incorrect password, After deleting the cookies in the browser, the login also worked under Windows! Conclusion: something messes up the Session Cookie.

Same I have here with an account from a client. From my linux machine the login works fine, from a windows machine not. I didn't dive into the used login procedure, but I guess that the cause is something with the character set. I've noticed issues with an previous froxlor version from the last year, where it helped to remove the browser cache. On both machines, Linux and Windows, I've been using Firefox.

Jetzt habe ich diesen Fehler auch bekommen. (Version 2.0.19-1) Zwei Dinge: 1. Wenn man nach der Fehlermeldung wieder zum Formular geht, ist alles wieder leer, das ist kein Problem, aber etwas ärgerlich. 2. Wenn eine Neue Domain angelegt wird und die DNS-Einträge von Froxlor angelegt werden müssen, geht das in die Hose. Letzteres habe ich mit einem 'Workaround' gelöst, indem ich die domain zuerst ohne Let's Encrypt angelegt habe.

Hello, I'm trying to provide an SSH shell access to customers on an Debian Bullseye. So far the usernames are shown properly in the system but the loggin in with SSH is rejected. The path in "/var/lib/extrausers/passwd" is always set to "/bin/false" even if I set the "List of available shells" in Froxlor on "/bin/bash", while the cronjob does create the files. Any Idea, why the path is not what I would expect to be set in the passwd file?