2008-09-18 10 views
7

Ich habe ein wenig selbst getestet (Während der serverseitigen Verarbeitung eines DWR Framework Ajax Request-Handlers, um genau zu sein) und es scheint, Sie können Cookies erfolgreich manipulieren, aber das geht gegen vieles, was ich auf Ajax am besten gelesen habe Praktiken und wie Browser interpretieren die Antwort von einem XmlHttpRequest. Hinweis habe ich getestet auf:Können Sie einen Cookie während der serverseitigen Verarbeitung eines Ajax (XHR) -Aufrufs zuverlässig setzen oder löschen?

  • IE 6 und 7
  • Firefox 2 und 3
  • Safari

und in allen Fällen Standard-Cookie-Operationen auf dem HttpServletResponse Objekt während Ajax-Request Handling waren richtig Ich würde gerne wissen, ob es am besten ist, die Cookie-Manipulation auf die Client-Seite zu schieben, oder ob dieser (viel saubereren) Server-seitigen Cookie-Behandlung vertraut werden kann.

Ich würde gerne Antworten sowohl auf das DWR-Framework und AJAX im Allgemeinen begrüßen.

+0

Ich fragte mich, wie ich Probleme hatte, ein Cookie in einer serverseitigen DWR-Anfrage zu löschen. Ich kann sie gut erstellen, aber kann sie nicht löschen - haben seitdem eine Cookie-freie Lösung herausgefunden, nachdem angenommen wird, dass es nicht getan werden konnte. –

Antwort

8

XMLHttpRequest verwendet immer das Verbindungsframework des Webbrowsers. Dies ist eine Voraussetzung, damit AJAX-Programme ordnungsgemäß funktionieren, da der Benutzer abgemeldet wird, wenn das XHR-Objekt keinen Zugriff auf den Cookie-Pool des Browsers hat.

Es ist theoretisch möglich, dass ein Web-Browser Session-Cookies einfach ohne das Verbindungs-Framework des Browsers teilt, aber dies ist meines Wissens nie in der Praxis passiert. Sogar das Flash-Plugin verwendet die Verbindungen des Webbrowsers.

Das Endergebnis ist also, dass es sicher ist, Cookies über AJAX zu manipulieren. Nur Denken Sie daran,, dass der AJAX-Aufruf möglicherweise nie passieren wird. Sie sind keine garantierten Ereignisse, also zähle nicht auf sie.

+0

Danke, trotz der geringen Anzahl unterschiedlicher Meinungen, dies ist am sinnvollsten, wenn ich meine eigenen Testergebnisse, die Abstimmungen und die allgemeinen Best Practices im Zusammenhang mit der Zentralisierung der Geschäftslogik auf der Server-Seite anführe. – Peter

+0

Mein Vergnügen. Ich habe auch einiges in diesem Bereich erforscht, während ich eine Multiplayer-Spiel-API für Flash und Javascript erstellt habe. Dank der 2 Verbindungsbeschränkung durch den HTTP RFC wurde schnell klar, dass ich die Verbindungen des Browsers nutze. Die Cookies haben diese Information bestätigt. – 64BitBob

-1

Die Manipulation von Cookies auf der Client-Seite ist eher das Gegenteil von "Best Practice". Und es sollte auch nicht notwendig sein. HttpOnly Cookies wurden nicht umsonst eingeführt.

+0

Er manipuliert keine Cookies auf dem Client; Er manipuliert sie auf dem Server als Reaktion auf eine Ajax-Anfrage. In jedem Fall wird eine clientseitige Cookie-Manipulation im Allgemeinen nicht als schädlich angesehen, solange sie sich in einem fehlerfreien Zustand befindet, wenn JS deaktiviert oder nicht unterstützt wird. –

1

Im Zusammenhang mit DWR ist es möglicherweise nicht "sicher".

Von the DWR site Lesen heißt es:

Es ist wichtig, dass Sie die HTTP-Anforderung und Antwort als schreibgeschützt zu behandeln. Während HTTP-Header möglicherweise OK erhalten, besteht die Gefahr, dass einige Browser sie ignorieren.

Ich habe damit gemeint, dass das Setzen von Cookies oder das Anfordern von Attributen ein No-No ist.
Sagen, dass ich Code habe, der Anfrageattribute setzt (Code, den ich schrieb, bevor ich diese Seite las) und es scheint gut zu funktionieren (abgesehen von dem Löschen von Cookies, die ich in meinem Kommentar oben erwähnt habe).