Laden...

Client als Cache?

Erstellt von Omit vor 13 Jahren Letzter Beitrag vor 13 Jahren 4.519 Views
Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren
Client als Cache?

Hallo Leute,

wollt mal Nachfragen warum man den Client nicht als Cache verwenden sollte. Man könnte doch einen Hash abgleich machen. Das ein Hacker da einen Inhalt findet der Sinn ergibt und den selben Hashwert sollte doch gegen null gehen.
Mir kommt da zur Zeit kein Grund außer vielleicht Performance. Kann mir da wer auf die Sprünge helfen.

Danke und Gruß Timo

C
2.121 Beiträge seit 2010
vor 13 Jahren

Jetzt bitte nochmal so dass mans versteht

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

OK ich probiers nochmal:

Warum sendet man nicht die UserDaten(SessionDaten) an den Client als JSON Objekt zum Beispiel? Da man dem Client aber nicht trauen kann, bildet man über die Seesiondaten einen Hash, den man auf der Server Seite lässt. Beim Zurücksenden der Sessiondaten checkt man einfach den Hash und hat die Sessiondaten auf dem richtigen Server. Man muss halt nur den Hash austauschen. Könnte man Cach-Speicher sparen. Denk das es sich aber rein aus Performance Gründen nicht lohnt. Aber würde mich interessieren ob da aus Sicherheitsgründen was dagegen spricht.

Danke und Gruß Timo

1.457 Beiträge seit 2004
vor 13 Jahren

Was genau möchtest du damit bezwecken?

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

Serverkosten einsparen. Ram einsparen, Netzwerkauslastung reduzieren. Aber ist nur hypothetisch. Nur eine lern Überlegung.

Gruß und Danke Timo

Gelöschter Account
vor 13 Jahren

Sowas macht man bereits mit HiddenFields und natürlich dem ViewState. Generell gilt, das in die Session nur das notwendigste und sicherheitsrelevante rein soll.

Immer wieder mal sieht man, das da z.b. Daten reingeschoben werden (sogar größere Datenmengen)... die man ohnehin aus der Datenbank bezieht... das ist natürlich mist. Das bläht den Sessionspeicher nur auf (es sei denn man nimmt den Datenbankbasierten ^^ )

Ein Gridview ist z.b. nicht in der Session notwendig.

Deine idee mit dem Hash ist zwar interessant aber nicht sicher. Jeder hacker kann ans ende dessen, was er manipuliert hat noch ein paar sinnlose bytes hängen, damit der Hash wieder stimmt....

Zudem erhöhst du mit deiner Methode die Netzwerklast, welche gerade bei Webgeschichten eine wesentliche Rolle spielt.

1.457 Beiträge seit 2004
vor 13 Jahren

Serverkosten einsparen. Ram einsparen...

Das solltest du nicht bedenken, sondern eher deine Webanwendung sauber und optimiert programmieren. Alles andere ergibt sich dann von selber. Schau dir die Thematik mit ViewState an. Diesen kannst du auch nur für bestimmte Controls einschalten, falls du es unbedingt benötigst.

Netzwerkauslastung reduzieren

Stichwort: Caching, sauberes Markup, Caching, Caching und GZIP Komprimierung.

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

Danke für eure Antworten.

Bezüglich Hash, wenn man auf dem Server jedoch die Syntax überprüft, dürfte es doch nicht gerade einfach sein einen semantisch sinnvollen Inhalt zu erstellen. Dann noch einen Teil des Inhalts auf dem Server lässt(sowas wie ein Salt). Klar kann der den Salt dann noch erraten aber wie wahrscheinlich ist das und mal die Wahrscheinlichkeit das er Syntaktisch und Semantisch Sinnvollen Inhalt mit dem selben Hash hinbekommt.
Müsste dann ja Richtung Public und Secret Key gehen.

Kennt ihr vielleicht ein Buch das gut ist, wo solche Probleme beschrieben sind? Abstrakt und am besten noch mit Anwendungsbeispiel.

Gruß und Danke Timo

3.170 Beiträge seit 2006
vor 13 Jahren

Hallo,

Warum sendet man nicht die UserDaten(SessionDaten) an den Client als JSON Objekt zum Beispiel?

  1. Zunächst mal braüchtest Du dafür auf dem Client etwas persistentes, wo das Objekt über mehrere Seiten gespeichert werden kann. Dafür bedarf es dann eines eigenen Frames, der immer existieren müsste.
  2. sparen kannst Du dabei sicher nix, denn entweder müssen Änderungen der Daten vom Client a den Server oder umgekehrt mitgeteilt werden.
  3. Was soll der Client mit den Sitzungsdaten denn anfangen? Die Eigenheit von Sitzungsdaten ist es ja, daß sie auf dem Server verarbeitet werden...
  4. Das mit dem Hashwert ist ja auch Unsinn. Dann dürfte der Client ja keine Änderung an den Daten vornehmen, weil der Server sonst verweigert. Dann ist es erst recht Unsinn, die Daten dort zu halten, wo sie nicht geändert werden dürfen.
    (die Liste ließe sich noch fortsetzen, aber sollte erstmal reichen)

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

Gelöschter Account
vor 13 Jahren

Kennt ihr vielleicht ein Buch das gut ist, wo solche Probleme beschrieben sind?

Nein, weil es unsinnig ist. Bislang betrachtest du immer nur das eine Problem mit dem Hashcode... die anderen erwähnten Probleme, hast du bislang gekonnt ignoriert.

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

Nein ich glaub euch das es Unsinn ist und verstehe eure Argumente. Ich will es nicht (mehr) als SessionCache verwenden.

Meine danach Angestellten Überlegungen sind theoretischer Natur.
Kann man jemanden was aushändigen zur Speicherung und nur einen kleinen Teil selbst speichern zur Überprüfung. Und in den Inhalt dann vertrauen.

Es kann sein das es dafür zur Zeit keine Anwendung gibt. Aber Spielregeln ändern sich ja auch mal oder man kommt in andere Gebiete wo es andere Spielregeln gibt.
Man könnte das Problem mit dem von Seti@home-Problem vergleichen. Die auch in ihre Nutzer vertrauen müssen. Die machen das darüber das sie jede Berechnung 3mal ausführen lassen und die Ergebnisse vergleichen. Vielleicht programmiert man eine Peer-To-Peer Festplatte oder so.

Mir ist bewusst das ich Lost im Gedankenspace bin. Aber manchmal kommen aus so Überlegungen Ideen.
Hab nur zur Zeit etwas Freizeit, deswegen lass ich meine Gedanken kreisen.

Wenn das nicht der richtige Ort für so Gedankenspiele ist, dann verstehe ich das und entschuldige mich fürs abtrifften.

Danke und Gruß Timo

Gelöschter Account
vor 13 Jahren

Es ist ok, das du sowas fragst und es ist super, das du dinge hinterfragst. Allerdings musst du immer auch alle Argumente betrachten und dich auf keinen Fall auf nur eines versteifen.

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

Ich bin dankbar für die Argumente. Ich denk auch über diese nach, nur sind die teilweise schon konkret gewesen, wo ich mit meinen Gedanken noch Spielchen gemacht habe. Doch hilft mir das weiter auf meinem allgemeinen Weg ein guter Softwareentwickler zu werden. Dadurch verstehe ich unter anderem, was für solche wichtig ist.
Fest zu halten bleibt: Ich sollte in Zukunft mehr drauf eingehen, wodrauf ich hinaus will. Auch war es nicht richtig, diese Argumente nicht in meinen weiteren Posts zu behandeln. Sorry.

Im Prinzip will ich ja nur die Server (IPs) , der relevanten Cache Server, im Browser speichern (War mir im ersten moment der Idee eigentlich nicht so klar). Davon verspreche ich mir den Round Trip zum Master-Cache-Server zu sparen. Dazu muss ich eigentlich noch nicht mal sicherstellen das die Daten stimmen, ist mir dann eingefallen. Da ich bei einem Miss einfach den Master-Server frag. Kommt ja eh fast nie vor, das wer diese Daten ändern wird.

Das andere was sich aus der Idee ergeben hat war der Gedanke ob es möglich ist einem Fremdanbieter Daten anzuvertrauen und im nachhinein feststellen kann ob er sie geändert hat. Da habe ich an eine Signatur(Hash) gedacht.

Ich arbeite zur Zeit an keiner Anwendung die so skalieren muss. Aber daran seht ihr schon wie theoretisch das bei mir ist.

Ein Buchvorschlag wollte ich zu Cryptographie, aber nicht zu den theoretischen Grundlagen, an den Formeln will ich jetzt nicht rumdoktoren. Sondern sollte behandelt werden, was es gibt und wieso es das gibt. Wenn ihr dazu noch was wisst würde mich das freuen.

Vielen Dank für eure Antworten,
Timo

X
1.177 Beiträge seit 2006
vor 13 Jahren

huhu Timo,

naja, deine Fragen sind ihmo nicht so abwegig wie es gerade erscheint. Genau das passiert ja in jedem P2P Program: Daten werden verteilt und jeder vertraut darauf, dass der (später) resultierende Hash die Originaldaten wiederspiegelt. Das Funktioniert bekanntermaßen auch sehr gut und verlässlich.

Was nicht funktioniert, sind Daten, welche (potentiell) nur einem Benutzer zugute komme sollen. Denn diese daten muss man übertragen - womit die Idee der Netzwerklast schon wegfällt - und das immer nur zu "dem einen Client".

Ein Hash ist immer nur bedingt gut. Wenn die Datenmenge sehr klein wird, dann reduziert sich die Menge der möglichen Hashes auf das maximum dieser Datenmenge. Also z.B. Daten sind nur ein Buchstabe ("A-Z") - dann gibts auch nur 26 mögliche Hashes. Bei sehr grossen Datenmengen reduziert sich wiederum die Nachprüfbarkeit. Hash-Algorithmen sind nur möglichst gut mathematisch analysiert - aber es garantiert niemand, dass sie nicht "versehentlich" bei großen Datenmengen eine kollision produzieren. (kleine Mengen lassen sich berechnen, große nicht mehr) Aber: ja, es funktioniert auch bei großen Datenmengen (aktuell)^^

Crythographie ist übrigens bei deinen Überlegungen nochmal ein anderer Punkt. Verschlüsselung kostet immer Serverkapazität (CPU, RAM, Nertzwerklast) - womit ja deine anderen Punkte angesprochen sind. Ok, hier gibt es sehr gute Lösungen dafür (eine extra Crytobox für SSL vor den eigentlichen Servern) aber es ist imho nicht das was du meintest.

Wenn Du dich für das Thema interessierts, kann ich leider kein Buch empfehlen, nur Richtung. schau Dir an, wie https (ssl) funktioniert, Unterschiede zwischen synchroner und asynchroner Verschlüsselung, Unterschiede zwischen (crypto)Hashes; da reicht ja auch schon mal Codierungen auf Netzwerkkabeln als Grundlage anzugucken. Man muss ja immer davon ausgehen, das viel clevere Leute sich da schonwas dabei gedacht haben.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

Omit Themenstarter:in
143 Beiträge seit 2008
vor 13 Jahren

Hallo Xynratron,

danke für deine Antwort. OK das bei P2P Netzwerken, diese Technik eingesetzt wird, war mir bis jetzt noch nicht bewusst.

Jemand will in eine Datei einen Virus einpflanzen. Fraglich ist halt nur ob er, da die Syntax einer ausführbaren Datei doch recht viel zulässt, eine Kollision finden kann. ...am Anfang steht der veränderte Code (Virus) und hintendran einfach ein "Ausgleichsterm". Hast mir ja gute Schlagwörter geliefert.

Danke für diese, das ist immer ein guter Einstiegspunkt. Da das Gebiet nur so Rand Gebiete für mich ist, hatte ich da noch kaum.

Ja es erstaunt mich immer wieder, wieviel die cleveren Leute doch schon alles durchdacht haben. Ich find es aber dann auch immer spannend zu sehen, das man ähnliche Grundgedanken hat, wenn man sich neu damit beschäftigt. Doch alle die Bretter auf allen Weg nochmal zu brechen, wäre Zeitverschwendung.

Gruß Timo