Jump to content
Froxlor Forum
  • 0

Andauernder Erneuter Login


H4nSolo

Question

Hallo Liebe Froxlor Community,

 

derzeitig beschäftige ich mich mit einem sehr koriosen Problem was mich, je länger ich damit zu kämpfen habe, zur Weisglut bringt.
Aktuell benutze ich die letzte Froxlor Github Version und muss mich permanent neu einloggen.
Dabei spielt es keine Rolle ob ich mich als Admin oder Kunde anmelde.
Der automatische Logout kommt nach einer unbestimmten Zeit und egal welcher Aktion

Beispiel Ablauf:
- Logge mich als Admin ein
- Bearbeite die Domains
- Werde gewzungen mich neu anzumelden und  vorherige eingegebene Daten sind verschwunden bzw nicht gesichert worden

- Logge mich erneut ein
- Wähle Kundenverwaltung
- Klicke auf Kunde
- Werde gewzungen mich neu anzumelden...

Ja ich habe schon die Sessiontime für die Logins erhöht und weitere einstllungen probiert, jedoch ist dies nicht mein Fehler bzw ändern nichts an dem permanenten wiederanmelden.
Ich habe auch schon in den Webserver logs nach Fehlern geschaut aber da wird sowohl in den access als auch im Error Log keinerlei Fehlemeldung angezeigt.

Bei mir spielt es ausserdem auch keine Rolle welche Browser ich benutze da bei allen (sowohl aktuellster FireFox als auch Chrome / Opera Browser) das selbe Phenonem auftritt.

Daten:

Root: OVH Dedicated Root (4kerne, 64gb Ram 2TB HHD)
OS: Ubuntu 16.04 LTS
Webserver: apache2 (version 2.4)

 

Ich hoffe das ihr mir weiterhelfen könnt.

Sollte ich etwas an Informationen vergessen haben, bitte bescheid geben.


lg H4nSolo

Link to comment
Share on other sites

13 answers to this question

Recommended Posts

Hallo D00p,

ich stehe gerade etwas auf dem Schlauch.
Wie meinst du das mit PHP eingebunden.

Ich habe nach der Webserver Installation über SSh die Packete PHP und die dazugehörigen packete (php-common, php-mysql,etc) über apt-get nachinstalliert.
Diese sind auch in /etc/apache2/mods-available drin und in /etc/apache2/mods-enabled liegt auch eine saubere verknüpfung auf die php5.6.load sowie php5.6.conf

In den Apache logs sehe ich derzeit keine ungewöhnlichen aktivitäten was auf den Fehler hindeutet.
 

Im /var/customers/tmp oder /tmp ist nichts drin was vom webserver kommt und irgendwelche sessions abspeichert.
Der /var/customers hat alle lese und Schreibrechte (testweise mal auf 0777 gestellt) ohne ergebnisse

 

lg H4nSolo

Link to comment
Share on other sites

Also mod_php. Und nicht gucken ob in den Ordnern was drin ist sondern Berechtigungen anschauen (sollten beide 0777 sein). Und dann Schauste Mal in die PHP.ini was da so bzgl Session steht. Nach einer Default Installation aber sollte das alles problemlos funktionieren, sicher daß das alles Default ist?

Link to comment
Share on other sites

Ok ich habe es jetzt auf meine Internet verbindung begrenzt.

Derzeit gehe ich über einen T-Online Hotspot mit vpn zugang ins Internet.
Da meine Verbindungsqualität hierbei nicht die beste ist, gehe ich mal davon aus das ich zuviele unterschiedliche anfragen an den Webserver schicke, der meine meine identität bzw session andauernt verliert und meint das ich nciht angemeldet wäre.

Gott sei hab ich ab Mittwoch besseres Internet.

Habe jetzt mal für mein Problem einen umweg genommen und richte grade alles über eine Windows VM  vom Root direkt aus ein. [Keinerlei Probleme]
Nun hänge ich aber vor dem nächsten Problem.
Ich kann es hier ja mal anschneiden in der Hoffnung das ich das hier auch gelöst bekomme, am sonsten eröffne ich dafür einen neuen Thread.


Neues Problem:

Ich habe  nun erfolgreich die benötigte Domain eingerichtet und würde gerne auch einige subdomains der Haubtdomain über https haben. (phpmyadmin, webmail, gameserverpanel, etc)
Die Subdomains sind auch erfolgreich angelegt und entsprechende einstellungen für https wurden erstellt.
Wenn ich jetzt zbsp auf meine subdomain http://panel.mgc4you.de gehe, werde ich auch sofort auf https umgeleitet.
Hier endet jedoch das schauspiel den die jeweiligen https Seiten sind nicht erreichbar.
Lets encrypt hat erfolgreich für die betroffenenden Domains bzw subdomains die Zertifikate erstellt und werden beim Webserver neustart auch nicht bemängelt oder sonstige.

Ich erhalte nur meldungen das er die Zertifikate eungebunden hat.
Ein Check der Ports war auch Positiv. Also Offen.

 

Ich hoffe das man mir da weiter helfen kann.

 

lg H4nSolo

Link to comment
Share on other sites

job ich bin derzeit dabei die sachen wieder einigermassen nutzbar zu machen.

Wenn ich es jedoch wieder umstelle, wird auf die https seite weiter geleitet aber dann passiert nicht mehr.
Im FF wird mir angezeigt das die Seite nicht erreichbar ist, Im Chrome sagt er mir das die verbindung abgelehnt wurde.

Ich hatte jetzt mal testweise auf dem Root die Seite per ssh aufgerufen (openssl s_client -connect adresse:https)
und erhielt am anfang den ssl code gefolgt von Zertifikats Informationen und am ende den Quelltext der Seite.
Im Quelltext sagte er mir dann das er die Seite auch nicht aufrufen konnte (Fehlermeldung 400 Bad Request)
 

Ich habe das gleich  jetzt mal mit der subdomain http://owncloud.mgc4you.de/ gemacht.
Hier passiert wieder das gleiche.

Seite wird aufgerufen -> weitergeleitet zu https -> Seite nicht aufrufbar...

 

root@mgc4you:~# openssl s_client -connect owncloud.mgc4you.de:https                                                                                                              CONNECTED(00000003)
depth=0 C = FR, ST = Roubaix, O = Internet Widgits Pty Ltd, emailAddress = mc@mg                                                                                                 c4you.de
verify error:num=18:self signed certificate
verify return:1
depth=0 C = FR, ST = Roubaix, O = Internet Widgits Pty Ltd, emailAddress = mc@mg                                                                                                 c4you.de
verify return:1
---
Certificate chain
 0 s:/C=FR/ST=Roubaix/O=Internet Widgits Pty Ltd/emailAddress=mc@mgc4you.de
   i:/C=FR/ST=Roubaix/O=Internet Widgits Pty Ltd/emailAddress=mc@mgc4you.de
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFPDCCAyQCCQCdjP7n7yUH3jANBgkqhkiG9w0BAQsFADBgMQswCQYDVQQGEwJG
UjEQMA4GA1UECAwHUm91YmFpeDEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQ
dHkgTHRkMRwwGgYJKoZIhvcNAQkBFg1tY0BtZ2M0eW91LmRlMB4XDTE3MTIxMTIw
NDY1NVoXDTE4MTIxMTIwNDY1NVowYDELMAkGA1UEBhMCRlIxEDAOBgNVBAgMB1Jv
dWJhaXgxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEcMBoGCSqG
SIb3DQEJARYNbWNAbWdjNHlvdS5kZTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBAMUJtgggANLaBXytbmVAANMD0tqadgUge+Xn3SQm33Dwx5FBkkn0ErOR
2C/CaakP35JkZK/kTbCGbDGTnkjCuzgdglG5dFTsZWz4pI3WDDmZdVjowgeDU8zd
o1VL3y3XL5y7KgAK9vmuNqNJBSG2z4SdUe3unKm7Tf7yDq4/yXAe2YOdv+msH/vM
0FmqHUu4A1BkzOLgWn4lQ7q3yCmSXVterrKb5PfIIqZlVz45kBPgYWLN9bjRHyaq
fr98gzcWdWgqKBkGpTmEocR483mGDWc9Vo6nYRVwhDXgXmP9kG5VMB0hxcMfsSDA
YAwbP5795ZfMERckFjv+Gp6PWZIW9kzTUS7c+9J9pce4SpBwVTmiLFoj7Ek5GsEz
+hxcYODYjW54wGfbefltnS1vj0GpAmxx2gKDVNgTPms6hcxrxPQJJPmNhNuTFah7
lll+LfEl2wy1swyIDFfTdR5P9i57doqHvS2YdDE+AMLfzLU6E7XrtTzDJDLcrT/o
bwyeQC4Jh9iFrz5Ryn8nj15//W1eZwnDRLVYsCS7TYFe+wbOphmtu2lTXmtJ51gt
PDYIPfPMx8SZBaIyuFCn0oX4DzUJgT+Y4eCShdGmdoiqEAoiXRkvDmPnEWdc/GQe
GAO/1XdOJOpFAC6krlNufjYZkbbQQNj1d/xUG4uGUyQrDZbVQHWDAgMBAAEwDQYJ
KoZIhvcNAQELBQADggIBAChxMliaSZDNGImrTywDi14nLaC2lg29vGjPKnAwPnPB
Y50KHhUZRMYNRbgmGi8eKiCXIQ4TlL030cQD9Wo1Lnb/V4Q49ttox1hTw8NOblLO
2jNCqs3g6TJwV5MyIDiGtIuk0FIFqQGq+b03MSKxr6jUd6GH8CvO1550olgMIk+5
VKVvMR9cewf7Mb5fVO3DwfSGxMdXkn3Ytjajv6MhcsbF3q3QCJKG+ecw80McFFa2
dy4zaB9i8XeXc87lB5j5BJT9a6NRVK9EKsqG1QqItznNuxmj2UxS/jWbbxUjpA19
foQywMvKAyWO145ZHm+i0g3WqS2le/V7RcgSgBbJu6Ldb4q2pmKY+8tc0lBZBpE6
whtBe+8c20hHkXptRYVFWDWU01zRu6GGPUdopVs0dAGeG8vrKPgg1ONzxMMwKWfr
5AKVyoK/8MBUFI+sgHttpaz11Uwl2vOtRlKjz6w/+8qLUbV65o5X8NBMrFww3VSL
2n6Li6DTWLDPZRmeykrZ0xND6h0ieLeLkfriduAPbTaRfTT43cpKY4VysxzcsD0w
3ajSX4FzLlE+V1AWCAd4G3hk5VUBT0LgOG4x9lrn/VGi61axWsnXqStI4LSvbWZW
gzMK304Ah/q12Vq3/ddEZpDvskORy68u2aeJ2nMSW8j2ji5rUYCygxdu3B6iyuai
-----END CERTIFICATE-----
subject=/C=FR/ST=Roubaix/O=Internet Widgits Pty Ltd/emailAddress=mc@mgc4you.de
issuer=/C=FR/ST=Roubaix/O=Internet Widgits Pty Ltd/emailAddress=mc@mgc4you.de
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2286 bytes and written 302 bytes
Verification error: self signed certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 931AC99FAF65EE89432117DD3586ABBAC4B507F3A8B1D2F785E8DA1251D0FD70
    Session-ID-ctx:
    Master-Key: 0386798F0D9563834DE3073A7B9EE7656EDAE640F6A1592D6A5396C44123ACB8                                                                                                 BDAD2CDA755D4C9D7146052CD0821B48
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 09 e9 4d 4e e7 99 46 7c-f3 0b 50 cb a0 fe 2f 30   ..MN..F|..P.../0
    0010 - d5 06 00 87 23 39 59 39-bf 67 9d fc 69 85 65 4c   ....#9Y9.g..i.eL
    0020 - 73 d1 31 0a 07 54 93 ae-01 5e 7e d1 a8 f8 e7 72   s.1..T...^~....r
    0030 - 35 f7 4c 46 08 73 bf 79-23 d0 d8 00 d3 39 be ff   5.LF.s.y#....9..
    0040 - 0f 9a 53 fe a8 25 d4 5f-9d 73 36 28 b5 38 2f 4e   ..S..%._.s6(.8/N
    0050 - 37 fc 83 60 bf 49 4b 45-88 cc 03 31 01 d0 ad 23   7..`.IKE...1...#
    0060 - 3f 0d 1b 3e b0 e2 7b f9-f0 b1 89 82 21 8e 35 d2   ?..>..{.....!.5.
    0070 - f8 5c 1b 71 07 52 26 78-eb 58 15 ab f3 e0 c6 3c   .\.q.R&x.X.....<
    0080 - 8d 14 17 f2 ba 58 6e 07-9d 2f 46 41 ae f8 2d 43   .....Xn../FA..-C
    0090 - a2 46 34 00 6e e3 f2 f2-d0 63 83 84 cb c8 ab 1d   .F4.n....c......
    00a0 - 94 1f 02 21 e3 f8 b6 e4-70 e8 f4 98 cb 04 a7 a8   ...!....p.......
    00b0 - 39 17 c5 ae 25 bc e6 74-a6 3b 76 c4 42 f2 37 c6   9...%..t.;v.B.7.

    Start Time: 1513073867
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
---

HTTP/1.1 400 Bad Request
Date: Tue, 12 Dec 2017 10:17:48 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 303
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at mgc4you.de Port 443</address>
</body></html>
closed

 

Link to comment
Share on other sites

10_froxlor_ipandport_94.23.6.180.80.conf:

# 10_froxlor_ipandport_94.23.6.180.80.conf
# Created 12.12.2017 11:49
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

<VirtualHost 94.23.6.180:80>
DocumentRoot /var/customers/webs/mgc4you/mainsite
 ServerName mgc4you.de
</VirtualHost>

10_froxlor_ipandport_94.23.6.180.443.conf:

# 10_froxlor_ipandport_94.23.6.180.443.conf
# Created 12.12.2017 11:49
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

<VirtualHost 94.23.6.180:443>
DocumentRoot /var/customers/webs/mgc4you/mainsite
 ServerName mgc4you.de
 SSLEngine On
 SSLProtocol -ALL +TLSv1 +TLSv1.2
 Protocols h2 http/1.1
 SSLCompression Off
 SSLHonorCipherOrder On
 SSLCipherSuite ECDH+AESGCM:ECDH+AES256:!aNULL:!MD5:!DSS:!DH:!AES128
 SSLVerifyDepth 10
 SSLCertificateFile /etc/apache2/apache2.pem
 SSLCertificateKeyFile /etc/apache2/apache2.key
</VirtualHost>

 

 

Sachen sollten eigentlich soweit stimmen.

Oder muss als Zertifikat das von /etc/ssl/froxlor-custom/mgc4you.* rein?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...