Beiträge von Arne Drews
-
-
Du vermischst da 2 Sachen. Einmal Sessions und Cookies. Die Sessions werden zerstört wenn der Browser komplett geschlossen wurde oder wenn der Befehl gegeben wurde, dass diese zerstört werden soll. Den Cookies gibt man eine feste Laufzeit. In dieser Laufzeit sind sie, auch egal ob der Browser bereits geschlossen ist, vorhaden. Außer man gibt auch da den Befehl, dass der Cookie zerstört werden soll.
Ich würde eher sagen, dass Du gerade etwas trennen willst, was eigentlich zusammengehört bzw. fast das gleiche ist.
Sessions verwenden Cookies. Dass die Session "zerstört" wird, wie Du schreibst, liegt daran, dass die Cookies ausschließlich für die Session-Lifetime definiert wurden: Session-Cookies eben.
Du beschreibst inhaltlich lediglich den Unterschied zwischen Cookies mit und Cookies ohne Expiration, letztere sind sog. Session-Cookies, wie sie von Sessions verwendet werden. Cookies sind es jedoch in beiden Fällen!
-
Kann man die session auch sofort Löschen ?
Lest ihr die Doku zu den Dingen, die ihr produktiv verwendet?!
PHP<?php session_destroy();Wenn ich den Broweser schliese und mein Sohn ihn wieder auf macht ,müsste er doch aus den Chat rausgeflogen sein und kann auf meiner session nicht weiter chatten .Oder geht das doch noch wenn die Session auf den Server noch nicht gelöscht wurde ?
Eine PHP Session sendet auch nur einen Cookie an den Client. Findet er die Information nicht mehr, kann darüber auch keine Assoziation mehr hergestellt werden. Daher: Session-Cookies.
Also Websocket Ja oder Nein und Warum ? Danke für die Antworten
Ein Socket Server wird als Dienst/Service gefahren, Polling hingegen findet per Script zur Laufzeit statt.
Der Vorteil von Websockets liegt hier u.a. bei der Performance.
Ich sag mal von meinem Standpunkt aus: Definitiv JA!
-
Betroffene Firmen schaffen es sehr oft noch nicht einmal Hoster zu Schadensersatzzahlungen zu bringen.
Sofern das Hosting managed ist, ist das weniger ein Problem, bei dedicated ist es klar, da liegt die Verantwortlichkeit bei den Firmen.
Du darfst bei Deinen Aussagen nicht die Tatsachen vermischen.
Das Prozess-Risiko ist viel zu gross, wenn es darum geht, so einen "home hoster" auf Schadensersatz zu verklagen.
Klär mich auf, welches Prozess-Risiko? Ein Unternehmen hat doch keine Angst, einen Privat-Hoster zu verklagen?
Man merkt, dass Du da nur theoretisierst. Ich bin bereits vor einigen Jahren verklagt worden und weiß wovon ich rede. Nicht wegen Server-Hosting, aber der Grund ist hier irrelevant. Host Europe war der Kläger und denen war es scheiß egal, wie klein ich war und wie ich eine Klage finanziell bewältige! Ich habe sogar mit dem Geschäftsführer seinerzeit telefoniert, der mir zusicherte, dass er sich darum kümmern wolle. Natürlich tat er es nicht. Die beauftragen wie andere Unternehmen auch Anwälte, gegen die Du als Little People selbst mit eigenem Anwalt äußerst geringe Chancen hast.
-
Anstatt document.write würde ich zu appendChild raten.
Und es ist grundsätzlich auch nicht ratsam, diese DSGVO relevanten Hinweise/Möglichkeiten Themen per Script zu lösen, damit bist Du weiterhin abmahnfähig.
-
Aber bei PHP-Sessions hast Du doch schon einen SessionCookie, wofür brauchst Du denn noch einen?
-
ich setzte den Cookie immer mit session strat , wie macht man das den ohne Expiration ?
Je nach Browser:
Codedocument.cookie = 'foo=bar; expires=0; path=/'; document.cookie = 'foo=bar; path=/'...halt ohne Expiration!
Oder auf SessionStorage umsteigen:
CodesessionStorage['foo'] = 'bar'; alert( sessionStorage['foo'] ); -
Pack den Text nochmal zusätzlich in einen <span> und gib diesem den entsprechenden Background.
Am besten auch gleich per externer CSS-Definition und nicht als Inline-Style!
Wenn Du etwas Abstand am Rand des Text benötigst, gibst Du dem <span> ein display:inline-block; und setzt padding entsprechend.
-
Setz doch den Cookie ohne Expiration Angabe, dann ist das ein Session-Cookie und sollte beim Schließen des Browsers wech sein.
Ob das auch für Tabs gilt, weiß ich adhoc nicht, musst Du mal versuchen.
Ansonsten mal mit onbeforeunload oder onunload testen
-
-
nein da irre ich mich nicht. Ein einzelner Server, der SPAM verschickt wird sehr schnell abgestellt und kann nicht viel SPAM verschicken. Und dem eine Rechnung dafür zu schicken ist derartig sinnlos, dass das wahrscheinlich niemand versucht.
Das bestätigt, dass Du damit noch keinen Kontakt hattest. Technisch betrachtet stimmt das zwar, was Du sagst, aber wenn ein Betroffenes Unternehmen Dich als Server-Verantwortlichen zur Anzeige bringt, zahlst Du!
-
Damit ich Dich nicht falsch verstehe: LibreOffice ist in diesem Zusammenhang kein Beispiel, sondern Du willst wirklich ein HTML-Dokument damit per Template zusammenbauen, in dem Du die Bilder per Drag & Drop eingebettet hast und dieses Dokument dann auf dem Server ablegen.
Der Webserver soll erkennen, dass eine neue Version vorliegt und dies mit Verlinkung anzeigen?
Ist das soweit richtig?
-
Ich finde JavaScript und Ajax super und verwende das in fast allen meiner Projekte.
Aber für mein Empfinden sollte eine grundlegende Funktionalität einer Website auch heute noch komplett ohne Scripte funktionieren.
Ich als Entwickler weiß ja nie, was für lokale Browser-Einstellung oder Plugins meine Besucher installiert haben.
Es gibt etliche Script-Blocker, die immer beliebter werden. Da macht es für mich keinen Sinn, grundlegende Menü-Funktionalität auf JS/Ajax zu begrenzen.
OnTop ja, als Kosmetik und Usability. Aber nicht als grundlegende Funktion.
Es sei denn, man ist sich bewußt, dass man damit ungewollt User ausschliesst.
-
das mit der Haftung beim SPAM verschicken, ist in er Praxis eher nicht das Problem.
Na denn hoffe ich mal für Dich, dass Du nie in die Situation kommst und merkst, dass Du Dich irrst.
-
Ich frage mich immer noch, was bei einem Klick auf ein Menüpunkt im Produktivmodus passieren soll, sprich: wie wird der Content geladen?
Steckt da ein Ajax-Request hinter oder die Standard Funktionalität der <a>-Tags?
Denn wenn auf Klick ein Standard HTTP-Request erfolgt ( also kein Ajax! ), sehe ich noch nicht, dass die CSS Pseudoklasse :active hinterher greift.
-
Dann wird das ganze nicht im WWW betrieben, sondern sozusagen in einem Intranet?
Dann wären frames tatsächlich noch eine Alternative.
Die beste Alternative wäre allerdings die Initiative Deiner beratenden Funktion.
Du musst Deinen Chef davon überzeugen, dass die Umsetzung keinen Sinn macht, wenn Du den Code der zweiten Seite dahingehend nicht anpassen darfst.
Der Aufwand steht in keinem Verhältnis.
-
Ohne ein preventDefault() oder stopPropagation() wird die Standard-Aktion ausgeführt und die basiert beim Klick halt auf dem href, erzeugt also einen neuen Request. Ich könnte mir vorstellen, dass es damit zu tun hat, denn Browser verhalten sich schon mal unterschiedlich.
-
Wenn Du den bei Dir zu Hause hosten willst, solltest Du es allein schon aufgrund von brainstuff #2 lassen.
Wenn der wirklich online verfügbar sein soll und Du nach einem Server-Buch für Anfänger fragst, hoffe ich mal, dass hier keiner Dir weitere Hilfe dazu geben wird.
Ein Server ins Netz zu stellen birgt mehr Verantwortung, als Dir lieb ist!
Versendet Dein Server bspw. irgendwann mal Spam ( aus welchem Grund auch immer ), trägst Du die komplette rechtsgültige Verantwortung!
Ich selber habe auch nur Grundkenntnisse für Webserver, aber ich habe eben auch einen Hoster meines Vertrauens, der verantwortlich für die Sicherheit und deren Konsequenzen ist ( solange meine eigene Scripte nicht schuld sind, natürlich ).
Ein Server im eigenen Haus ist das sinnloseste, was man in diesem Bereich machen kann, wenn man nicht Super-Experte ist!
Und selbst dann sollte man das aus Haftungsgründen überdenken.
-
Ich will es ja nicht mit Google realisieren
War Dein Beispiel, ich habe es nur aufgegriffen.
ich habe eine Interne Seite die ich aufrufe da was eingeben kann und dann wieder umschwenke auf die vorherige Seite also wird es rechtlich keine Probleme geben. Nur kann ich den Code der zweiten Seite nicht verändern.
Wie bereits erwähnt, Quelltext der Seite laden und nur den Form-Part in den Layer einbinden, Kurze Frage dazu: Wenn es Deine interne Seite ist, warum kannst Du diese dann nicht verändern?! Das klingt für mich, als fehlen uns Informationen, um Dir einen vernünftigen Lösungsweg zu zeigen. Evtl. geht es ja viel einfacher oder gar nicht. Erzähl mal bitte detailliert, was Du hast und was Du willst.
Wenn es zu umständlich ist dann gibt es ja noch den Weg einfach zwei Fenster offen zu haben und die erste Seite in den Hintergrund zu schalten und einfach nach 30 Sekunden die erste Seite wieder in den Vordergrund zu schalten.
Ist dieser Weg einfacher ?
Klingt für mich nach keiner sinnvollen Lösung, auch wenn es funktionieren könnte.
Du hast zwei Seiten, angeblich beides Deine. Wenn Du ein Formular der zweiten in der ersten anzeigen/verwenden willst muss es einfachere Wege geben.
Der Knackpunkt ist, dass Du behauptest, die zweite Seite nicht ändern zu können?! Warum???
-
Das Beispiel setzt aber voraus, dass das CSS dynamisch Server seitig generiert wird.
Ich weiß nicht, ob das dem TE so wirklich hilft.
