Invalid session ID >

Nein, Einfall hier auch nicht.

Aber er hat insofern recht, dass der Cookie-Banner, die Optionen, mit einer Session-ID nichts zu tun haben. Nichts zu tun haben, wenn er es richtig machte.

Das Thema Session-Cookies hatten wir doch schon mal bei der Bundesnetzagentur. War dort nicht das Problem, aber schon mal erklärt.

Eine Session läuft fast überall heutzutage. Bei Deinen Domänen nicht, bei Deinem Forum aber schon. Eine Session ist eine "Sitzung" mit einem bestimmten Cookie dazu. Dieses Cookie ist immer nur so lange gültig, wie der Browser offen ist. Das "Cookies löschen, wenn Browser geschlossen wird" ist also für alle anderen Cookies, Session-Cookies machen das von selbst. Daher hat der Cookie-Banner auch nichts damit zu tun, denn für die ist er nicht zuständig. Session-Cookies sind für die Kommunikation zwischen Browser und Server, Datenspeicherung, aber eben immer nur für eine Session.

Loggst Du Dich mit dem FF hier ein, dann bekommste eine Session, dass Du eingeloggt bist und eben auch mit Infos, was für Einstellungen Du als Nutzer haben willst. Machst Du dann Chrome auf, ist der ausgeloggt, denn die Session zählt nur für den Browser. Der Chrome muss sich also selbst einloggen, dann hat er eine neue Session und eben auch eine neue Session-ID.

Die ID ist nix anderes als eine Identifikation. Dein Browser sendet die Session an den Server und der Server sucht dann anhand Deiner ID danach, ob er überhaupt Session-Daten zu der ID hat.

Das da ist so eine von meiner Seite.

Hier in dem Fall hat die den Namen "PHPSESSID", ist PHP-Standard. Kann aber auch anders sein, durch Umbenennung oder anderes System als PHP. Der Browser schickt also diese ID an den Server und der schaut nach, ob er diese Datei (ist ja nur eine kleine Textdatei) auch hat, also eine mit dem Namen "aaadhn.....". Wenn ja, dann weiß er in meinem Fall, ob die Sortierung vielleicht anders sein soll, Bewertungen schon abgegeben wurden etc. Also alles, was man eben zu einem bestimmten User haben möchte. Oder eben ganz einfach in einem Kundenbereich, ob der User auch eingeloggt ist oder einfach so auf einen internen Bereich zugreift.

Wie gesagt, Sessions werden mit dem Schließen von Browsern automatisch gelöscht, das ist der Sinn davon, die können das gar nicht anders. Daher ist der Cookie-Banner für die auch nicht zuständig und fallen unter die immer wieder genannten "technisch notwendigen Cookies", die man in der Regel nicht abwählen kann.

Alles was da als "Sitzungsende" bezeichnet ist, sind Sessions. In dem Fall eben die eine von oben und noch ein paar andere, von anderer Software auf der gleichen Domain. Die Session oben ist nur zuständig für meine Webseite, die anderen für Admin-Software. Letztere kommen da vom Namen her teils doppelt vor. Ist auch normal, denn der unkenntlich gemachte "Path" ist anders. Sind verschiedene Versionen der Software, einmal v5.1, einmal v5.2. Der Cookie-Banner ist also zuständig für alles, was NICHT bis "Sitzungsende" ist. Normalerweise.

Und wie gesagt, den Fehler kenne ich da nun auch nicht. Kann bei Dir liegen, ja, aber auch beim Provider. Das Problem da ist ja eben, dass diese Geschichten nur zwischen Deiner Software und der Zielsoftware ablaufen. Also irgendwas aus dem Bereich, Dein Browser -> Dein Handy-Anbieter -> dessen Internet-Anbindung -> Zielserver -> Zielsoftware.

Auch schon mehrfach gesagt, das Problem habe ich hier oft genug mit meinen Kalender-Kunden. Die schwören immer auf Gott und die Welt, dass bei denen alles korrekt ist und mein System spinnt. Wenn ich dann zig mal das Gegenteil behaupte, letztendlich sage, nutzen sie bitte mal ein anderes Gerät, das der Tochter oder Frau, dann siehe da..... Es geht plötzlich. Also hier ist der Fall klar. Ihr Browser ist das Problem.

Bei Dir könnte man, wenn Du andere Browser genutzt hast, die ausschließen. Bleiben also oben aus der Liste noch "Dein Handy-Anbieter -> dessen Internet-Anbindung -> Zielserver -> Zielsoftware". Und natürlich wieder mal die zeitliche Nähe zu einer Änderung am System, in dem Fall der neue Cookie-Banner.

Ohne da direkt an Deinem Rechner zu sitzen ist das schwierig, auch ohne zu wissen, was die Zielsoftware genau tut. Derartige Sessions gibt es ja viele. Beim Anbieter selbst funktioniert es. Also scheint die Zielsoftware auch nicht unbedingt das Problem zu sein. Kann aber ein Teil davon sein. Wie schon oft erwähnt, Du hast ein mögliches Problem mit den ständigen IP-Wechseln. Sessions sind "biegsam", aber eben nicht alle gleich. Stichwort: Session Hijacking

Es könnte also einer hergehen und Deine Session-Datei vom Rechner klauen (oder aus der Übermittlung) und bei sich verwenden. Somit hätte er Deine ID, aber einen anderen Rechner. Dem Ziel wäre das eigentlich egal, so lange die ID stimmt. Somit wäre der Fremde plötzlich Du. Das kann man alles weiter absichern, eben auch mit Einbezug der IP.

Dann bei Dir immer wieder das Problem der schlechten Internetverbindung. Ich hatte das ja selbst nun 2 Wochen am Stück. Schlechter Ping, schlechte und tierisch langsame Verbindung. Da hatte ich auch ständig solche Probleme. Eben noch was gemacht, ging, nächster Klick, zack ausgeloggt. Musste mich z.B. alleine für einen Support-Post im Support Forum, während dem Tippen, dreimal neu einloggen. Klar, jedesmal auch die Daten von vorher weg, weil die konnten nicht gespeichert werden. Klar, die Session kam am Ziel nicht korrekt an und das Ziel dachte, ich wäre "neu".

Ich für meinen Fall mache das mit meinen Kalender-Kunden, also denen, die hartnäckig sind und meinen, es ist nicht deren Problem, immer ein erweitertes Logging. Mit deren "Problem" meine ich, deren Browser, Internet-Anbindung etc, also alles, was eben nicht meine Software ist. Und in 99,9% aller Fälle ist es wirklich so, dass immer dann, wenn der Fehler passiert, bei mir am System eine andere Session-ID ankommt als beim Zugriff zuvor oder eben gar keine. Dann kann ich immer nur sagen, ich bin raus, liegt irgendwo bei ihnen.

Die Frage wäre bei "Invalid session ID" also durchaus auch, wie genau diese Fehlermeldung erzeugt wird. Was löst diese Meldung aus? Ist es wirklich nur ein simpler String-Vergleich der gesendeten ID oder ist da noch was anderes?

Und aus Deiner Position eben, alles in der Entwickler-Konsole mitloggen und nachschauen, was der Browser tut. Also welche ID wurde vorher gesendet und welche, bei dem dann danach die Meldung kommt. Sendete er die gleiche wie vorher? Wenn ja, dann wieder die Frage, was ist das für ein Vergleich. Wenn nur String, dann müsste es passen. Wenn was anderes, was genau? Ist es eine andere ID, die gesendet wird, dann wäre hier die Frage nach dem warum. Die ID denkt sich ja nicht der Browser aus, die kommt vom Zielsystem. Also wenn es eine andere ist, dann muss das System dem Browser vorher eine andere gegeben haben. Aber dann hätte man einen Ansatzpunkt, denn das sollte nicht passieren. Passt da alles, dann bleibt noch der andere Faktor, der Internet-Zugang.

Eine Session sollte ja immer gleich bleiben. Also ganz einfach gesagt, einmal ein "session_start", 10, 100 andere Klicks, alles bleibt gleich, dann am Ende ein "session_destroy". "session_start" generiert eine neue ID, aber nur, wenn vorher keine gültige da war. War eine da, dann kommt die alte ID wieder zurück. War die alte aber nicht auffindbar, beschädigt oder fehlte, dann löst das "session_start" eine neue ID aus, wie für einen neuen Besucher. Und dann hat man genau das Problem. Man sendet zwar immer eine ID, aber irgendwann plötzlich eine andere.

Was man natürlich auch bedenken muss, wurde noch nie angesprochen, ist aber auch nur vage, da unbekannt. Die Zeit, also die Dauer der Inaktivität.

Eine Session zählt zwar bis zum Sitzungsende, aber das ist nur das Enddatum, wann sie beendet werden MUSS. Die kann auch schon vorher beendet werden und das ist die Lifetime. Die ist, wenn nicht geändert, in der Regel 24 Minuten (1440 Sekunden). Die wird immer erneuert und neu gestartet, wenn es eine Aktivität gibt, also einen Klick oder ein Script, das quasi eine Aktion im Hintergrund "vortäuscht". Bei mir ist z.B. so ein "Session-Holder" bei Textformularen. Textformulare sind per Definition keine Aktion, wenn man die ausfüllt. Aktion ist der Aufruf der Seite. Wenn man dann aber 30 Minuten lang ein Formular ausfüllt, dann ist die Session im Hintergrund abgelaufen. Beim POST passiert dann genau das Gleiche. Es gibt eine neue Session-ID und das Zielsystem meldet "falsch".

Für so was habe ich, wie oben erwähnt, einen "Session-Holder", der quasi beim Tippen alle paar Minuten einen Request an die Zielsoftware schickt und somit "sagt": "Hallo, ich bin noch da". Dieser Request löst einen neuen Zeitstempel aus, also die 24 Minuten starten dann wieder neu. Hier im Forum macht das z.B. auch der "Autosave", wenn man was tippt.

Wenn die Zielsoftware so was allerdings nicht hat, dann kann der Grund für die Fehler schlicht auch einfach nur die Zeit sein, also ID ungültig, bevor sie gesendet werden konnte. Der Browser sendet dann zwar eigentlich noch die richtige, aber das Ziel sagt: "Nö, zu alt, nicht gültig".

Klar hat Brave das auch. Einfach F12 drücken. Haben alle aktuellen Browser, selbst der IE, nur bei allen schaut es halt anders aus. Das Bild ist vom Firefox und eben in der Console oben der Reiter "Webspeicher". Sollte dann direkt so die Ansicht kommen, wenn nicht, links auswählen, was man möchte, gibt ja verschiedene "Webspeicher". Also in dem Fall, da es um Session geht, "Cookies" und dann die entsprechende Domain.

Dein Bild da sagt nicht viel aus. Der Scriptfehler (rot) sollte aber nicht sein. Kann natürlich auch ein Fehler der Webseite sein, aber auch am Browser liegen. Dieses "null" kommt gerne, wenn man eine Funktion aufruft, die der Browser nicht kann.

Wegen dem "Webspeicher" noch mal. Bedenke, Du hast einen uralten Firefox. Ich habe keine Ahnung, wie das dort heißt oder ob der das schon hat. Kommt ja ständig was neues dazu.

Im Chrome, Edge und Brave (sind ja alles Chromium-Browser) schaut es so aus, hier in englischer Version vom Brave.

Aber das was Du schreibst hört sich genau nach dem an, was die Fehlermeldung ist, zumindest in die Richtung. Eine Seite aufrufen, das geht noch. Irgendwas machen, Formulare ändern (zählen nicht als Aktivität) und dann beim Senden ist die Session weg und man muss sich neu einloggen.

Du müsstest dazu aber nicht die Ansicht nehmen, sondern das "Network". Und dort als erstes "Preserve Log" aktivieren, also die Ansicht nicht automatisch löschen lassen. Dann wird quasi alles protokolliert, was Du durchklickst (aktiv). Also auch der Seitenaufruf an sich und dann das Absenden der Seite, wo danach der Login wieder kommt.

Also wären da unter anderem eben die drei Seitenaufrufe drinnen.

1. Aufruf der Seite (Daten ändern)

2. POST der Seite

3. Weiterleitung an den Login

Und zu allen dreien kann man sich die Daten ansehen, also auch die Cookies inkl. eben Session, was gesendet wurde. Wird dann eine sehr lange Liste, jenachdem, wie lange man ohne zu löschen aufzeichnen lässt und wie viel die Seite lädt, aber es ist eben alles enthalten. Die eigentlichen Seiten, aber auch Bilder, CSS, Scripte etc. Ist alles unwichtig, aber die Seiten an sich halt. Und dort eben wie im Bild unten dann die entsprechenden Daten, die gesendet wurden. Hier heißt die Session nicht "PHPSESS", sondern in meinem Fall "wsc_xxx_user_session", aber der Wert danach, die ID, die sollte dann bei jedem Zugriff und Klick gleich bleiben. Wenn nicht, dann kennt das Zielsystem dich nicht mehr.

Sehe da gerade Deine Requests.... Keine Ahnung, ob das was zu sagen hat, aber eine Session-ID kann auch, wenn Cookies nicht geht, in der URL stehen. Das ist ein uraltes "Notfallsystem" und funktioniert oft nicht richtig. Bei Dir in der Liste steht eine ID dabei. Das kann alles mögliche sein, aber eben auch die Session-ID. Jedenfalls ist sie nicht gleich.

Kann man da nun nicht rauslesen, höchstens schätzen, aber das ist auch mehr als vage. So wie das aber sein KÖNNTE warst Du auf dem Login (erster GET) inkl. dem GET vom css. Dort war eine ID. Dann haste einen Post ausgeführt, könnte das Absenden der Zugangsdaten sein, dann kommt wieder ein GET vom Login, aber mit einer anderen ID. Sprich, der eigentliche Login bzw. die Prüfung hat Dich rausgeworfen, daher der 302 zurück zum Formular.

Schaut so aus, könnte man so lesen, kann aber auch alles andere sein. Dazu müsste man das System kennen.

Meinst Du die Fehlermeldung da, oder wo anders?

Die löse ich quasi hier aus, wenn ich den Login so wie bei Dir in der Liste angegeben, einfach mit einer x-beliebigen ID aufrufe. Also ich muss die extra angeben. Fülle ich den Login einfach nur aus und sende in ab, dann kommt bei mir keine ID in der URL, aber eben die Meldung, dass die Zugangsdaten falsch sind.

Nö, ich mache das nicht am alten FF fest. Ich sagte nur, dass ein "null" so entstehen kann. Mein zweites Bild war ja dann extra vom Brave und anfangs schrieb ich ja auch, dass Deine Browser es nicht sein werden, da Du ja eben einen anderen, eben Brave, auch versucht hattest.

Das Problem ist nur, ich habe hier nur den neuen FF und wenn ich was aus dem Poste und Du nachfragst, dann kann ich nur sagen, was ich hier habe. Ich weiß nicht, was der alte FF an Einstellungen / Optionen / Tabs hat und wo genau dort was zu finden ist. Es gab in den alten Versionen Möglichkeiten, die der neue nicht mehr hat, aber dafür hat der viele, was der alte nicht hat.

Daher eben das zweite Bild von Brave, denn die sollten bei uns beiden gleich sein. Nur den kenne ich halt nicht auswendig, das ist im Grunde ein Chrome und mit dem arbeite ich normalerweise nicht.

Das mit dem "Session in URL" und "uraltes Notfallsystem" war auch nicht auf den Browser bezogen, sondern eher auf die Config oder andere Probleme. Cookies können Browser schon sehr sehr lange. Daher wird dieses "Session in URL", eigentlich auch nicht mehr verwendet. Muss bei der Webseite auch nicht so sein, schaut aber "etwas" danach aus. Hatte das früher selbst als Fallback drinnen und hatte da auch immer wieder seltsame Probleme auf der Seite. Ein Request, wo man die ID in der URL vergessen hatte, eine Weiterleitung, wo der Webserver vielleicht was "vergessen" hatte, und zack, schon fehlte sie bei einem Zugriff und beim Nächsten kommt eine neue. Per Cookie macht das der Browser halt komplett alleine, da muss man als Entwickler der Software sich nicht drum kümmern.

Merke auch gerade, Du meinst mit #2 oder #4 die Post-Nummer. Also auch mit dem #2 den zweiten Post, dachte Du meinst mein Bild Nr. 2. Diese Ansicht da, die Du da hast, mit den Texten, JS-Hinweisen, teilweise Zugriffen, das ist mehr oder weniger die eigentliche "Konsole". Das ganze Tool, das ich auch immer als "Konsole" bezeichne, also das F12, sind die Entwickler-Tools. Die hießen früher aber einfach mal "Dev-Console". Die Ansicht von Dir ist ein Teil dieser "Tools".

Die Ansicht von Dir ist quasi hier bei mir im FF der Reiter "Konsole". Im Bild mit einem blauen Oberstrich versehen.

Meine anderen Bilder stammen aus den Bereichen "Netzwerkanalyse" und "Web-Speicher". Aber wie gesagt, da weiß ich nicht, wie das im alten FF ausschaut. Im neuen wären die Einstellungen z.B. auch die drei Punkte "..." rechts oben neben dem "x". Da kann man "Reiter" zuschalten oder entfernen. Das wird bei Dir auch anders sein.

Im Brave ist es analog, hier aber in englisch. Also "Network" und "Application". Deine Ansicht ist im Brave analog dazu der zweite Reiter "Console". Die braucht man eigentlich so gut wie gar nicht, es sei denn, man möchte JS-Fehler sehen, so wie bei Dir da einer ist. Oder man möchte selbst Befehle eintippen oder Code. Daher ist am Ende auch das ">>", zumindest bei mir. Bei Dir ist es glaube ich eine Eingabezeile irgendwo.

Na extra eingeben muss ich die ID bei der Fehlermeldung. Wenn ich da sonst einfach was mache, dann wandere ich nur zwischen index.php/ und CSS hin und her, aber eben ohne irgendwann mal eine ID in der URL zu haben, so wie bei Dir. Du hast da ja "http://index.php/id/0123456/a/os" . Erst wenn ich diesen Wert, also alles nach "index.php" mit anhänge, dann kommt der Fehler der falschen Session-ID. Die Kennung da in der URL hat also schon was zu bedeutet, was genau weiß nur der Betreiber. Wenn es aber eine Session-ID ist, dann müsste die gleich bleiben. In Deinem Bild oben sind aber zwei verschiedene. Aber hier, wie gesagt, das sind nur Spekulationen, denn ich kenne das "dazwischen" nicht. Also was genau ist nach "Login".... dann irgendwas machen, dann "Fehler und logout". Das "irgendwas machen" kenne ich nicht.

Allgemein: So Aussagen wie "ich habe nix gemacht", also vom Betreiber, sind immer mit Vorsicht zu genießen. Kann stimmen, kann auch unwissentlich falsch sein. Gut, das Loginformular oben ist wirklich sehr einfach, an dem kann es, vom Quellcode her, nicht liegen. Das ist noch einfacher gestrickt, als Deine Webseiten. Aber was eventuell danach kommt und was auf jeden Fall davor auf der eigentlichen Webseite, das ist ein ganz anderes Kaliber. An dem Frontend davor hat er vielleicht auch nichts gemacht, aber vielleicht ein anderer. Da sind ja gefühlt 100 andere Bibliotheken, Skripte und Co. eingebunden. Da muss er also selbst wissentlich nichts gemacht haben, aber einer der Paketanbieter. Diese rot markierte JS-Fehlermeldung bei Dir im Bild, die kommt ja auch irgendwo her. Hier ist die nicht. Aus dem Login-Formular selbst kommt sie auch nicht, denn dort ist kein Javascript eingebunden.

Auch wenn es nun zu weit geht, aber als Beispiel. EMCA-Script (ES), sagt Dir nix, ist aber egal. Das ist die Grund-Bibliothek von Javascript, auf Basis derer Browser ihre JS-Parser implementieren. Wir sind aktuell bei Version ES12. Ich nutze hier Funktion oder will es, aus dem Bereich ES6. Warum? Kürzer, einfacher zu schreiben, schneller, moderner, sicherer als das aktuell verwendete ES4 und 5.1. Der IE10 kann laut dessen Angaben ES6. ABER!!! Diese Bibliothek besteht ja aus 10.000den an Funktionen teilweisen noch mit weiteren Abhängigkeiten anderer externer Erweiterungen. Der IE10 kann ES6, aber nicht alles davon, nur gefühlt 80%. Und nutzt man nun was aus den anderen 20%, dann hagelt es in der Konsole auch so was wie "null". Und was genau dann nicht geht kommt immer drauf an, was genutzt wurde und für was. Bei mir waren es z.B. Bildergalerien. Die großen Bilder wurden einfach nicht angezeigt, konnten nicht geladen werden, nicht geladen, weil der IE10 die Syntax vom JS-Code auf Basis von ES6 nicht versteht. Es lief also alles am Code, wirklich alles, nur diese eine Codezeile nicht. Und diese eine ist eben die Auslesung der URL vom Bild. Klar, wenn das nicht geht, dann geht auch nix anderes.

Code-Beispiel, für so einen Mist. Aus Wikipedia:

kleine als ES9 war so

let objectClone = Object.assign({}, object)

ab ES9 ist das möglich

let objectClone = {...object}

Also man sieht, eine kürzere Schreibweise. Schon gehen aber die Probleme los, denn.... Der IE10, kann ES9. Er kann auch die verkürzte Schreibweise, die hier eingeführt wurde. ABER. Der IE10 kann in einigen Situationen das "let" nicht. Das gab es aber schon in ES8! Das modernste, was man da also für den IE10 in dem Beispiel schreiben kann ist eine Mischung aus ES7 + ES9. So ein Schwachsinn. Gott sei Dank, hört das mit dem IE bald auf. ABER, der Apple Safarie ist kein Stück besser. Der hat die gleichen Probleme. Vieles an neuen Funktionen wird von diesem "modernen Silikon-Unternehmen" nicht unterstützt.

Das ist leider das Dilemma mit alten Browsern oder eben auch modernen Browsern, die behaupten was zu können, es dann aber nicht 100% tun.

Und das sind eben auch so Dinge, wo ein externes Script was geändert haben kann / könnte und man selbst "nichts gemacht hat".

Wenn Du sagst, es geht nun nach einem Reset wieder, dann achte doch mal drauf, ob nun die IDs in der URL, also in dem Bild von Dir, das zu hattest, gleichbleiben, wenn Du im Kundenbereich was machst.

Wenn es ein Windows-Reset war, so wie ich das verstanden habe, dann nein. Da gibt es keine Info, was da genau gemacht wurde.

Mich persönlich wundert es auch, dass es danach wieder ging. Ich will nix über alte Browser sagen, aber es gehört zum Satz dazu. Der Reset resettet ja auch möglicherweise Einstellungen von Software. Das würde aber keinesfalls erklären, warum Brave und Co auch nicht funktioniert haben und es jetzt wieder tun. Das muss also was gewesen sein, das als "Problem" alle Browser einschließt, also eigentlich was auf der Seite von Windows. Ich wüsste aber nicht, was das sein soll.

Höchstens was, was Du schon vermutest, dass was anderes irgendwie auf dem Rechner mit aktiv war. Das Thema hatten wir aber doch auch schon oft genug. Viren und Spyware, Adware und Co.

Mich wundert auch Dein gestriges "der leitet mich nun an /en/" weiter. Habe das hier auch versucht. Bin dort normal auf die Startseite, dann auf das Loginformular, was eingegeben und abgesendet, dann kommt ja das "nackte" Formular auch mit der roten Fehlermeldung. Ich wurde NICHT weitergeleitet. Und das schreibe ich extra nun mit dazu, dass ich eben per VPN in Madrid war, also im Grunde wie Du mit Deinem Mobil-Anbieter. Aber keine Weiterleitung an /en/.

Das sind Fehler, die lassen sich so nicht klären. Eventuell sind es auch nur Kleinigkeiten, wo was in den Angaben fehlt, etwas Wichtiges, was der andere nicht als wichtig erachtet. Oder es ist so was, wo man einfach sagen muss: "vergiss es, mach platt und neu".

Kleinigkeiten: So was hatte ich Anfang des Jahres. Auch wieder der Kalender und eben genau so was. Login geht, keine Fehlermeldung, Zugangsdaten wurden akzeptiert, dann ein Klick und zack, Loginmaske wieder da. Ungelogen, wir haben hier 2 Tage, in Summe etwa 9 Stunden rumgemacht. Ich bin auch schon verzweifelt, denn eigentlich ist es genau der Fehler, wo ich sage, zu 99,9% ist es der Browser und Cookies. Das war da aber nicht der Fall, es ging auf keinem Rechner, auf keinem Browser. Wir haben Stunden telefoniert. Irgendwann schickte ich per Mail einen Link und die Antwort war "geht". Gut, super, alle zufrieden. 30 Min später, Anruf: "geht wieder nicht". Wie gesagt, Stunden telefoniert. Hier schon die Protokollierung an, alles mitgeloggt. Der Anrufer, auch nicht viel Ahnung von Rechnern, aber so weit gebracht, dass er über die Console auch mitloggt. Denn ich sehe ja nur, was hier ankommt. Und das war genau so: Eigentlich alles richtig, aber ich sehe hier auch den automatischen Logout. Ich sehe aber auch, dass das Session-Cookie fehlt. Die Frage also, warum es fehlt, fehlte ja in allen Browsern. Alles was mein System hier hätte als Fehlermeldungen protokollieren hätte müssen, wenn einer ausgelöst wurde, war richtig. Wir versuchten es ja absichtlich mit fest vorgegebenen Fehlern. Alles richtig erfasst, also den Fehler. Aber warum der Login nicht geht, keine Ahnung. Brave auch schon installiert, Router gecheckt. Mittlerweile telefonierten wir schon zu viert. Er, ich, seine Frau und die Tochter war auch noch dabei. Alle unterschiedliche Geräte und Browser, aber alles welche, die ich exakt so auch da habe. Also Test 1zu1 möglich. Ging bei denen nicht. Er sagte immer mal wieder was von "klicke auf Admin".... Naja, wie gesagt, er ist unerfahren. Ich fragte zig mal nach, auf was er da genau klickt, denn bei mir gibt es keinen Link der "Admin" heißt. Antwort nur sinngemäß, na der Link hier zum Login. Dachte dann, das wird schon passen. Dann sogar über Google gegangen, dass der auch wirklich auf meiner Seite ist und nicht bei einem anderen Kalender. Hatte ich auch schon oft. Geht nicht, Daten falsch etc. Dann waren das noch nicht mal meine Kunden.... Passte auch alles. Irgendwann dann mal die Server-Logs einzeln durchgegangen, denn irgendwie muss er ja an die Login-Maske kommen. Er klickt ja angeblich einen Link an. Muss also bei mir auf der Startseite oder sonstwo gewesen sein. Nein, da ist nix zu finden. Dann in der Console zusammen geschaut. Da erzählt er mir dauert was von "Ferienhaus an der Elbe". Ich sage ständig, nicht das vorlesen, das interessiert nicht, das ist Ihre Domain, sie müssen auf meine. Auf seiner ist ja der Kalender eingebunden, der ist aber nur eine Ansicht, die Verwaltung ist bei mir. Aber ich finde bei mir dennoch nichts, wie er an das Formular kommt. Frage noch nach, ob er ein Lesezeichen verwendet. Naja, Gegenfrage: "was ist ein Lesezeichen?". Letztendlich schickte er mir dann einen Screenshot und ich dachte ich spinne. Seine Webseite ist auch uralt. Nutzt noch so wie früher Frames. In dem Hauptframe ist mein Kalender eingebunden und wird angezeigt. Alles richtig so. ABER! Er hat unter dem Kalender von seinem damaligen Admin einen Link "Admin" angelegt bekommen. Dieser Link führt zu meinem Login-System. Also sieht er immer genau das, was ich auch sehe. Nur er sieht es eben nicht als reine, eigenständige Seite, sondern als "Frame". Daher auch in der Console das ständige "Ferienhaus an der Elbe". Der füllte also immer das geframte Formular aus. Die Daten kamen bei mir an, waren richtig, dann der Kundenbereich. Dort loggte mein System dann aus, weil Session-ID falsch. Klar war die falsch! Weil das Frame die ID gar nicht sendete, darf es nicht! Lange Rede, kurzer Sinn. Hätte er mir gleich einen Screenshot geschickt, wäre das Problem nach weniger als 2 Minuten gefunden gewesen. Oder eben wichtige Infos nennen.

^ ^

^ ^ Meine Seite in seinem Frame. Geht alles, nur halt der Login nach dem Absenden nicht, da kommt der Logout.

Und ich muss dazu sagen, das ist ein Nutzer, der hat schon immer Probleme. Ich wusste nie, welche er hat. Hatten schon vorher oft Kontakt per Mail, weil der Login nicht geht. Er sagte immer, er geht nur nach einem Kennwort-Reset, aber nur einmal. Genau das war das gleiche Spiel. Nach einem Reset bekommt er eine Mail mit einem Link. Wenn er den anklickt, ist er auf meinem System in einem neuen Fenster / Tab. Das geht. Wenn er es dann wieder versuchte, nutzte er wieder seine Seite und seinen Link und meine Domain war wieder im Frame. Das ging schon fast ein Jahr so.....

Das hat mit Dir nichts zu tun, aber so Kleinigkeiten können es eben auch sein. Wobei ich mir bei Dir da nicht sicher bin, ob der Rechner nicht doch möglicherweise verseucht ist und Deine Anfragen da irgendwie abgefangen / umgeleitet werden.

Da gab es doch mal einen Fred dazu, ist aber schon Jahre her. Die üblichen Verdächtigen halt. Malwarebytes und Co eben.

Nein, das zeigt schon das an, was es besagt. "Beschreibung" ist der Wert, den das System selbst festlegte oder man eben manuell eingegeben hatte, wenn man selbst einen Wiederherstellungspunkt anlegte. IN dem Fall sind da also zwei Wiederherstellungspunkte, die durch ein "Windows Update" erstellt wurden. Unter "Typ" steht, was es für ein Typ der Sicherung war. Also bei den Updates eine Sicherung für ein "wichtiges Update". War also kein Optionales oder so, sondern ein "wichtiges". Als Typ könnte da auch "manuell" stehen, wenn man eine Sicherung selbst anlegt oder "Installation", wenn eine Programminstallation eine Sicherung machte. In dem Fall steht bei "Beschreibung" dann auch der Programmname, das da installiert wurde.

In der Liste werden keine "Wiederherstellungen" angezeigt, sondern Sicherungen. Die beiden da sind also Wiederherstellungspunkte, weil die wegen einer "Rücksicherung" (Wiederherstellungsvorgang = Rückgängig) erstellt wurden.

Entsprechend bedeutet "Wiederherstellungsvorgang" -> "Rückgängig", dass ein die Aktion eben von "Wiederherstellungsvorgang" ausgelöst wurde und das vom Typ "Rückgängig". Sprich Du hast das Programm "Systemwiederherstellung" genutzt und dort die Funktion "Rückgängig", also einen alten Datenpunkt installieren lassen. Dieses Fenster zeigt ja den "aktuellen" Stand der vorhandenen Sicherungen an und ist kein Abbild / Protokoll aus der Sichtweise einer älteren Zeit. Du hast da in dem Bild also 4 Sicherungen, zwei von Updates und zwei den Rücksetzungen.

Dass alte Datenpunkte verschwinden ist normal. Das ist das Problem mit Sicherungen. Das System kann ja schlecht sichern, zurücksetzen, dafür muss es auch erst mal sichern, dann beim Zurücksetzen, die Sicherung(en) auch sichern um dann ein System mit alten Daten zu nutzen, das seinerseits ja auch wieder Datenpunkte aus älteren Sicherungen hat und gleichzeitig, nach der Rücksetzung, einen neuen Sicherungspunkt anlegen muss (Typ Rückgängig). Also da sind ja quasi Sicherungen von Sicherungen von Sicherungen drinnen und das teilweise eben einfach "vorwärts", aber wenn zurückgesetzt wird, auch rückwärts.

Wegen Deiner Frage vorher, was betroffen ist bzw. geändert wurde. Das siehst Du nicht, also nicht nach dem Vorgang. Das sieht man an der Stelle aber vor dem Vorgang über den Button "Nach betroffenen Programmen suchen". Wobei das auch nicht 100% stimmen muss, denn das betrifft in der Regel nur Daten / Programme / Dienste, die sich am System auch ordentlich "melden" bzw. registrieren.

P.S. Wenn man eine Rücksetzung im "Abgesicherten Modus" macht, dann werden alte Datenpunkte automatisch gelöscht.

Also bedenke, wie oben schon geschrieben, bei derartigen Aktion sind rein technisch quasi Backups in Backups. Die Liste zeigt aber nur die "aktiven" an. Mögliche Backups, die in einem Backup stecken, werden nicht angezeigt, die sind nicht "aktiv". Auch wird das System diese nicht unbedingt mitsichern, sondern vor dem neuen Backup zwar nicht löschen, aber eben nicht sichern. Wäre ja ein Unding. Überlege mal das Datenvolumen.

Und bedenke auch, es betrifft nur offizielle Programme und Treiber. Im Grunde das auch nur "bedingt", denn das System ist gedacht, um Windows wiederherzustellen. Es kann / wird / muss auch Programme und Treiber ändern, aber es zeigt ja an, dass die danach möglicherweise nicht mehr funktionieren. Grund ist einfach: Nur das nackte Programm an sich wird "zurückgesetzt", also z.B. ein Firefox von v97 auf v96. Es werden aber keine Einstellungen / Addons etc. von 97 auf 96 zurückgesetzt. Wenn da also was nicht kompatibel ist, dann geht das mit 96 nicht mehr. Und ebenso, es kommt drauf an, welche Laufwerke überhaupt gesichert werden. Bei mir hier ist das z.B. nur Laufwerk C. Die E, F, G und H haben gar keine Sicherungen, denn auf denen laufen keine Windows-Dienste und sind daher per Default ausgeschlossen.