Beiträge von Synonym

Cura, auch wenn sich das von Dir nun eher witzig anhört, so in etwa dachte ich das ja. Aber halt mit "direkt kaufen". Klar, könnte sein, dass die dann keiner kauft, hätte aber auch sein können, dass die nach dem Schürfen nix wert sind. Gut, Unterschied, Rechner arbeiten lassen versus Geld ausgeben.

Gibt doch auch so einen, der "Weinständer" aus altem Holz baut. Anfangs nur für sich, dann für einen Freund, dann hat das einer gesehen und wollte es auch haben, kaufen. Ging dann so weiter, nun ist er eine kleine Manufaktur.

Du hast oben was von "Luft ist Luft" geschrieben. Stimmt, würde ich auch sagen. Ich kenne aber auch einen, der verkauft Luft

Aber noch mal zu den Coins.... Wenn die also geplant waren, dass sie mal was wert werden und eventuell Zahlungsmittel, gleichzeitig das Schürfen am Anfang ganz einfach war, da viele da und Hashes schnell errechenbar, Stromkosten gering, gleichzeitig noch dazu kommt und eben insbesondere, das Ganze nur für eher eine kleine eingefleischte Gruppe war, wäre es da nicht möglich gewesen, da extrem einfach zu betrügen? Also so im Sinne, ich hol mir da mal ein paar Coins, ist ja einfach, kostet nix und warte einfach ab bis die anderen "Spinner" den Preis hochtreiben.

Ich meine, ich verfolge das ja auch schon lange. Gehörte auch zu denen die sagten "was für ein Mist". Aber ich denke mal, als das bei uns überhaupt bekannt wurde und so richtig auf dem Schirm landete, da waren ja schon Jahre vorbei und das ganze lief ja schon, eben in kleinen Kreisen / Gruppen. Der eigentliche Hype kam ja erst, als es irgendwie weltweit "Mode" wurde und dann auch noch Banken und Staaten anfangen, das nutzen zu wollen.

Also im Grunde wie ein Schneeballsystem, ganz knapp anschneidend. Da ist ja auch eigentlich nie wirklich ein Wert. Und die echten Gewinner sind die, die damit anfingen und dann andere arbeiten lassen. Die "anderen" sind beim Coin eben alle anderen Leute, Läden etc, die den Handel damit erst ermöglichen.

Sei doch froh, das sind wenigstens Händler, die man anrufen und fragen könnte. Ich suchte neulich was wichtiges, hatte die genaue Typbezeichnung und was kam? Nur chinesisches Zeug Rein so nach dem Motto, die weltweit mit am meisten verkaufte SSD hat keine Infos in anderen Sprachen, auch nicht in Englisch, nur in Chinesisch.

Ah, die hatte ich sogar auf dem Schirm oder damals auch diese Surfbars, wo man sich Werbung anschaute und dafür Punkte bekam. Aber ok, nun verstanden. Ist halt so, wie es ist und das Ergebnis erst mal gewünscht, aber nicht sicher. Dieses "schürfen" ist quasi nur der Anreiz gewesen, ist ja ein anderes Umfeld, wo das erst mal aufkam, also eher Bereich Nerds und technikaffin.

Das Problem mit den Bildern sollte nun weg sein, hoffe ich. Das habe ich gefühlt schon seit Oktober 2021. Kam von jetzt auf gleich. Auch bei der Silvester war es plötzlich so. So wie es scheint liegt das irgendwie am Server-Push. Die Scripte kommen wohl zu schnell und das eingebettete "async" wird dann ignoriert. Sprich, das Script wird sofort ausgeführt und dann ist eben das DIV noch nicht da. Das würde den Fehler erklären.

In dem Fall war es noch nicht mal ein Fehler der Bilder, oder Lazyload oder irgendwas davon, sondern das Cookie-Consent-Script, das den "Revoke-Button" suchte, der aber noch nicht da war. Naja, nicht da war im Sinne von, er steht fest im Quelltext, aber der war wohl noch nicht verarbeitet, als das Script ausgeführt wurde. Und dessen Fehler "null" blockierte dann auch die anderen Scripte.

Da scheint also im Bereich Push und async irgendwas anders zu funktionieren, wenn ein Tab im Hintergrund geöffnet wird. Könnte gut sein, dass der Browser da dann zwar die Scripte schon ausführt, aber den DOM noch gar nicht eingelesen hat.

P.S. Suchergebnisse.... Nun haben die Links auch noch eine andere Farbe als vorher.....

Heute Morgen:

jetzt:

Dieses Gebastel von Google nervt. Gibt genug, das nicht richtig funktioniert, da ändert sich aber nichts.

Nun mit der neuen Farbe bin ich mit der "Kaufen" aber wieder auf P3. Diese komische und leere Seite der geranien_de ist nun auch aufgestiegen, auf 5, war vorher 15 oder so.

Sagt mal, hat einer von euch Erfahrungen mit den HTML Tags "<details>" und "<summary>"? Ich suche hier gerade nach einer Lösung, langen Text auszublenden und eben per Klick einzublenden. Aktuell mache ich so was mit Javascript, habe da nun aber eben "<details>" und "<summary>" gefunden.

Hat einer Erfahrung und weiß, wie sich das bei Google verhält?

Aktuell im Einsatz habe ich es hier in der FAQ: https://www.geranien-pflanzen.de/geranien-frage…ternativen.html

Da ist die Nutzung recht einfach, aber ich habe eigentlich andere Dinge damit vor. Mein Ziel ist, langen Text "ausklappbar" zu machen. Also Beschreibungen, die z.B. 1000 Wörter lang sind, dass dann nur 200 angezeigt werden und bei einem Klick die restlichen 800.

Ich habe nur keine Ahnung, wie Google das mit der Syntax wertet, denn "summary" bedeutet ja eigentlich was anderes.

<details>

<summary>

Hier der "klickbare Text"

</summary>

<p>"Hier der versteckte Text"</p>

</details>

In der FAQ oben im Link ist es ja einfach gehalten, da ist "Summary" die Überschrift und der "hidden Text" die eigentliche Beschreibung. Für mein Vorhaben wäre aber <summary> ein Teil des eigentlichen Textes und somit ziemlich lang, eben die Länge, die "normal" sichtbar sein soll, der Rest erst beim Klick.

Hat einer Erfahrungen oder kennt Seiten, die das aktiv nutzen?

Danke

Sodale, es ist der 23.2. Das mysteriöse Datum ist ja bisher immer der 22. gewesen und was soll ich sagen, es ist wieder das Datum bzw. teils auch der 21.

Ich beobachte hier ja auch andere Seiten und Domänen, die nicht im Index sind, nicht seit Anfang Dezember 2021. Alle haben das gleiche Problem, alle das gleiche Verhalten. Einige davon gingen am 21.2. nachmittags online. Bei meiner Geranien merkte ich da auch schon ein Zucken im Sinne von, es fehlen plötzlich wieder Seiten. War nur für ein paar Stunden, dann wieder wie vorher. Die "Kaufen" ist auch auf P3 geblieben, wo sie seit dem 22.1., als sie wieder da war, platziert wurde. Am 22.2. morgens war sie dann sogar auf Platz 2, den ganzen Tag bis ca. 18 Uhr.

So, heute morgen.... Die "kaufen" ist nur noch auf Platz 7. Von den vorher indexierten 43 Seiten fehlt nun noch eine weitere. Sind nur noch 42 im Index. Gleichzeitig hat Google die Anzeige der Anzahl an Treffern entfernt. Ob das überall so ist, keine Ahnung, hier ist es jedenfalls nicht mehr vorhanden.

An den anderen Domänen hat sich nichts verändert. Was fehlte, das fehlt immer noch. Vielleicht fehlt da noch mehr, keine Ahnung. Bei tausenden Treffern kann ich da nicht durchzählen, ist schon bei 43 mühsam. Bei der Nordsee, bei der eigentlich alles weitergeleitet wird, sind 80% der indexierten Seiten noch oder WIEDER die alte URL.

Die Geranien, also die Zugriffe von Google, sind weiterhin so wie vorher. Also immer wieder das Gleiche abrufen, so als ob es nur 8 Seiten geben würde. Eine von denen, die ständig abgerufen wird, ist nun weg.

Lunte

Bilder habe ich leider gar keine mehr, vor allem keine "guten". Die Pflanzen gibt es ja schon seit 10 Jahren nicht mehr, habe ja keinen Balkon mehr. Alles was da nun an neuen Bilder online geht, stammt aus öffentlichen Sammlungen

Das mit den Vorschaubildern habe ich auch schon bemerkt. Ich habe keinen Schimmer, warum das so ist. Das ist nur, wenn man die Seite in einem neuen Tab öffnet. Lädt man sie direkt, sind die Bilder da. Reloaded man, sind sie auch da. Das ist auch nicht nur bei der einen Unterseite so, sondern bei allen Bildern, die per LazyLoad geladen werden. Die Console wirft auch Scriptfehler, da kommt das Problem her, ich weiß aber nicht, wo der Fehler herkommt. Das Script sucht ein DIV, das es laut Meldung nicht findet. Das Div ist aber da. Es hagelt aber (Achtung Cura), einen Fehler "Uncaught TypeError: b is null". So als ob das Script geladen wird, bevor der DOM da ist, was aber nicht sein kann. Und, wie gesagt, das ist nur bei einem Öffnen in einem neuen Tab. Habe keinen Schimmer, wo das herkommt. Ich schalte derzeit überall das Lazyloading ab, aber das dauert.

Das hier schaut von der Technik her wie Dein zweiter Code-Teil aus, ist aber technisch völlig anders, mit anderen Joomla-Klassen, wie

use Joomla\CMS\Factory;

use Joomla\CMS\HTML\HTMLHelper;

use Joomla\CMS\Uri\Uri;

https://github.com/joomla/joomla-…mpl/default.php

Auch der von der 4.0-DEV ist völlig anders:

https://github.com/joomla/joomla-…mpl/default.php

Der von der 3.10-DEV schaut sehr ähnlich Deinem da oben aus:

https://github.com/joomla/joomla-…mpl/default.php

Wenn Du da mal schaust, dann gibt es von diesem mod_custom etliche "neue Versionen". Alle sind Entwicklungsversionen, aber für Joomla 4.0, 4.1 und schon 4.2. Aber es hagelt auch dort Fehler ohne Ende und die reichen von "Syntaxfehler" über "fehlende Felder in der Datenbank", falsche Berechtigungen für Dateien und Co.

https://github.com/joomla/joomla-…ules/mod_custom

Also könnte man sagen, Lunte, das ganze war anfangs auch nur ein Test, eine Art Spiel, ein Wettstreit durch Begehren. Hätte ja auch so sein können, dass da Leute die Coins schürfen, aber die dann keiner haben will, nicht getauscht werden, nicht gehandelt werden, nichts eben.

Also wie in Farmville diese goldenen Eier, rosa Hühner und blauen Einhörner. Jeder wollte sie haben, aber letztendlich war es nutzlos, denn es entstand nie ein Markt dafür. Man konnte sie unter den Spielern nie tauschen / handeln, andere Dinge schon.

Da kommste an einem Backup nicht sauber vorbei. Strato wird recht haben und es an etwas da oben liegen, aber! Das ist ja nur ein Teil vom Template. Die beiden Scripte da oben inkludieren ja auch andere Dinge, nutzen andere Funktionen. Der Fehler kann also auch tiefer stecken, wird halt nur dort aufgerufen oder eben über Dritte und Vierte eingebunden.

Du kannst also davon ausgehen, dass bei einem Aufruf von "$module->" im Hintergrund noch 100 andere Funktionen aufgerufen werden. Wenn eine von den 100 nun einen Fehler hat, dann kommt die genau auf diesen Aufruf zurück. Der Fehler wird hier dann "angezeigt", ausgelöst wurde er aber ganz wo anders.

Ehrlich gesagt ist da in den beiden Code-Teilen auch nicht viel drinnen, was einen Fehler 500 auslösen könnte, wenn schon so was wie das "$params->" oder das "$module->", aber wie gesagt, das sind nur Aufrufe hier, die Funktion selbst befindet sich viel tiefer im System.

Wenn Dein System ein Upgrade machte, dann wurde auch das Template bedacht und entsprechend in die Datenbank geschrieben. Das sind ja nicht nur Dateien auf dem Server. Also die einfach per FTP überschreiben geht nicht, denn das ändert ja die Datenbank nicht. So ist es durchaus möglich, dass das neue Joomla Datenbankfelder geändert hat, die eigentlich migriert werden mussten, aber das Template nicht kompatibel war. Was nicht kompatibel ist, kann nicht migriert werden, also hat es die alten, eventuell nicht mehr vorhandenen Datenbankfelder bzw. versucht sie zu nutzen.

Ein Fehler 500 deutet ja eher darauf hin, dass eben eine Funktion oder Klasse aufgerufen wird, die es nicht gibt. Oder eine Funktion so geändert wurde, dass die Syntax vom Aufruf nun eine andere ist. Oder eben, dass ein Datenbankabruf nicht funktionierte, das kann z.B. bei unbekannten / umbenannten Tabellenfelder der Fall sein. In dem Fall gibt es keine vernünftige Fehlermeldung, nur ein "500".

Wenn es das Template ist, dann war der Fehler, dass Du das vorher nicht deaktiviert hast. Also vor dem Upgrade zurück auf das Default-Layout von Joomla, auch wenn die Seite dann scheiße aussieht. Dann Upgrade, wenn es funktionierte, das eigene Layout wieder. Das wird dann schon sagen, ob es installierbar ist oder nicht.

Daher das mit dem DEV von Alex. Er meinte, ich übersetze einfach mal, eine Kopie Deines funktionierenden Systems erstellen und mit der alles durchtesten. Wenn es geht, dann im echten System machen. So würde nur das Testsystem ausfallen und nicht das eigentliche, das online ist.

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.

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.

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".

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.

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.

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.

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.

Ähm, nee, das ist alles schon einen Schritt zu weit. Meine Frage oder mein Problem ist, warum muss man das "schürfen". Wenn die Coins an der Börse sind, dann sind die ja schon im normalen Handel und können normal gekauft und verkauft werden. Zu dem Zeitpunkt wurden die ja schon geschürft.

Mir geht es um die Entstehung. Da ist also erst mal nix. Dann erfindet einer so einen Coin. Das ist auch erst mal nix. Das ist eine Software, die in dem Fall die Anzahl limitiert und die Schwierigkeit erhöht. Zu dem Zeitpunkt ist kein einziger Coin an der Börse oder ist handelbar, die muss man erst schürfen. Aber warum muss genau das so sein? Das "schürfen" erbringt so gesehen ja auch keinen Wert / Leistung für den Coin, denn die Ausgaben dafür (Gegenleistung = Strom) geht an andere Unternehmen. Man gibt also dem Energieversorger z.B. 1 Eur, damit man dann mit seinem Rechner einen Coin erschürft und den dann bekommt. Warum also kann man den Coin dann in diesem Fall nicht einfach für einen Euro kaufen? Wäre doch im Grunde nichts anderes, als eine Auktion. Je weniger da ist, desto teurer wird die Ausgabe. Genau das ist ja auch beim Schürfen der Fall. Wobei "teurer" hier bezogen ist auf die Energiemenge.

Irgendwann, vor sehr langer Zeit, als die normalen Währungen entstanden sind. Waren damals auch noch keine, sondern eher Tauschobjekte wie diese lokalen "Zahlungsmittel" (eine Art Wertmarken), da musste man auch keine Handstände machen, damit man einen "roten Stein" bekam, sondern eben eine Arbeit oder Dienstleistung erbringen. Die erbrachte man aber gegenüber dem Anbieter des "roten Steins". Dann hatte man "rote Steine" und irgendwann, wurden sie zum Tausch genommen, Tausch gegen Güter oder Arbeitsleistung. Dann würden sie Zahlungsmittel, dann mal geändert in Münzen, dann von Mark zu Euro etc. Das ist auch alles schon später, aber alles hat mal mit dem "roten Stein" angefangen. Der "rote Stein" wurde aber nicht erschaffen, weil man für jemanden anders was gänzlich anderes tut, sondern der war "einfach da" und man bekam ihn, weil man für dessen Besitzer was machte.

Wie gesagt, mir geht es um die Entstehung. Nicht das danach, wenn die schon da sind.

Geld, Scheine, werden einfach gedruckt.

Aktienpapiere kommen auch einfach so, auf Basis des Firmenwertes und des Ausgabepreises.

Andere fiktive regionale Währungen werden auch einfach so gedruckt. Der Wert kommt dann mit der Nachfrage und Nutzung.

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".

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.