Welche Datenbank?

[Julian]

Hallo allesamt,

Ich möchte in meine Webseite eine Tabelle mit dynamisch generierbarem Inhalt unterbringen. Jetzt bin ich am überlegen welcher Datenbanktyp für mich empfehlenswert ist? Ich hab bisher nur von mysql gehört.

by the way: wie würdet ihr den Warenkorb machen, mit Cookies?

mfg Julian

[Daniel]

Hi,

Ich möchte in meine Webseite eine Tabelle mit dynamisch generierbarem
Inhalt unterbringen. Jetzt bin ich am überlegen welcher Datenbanktyp
für mich empfehlenswert ist? Ich hab bisher nur von mysql gehört.

kannst je nach belieben auch "nomrmale" .txt-Datein verwenden. falls du dir keine provider mit MySQL DB leißten kannst bzw. willst.

by the way: wie würdet ihr den Warenkorb machen, mit Cookies?

So wie es hier im Forum leute gibt die strikt gegen das verwenden von
frames sind bin ich strikt gegen das verwenden von cookies.

MfG

[Ludger]

Hi,

So wie es hier im Forum leute gibt die strikt gegen das verwenden von
frames sind bin ich strikt gegen das verwenden von cookies.

Cookies binden den Nutzer unsicher an sein Rechner-Login. Optional scheint mir das aber nutzbar und ggf. nutzpflichtig zu sein.

Bei den Frames stimme ich aber zu.

Gruss,
Ludger

[Julian]

Hallo Ludger,

Bei den Frames stimme ich aber zu.

Was habt ihr alle gegen Frames, hab ich da was verpasst?
ist doch eigentlich eingfacher mit Frames als mit CSS?

mfg Julian

[Cheatah]

Hi,

Was habt ihr alle gegen Frames, hab ich da was verpasst?

offenbar. Das </archiv/> ist voll mit Gründen, die gegen Frames sprechen.

ist doch eigentlich eingfacher mit Frames als mit CSS?

Nein, im Gegenteil. Du ahnst gar nicht, wie viel unnötige Mühe Du Dir damit aufhalst.

Cheatah

[Cheatah]

Hi,

Jetzt bin ich am überlegen welcher Datenbanktyp für mich empfehlenswert ist?

welche Anforderungen hast Du?

Ich hab bisher nur von mysql gehört.

Das ist ähnlich wie PHP: So einfach gemacht, dass es von Anfängern nur noch schwer zu handhaben ist. Es gibt noch viele andere DBMSse, z.B. Oracle, PostgreSQL, Access, MS-SQL und AdoDB.

by the way: wie würdet ihr den Warenkorb machen, mit Cookies?

Ich würde einen Warenkorb definitiv niemals auf etwas Unverlässlichem basieren lassen. Beschäftige Dich mit serverseitigen Session-Mechanismen.

Cheatah

[Frank (no reg)]

Hi Cheatah, Meister des Wissens :-)

betreffs "serverseitigen Session-Mechanismen"

Mir fallen da jetzt die folgenden ein

• mit Cookies
• durch URL Zusätze (Session ID in der URL)
• ??

Irgendwie muss der Benutzer ja gegenüber dem Server ja identifiziert werden, oder?

Url-Zusätze bergen die Gefahr des URL HiJackings, soweit mir bekannt ist.

Gibt es da noch andere Optionen, die "verlässlicher" sind?

Gruß, Frank

[Jörg Peschke]

Moin,

Url-Zusätze bergen die Gefahr des URL HiJackings, soweit mir bekannt ist.

Cookies lassen sich afaik ungefähr genauso einfach "cheaten".

[Frank (no reg)]

Hi,

ja, darauf wollte ich mehr oder minder hinaus. Weder der eine noch der andere der beiden genannten Session-Mechanismen ist wirklich "verlässlicher", da er auch nur auf unverlässlichen bzw. unsicheren anderen Technologien beruht.

Eigentlich irgendwie so ziemlich das Ende von "Warenkorb"-Gedanken?!?

Ciao, Frank

[Christoph Zurnieden]

Hi,

ja, darauf wollte ich mehr oder minder hinaus. Weder der eine noch der andere der beiden genannten Session-Mechanismen ist wirklich "verlässlicher", da er auch nur auf unverlässlichen bzw. unsicheren anderen Technologien beruht.

Eigentlich irgendwie so ziemlich das Ende von "Warenkorb"-Gedanken?!?

Ja, so habe ich bis vor kurzem auch mal gedacht, bis mich dann jemand mal ganz unschuldig fragte: "Und was ist, wenn die Rechnung nicht bezahlt wird?"

Wir versuchen nämlich verzweifelt ein nichttechnisches Problem mit technischen Mitteln zu lösen. Wenn jemand beim Onlinebestellen bescheißen will kann er das auf so viele Methoden, da sind die Problemchen eines Warenkorbes noch die geringsten. Denn auch mal hier ganz unschuldig gefragt: wie haben es denn die Versandhäuser die ganze Zeit gemacht mit ihren Bestellungen?

Das soll natürlich jetzt nicht heißen, das man alle Session-IDs, SSL-Handshakes und was weiß ich noch alles sofort wegschmeißt, um Gotteswillen! aber graue Haare darüber zu bekommen lohnt einfach nicht.

so short

Christoph Zurnieden

[Frank (no reg)]

Hi Christoph,

ich glaube aber, dass es dem OP eher um die technische Realisierung ging und dass es trotz des Hinweises auf Session-Mechanismen keine wirklich "verlässliche" Technologie gibt um eine Warenkorb-Technik pauschal zu gewährleisten. Auch wenn Cheatah diesen Hinweis gegeben hat. Es gab ja bis dato keine Antwort auf meine Frage nach anderen adäquaten, "verlässlicheren" Technologien.

Wen meinst du mit "Wir versuchen..." ?

Gut Nacht, Frank

[Christoph Zurnieden]

Hi

Es gab ja bis dato keine Antwort auf meine Frage nach anderen adäquaten, "verlässlicheren" Technologien.

Das ist kein Wunder, denn es gibt ja keine.

Es ist ja nicht möglich einen Knoten im Netz von außen sicher zu identifizieren. Wenn man nicht gerade dem Kabel nachgeht oder TCPA in aller Rechner Innereien installiert ist.
Somit kann der Ausfüller des Bestellzettels -- und nichts anderes ist so ein Warenkorb ja -- nicht sicher festgestellt werden. Das können die Versandhäuser aber auch nicht.

Die Sicherung des Inhaltes des Warenkorbes ist also nicht signifikant für die Sicherheit des Systems (wenn der Kunde am Ende nicht das auf dem Bestellzettels stehen hat, was er angekreuzt hat, schickt er ihn einfach gar nicht erst ab) Sie ist es jedoch für die Bequemlichkeit des Kunden also direkt für den Unternehmensgewinn. Session-IDs (das Prinzip, keine spezielle Implementation) sind da eine gut bekannte Methode den Inhalt des Bestellzettels nicht während des Rumstöberns im Katalog einfach verloren gehen zu lassen.

Da es nun, wie oben erklärt, 100% Zuverlässigkeit nicht gibt, muß ein "ausreichend sicher" reichen.
"Ausreichend sicher" setzt sich dabei aus mehreren Faktoren zusammen, unter anderem auch, wie gut die Methode bekannt ist, ob es mindestens eine gut gereifte Implementation gibt, wie groß die Komplexität ist, Verfügbarkeit der Technik, wie groß der Schaden im Fehlerfall ist usw.

Die Methode Session-IDs+SSL ist sehr gut bekannt, es gibt mehr als eine gut gereifte Implementation, die Komplexität ist mittel, die Vefügbarkeit der Technik ist gegeben und der Schaden im Fehlerfall ist im schlimmstem Fall ein verlorener Kunde.
Da die Implementationen sehr ausgereift sind, dürfte ein Softwarefehler sehr selten sein, bleibt der aktive Angreifer. Wegen SSL kann er sich nicht so einfach dazwischenklemmen. Er kann also in den Kundenrechner eindringen (Trojaner) oder wirr Bestellungen aufgeben ((D)DoS)[0]. Auf den Kundenrechner hast Du schonmal gar keinen Einfluß und für's (D)DoS gibt es auch die eine oder andere Hilfe, wenn auch keine wirkliche Abhilfe.

Es ist also "ausreichend sicher", jeder Versuch etwas neues zu erfinden wäre automatisch erstmal unsicherer.

Ob's jedoch etwas altes gibt, das lediglich übersehen wurde jedoch besser ist weiß ich nicht. Es ist aber recht unwahrscheinlich.

Wen meinst du mit "Wir versuchen..." ?

Niemanden genau, das war ein rein rhetorischer Griff.

so short

Christoph Zurnieden

[0] es gibt auch noch andere Möglichkeiten, aber die sind dann wirklich _sehr_ exotisch

[Ludger]

Hi,

Eigentlich irgendwie so ziemlich das Ende von "Warenkorb"-Gedanken?!?

und was ist mit HTTP POST?

Gruss,
Ludger

[Frank (no reg)]

Gegrüßt haben wir uns heute ja schon ;-)

Du meinst REST?  Oder verstehe ich dich falsch? Ein Produkt wandert ja meistens (wenn nicht grad per Cookies gelöst) als Ergebnis einer HTTP POST-Aktion in einen Warenkorb. Nur welchen Bezug hat der Benutzer noch zu dieser Resource (Warenkorb) nach dem HTTP POST?

Ciao, Frank

[Ludger]

Hi,

wenn sich der Sitzungsverweis auf einer SSL-Verbindung im POST-Objekt des gleichnameigen HTTP-Requests befindet, dann hat man doch gewonnen, oder? Zumindest mache ich es so tendenziell.   :-)

Gruss,
Ludger

[Frank (no reg)]

ja (wenn ich dich richtig verstanden habe), läuft darauf hinaus, dass es dann "ausreichend sicher und zuverlässig" ist. Ob man damit dann "gewonnen" hat, hmm... :-)

... also doch REST ;-)

Ciao, Frank

[Daniel Thoma]

Hallo Frank,

Url-Zusätze bergen die Gefahr des URL HiJackings, soweit mir bekannt ist.

Bei Cookies ist das natürlich genau so möglich.
Die Gefahr, dass irgend jemand eine URL mit einer Session-ID jemand anderem gibt, ist natürlich bei Cookies nicht gegeben.
Das Hauptargument für Cookies ist meiner Meinung nach aber, dass man nicht jeden Link in den Seiten umbauen muss. Außerdem muss nicht jede Seite, bei der die Session-ID nicht verloren gehen soll, dynamisch sein.

Das einzige Argument für URL-Gewurschtel ist, dass es Leute gibt, die aus unerfindlichen Gründen etwas gegen Session-Cookies haben.
Bei einem Verkaufssystem ist das natürlich in der Regel ein Todschlagargument.

Grüße

Daniel

[Ludger]

Hi,

Das einzige Argument für URL-Gewurschtel ist, dass es Leute gibt, die aus unerfindlichen Gründen etwas gegen Session-Cookies haben.

nur, damit ich mal was dazulerne, Cookies sind gut und SessionID-Roundtripping per POST nicht so gut?

Gruss,
Ludger

[Cheatah]

Hi,

nur, damit ich mal was dazulerne, Cookies sind gut

wenn sie optional sind: Ja, genau wie auch z.B. JavaScript. Ist die Funktionalität von ihnen abhängig, sind sie gequirlte Scheiße. Wie alles, was man abschalten kann.

und SessionID-Roundtripping per POST nicht so gut?

Wo genau kommt hier POST ins Spiel?

Cheatah

[Daniel Thoma]

Hallo Ludger,

nur, damit ich mal was dazulerne, Cookies sind gut und SessionID-Roundtripping per POST nicht so gut?

Sessions mit Cookies zu implementieren ist einfacher als mit GET-Parametern und hat Vorteile - wenn es denn funktioniert. Es ist eben ein Mechanismus, der genau für solche Dinge geschaffen wurde.
Der entscheidende Punkt ist, wie kritisch es ist, dass man das abschalten kann. Ich sehe da kein absolutes Hindernis. Wenn man davon ausgehen kann, dass der Anwender Cookies einschaltet (weil er die Anwendung z.B. verwenden muss) oder man auf die Leute verzichten kann, die das aus Überzeugungsgründen abschalten, warum sollte man sich dann den Stress mit GET-Parametern geben.

Zu der Sache mit POST:
Das eignet sich sicher, um eine Session-ID beim Absenden eines Formulars mitzugeben, aber ansonsten ist das doch nur noch schlimmer. Willst Du da jeden Link durch ein Javascript/Form-Gerwurschtel ersetzen?

Grüße

Daniel

[Ludger]

Hi,

Zu der Sache mit POST:
Das eignet sich sicher, um eine Session-ID beim Absenden eines Formulars mitzugeben, aber ansonsten ist das doch nur noch schlimmer. Willst Du da jeden Link durch ein Javascript/Form-Gerwurschtel ersetzen?

ja.

Gruss,
Ludger

[Daniel Thoma]

Hallo Ludger,

ja.

Und was sollen die Vorteile davon sein?

Grüße

Daniel

[Ludger]

Hi,

ja.
Und was sollen die Vorteile davon sein?

wg. der Daten, wg. des HTTP-Requests, wg. allem so zu sagen.

Gruss,
Ludger

[Manuel B.]

Hi,

wg. der Daten, wg. des HTTP-Requests, wg. allem so zu sagen.

Und schon kann wieder blos derjenige einkaufen, der auch JS aktiviert hat. Ob ads in einem Shop eine Lösung ist, bezweifel ich jetzt mal

[Ludger]

Hi,

wg. der Daten, wg. des HTTP-Requests, wg. allem so zu sagen.

Und schon kann wieder blos derjenige einkaufen, der auch JS aktiviert hat. Ob ads in einem Shop eine Lösung ist, bezweifel ich jetzt mal

was hat denn der gute alte POST-Rrequest mit JavaScript zu tun?

Gruss,
Ludger

[Manuel B.]

Hi

was hat denn der gute alte POST-Rrequest mit JavaScript zu tun?

ich zitiere mal aus einem vorherigen Posting:

Das eignet sich sicher, um eine Session-ID beim Absenden eines Formulars mitzugeben, aber ansonsten ist das doch nur noch schlimmer. Willst Du da jeden Link durch ein Javascript/Form-Gerwurschtel ersetzen?

ja.

Gruss,
Ludger

Wenn du ne andere Lösung hast, ausser nen Link per Javascript als Post abzusetzen, lass mich bitte nicht dumm sterben. Ich hab das bisher immer nur per form.submit() geschafft und nutze deshalb ein GET

[Ludger]

Hi,

Wenn du ne andere Lösung hast, ausser nen Link per Javascript als Post abzusetzen, lass mich bitte nicht dumm sterben. Ich hab das bisher immer nur per form.submit() geschafft und nutze deshalb ein GET

ich weiss jetzt nicht, was Du willst. Man kann doch auch einen HTTP POST erstellen ohne JavaScript.

Gruss,
Ludger

[Manuel B.]

Hi,

ich weiss jetzt nicht, was Du willst. Man kann doch auch einen HTTP POST erstellen ohne JavaScript.

<a href="index.php?session=123456789&pid=99">Link</a>

Mach das ohne JavaScript zu einem POST.

Und ja, du kannst für jeden Link ein eigenes Formular definieren. Dann brauchst du kein JavaScript. Aber ich will das nicht und ich glaube auch, die meisten anderen wollen das auch nicht.

[Ludger]

Hi,

Und ja, du kannst für jeden Link ein eigenes Formular definieren. Dann brauchst du kein JavaScript. Aber ich will das nicht und ich glaube auch, die meisten anderen wollen das auch nicht.

ich habe mich auch schon gefragt warum der HTTP GET so hoch gehalten wird, ich habe es nie verstanden, ja ja die RFCs habe ich mir vor ein paar Jahren reingetan.   :-(

Gruss,
Ludger

[Johannes Zeller]

Ludger,

ich habe mich auch schon gefragt warum der HTTP GET so hoch gehalten wird, ich habe es nie verstanden, ja ja die RFCs habe ich mir vor ein paar Jahren reingetan.   :-(

Vielleicht, weil es ohne Javascript-Tricks möglich ist Daten mit einem _Link_ zu übergeben?

Johannes

[Manuel B.]

Hi,

ich habe mich auch schon gefragt warum der HTTP GET so hoch gehalten wird, ich habe es nie verstanden, ja ja die RFCs habe ich mir vor ein paar Jahren reingetan.   :-(

Könnte es vielleicht auch daran liegen, das Google mittlerweile bis zu drei Variblen verarbeiten kann, aber imme noch keinem Submit folgt?
Würde mich interessieren, wie du dem Kunden klar machst, das seine Seite zwar ohne GEt auskommt, aber dafür von SuMas nicht gespidert werden kann.

[Ludger]

Hi,

Ich würde einen Warenkorb definitiv niemals auf etwas Unverlässlichem basieren lassen. Beschäftige Dich mit serverseitigen Session-Mechanismen.

wenn Du ehrlich bist, hast Du schon viele Nicht-JSNutzer ausgeschlossen, oder?

Gruss,
Ludger

[Cheatah]

Hi,

wenn Du ehrlich bist, hast Du schon viele Nicht-JSNutzer ausgeschlossen, oder?

das wäre mir jetzt ehrlich gesagt nicht bewusst. Wenn Du auf etwas Bestimmtes meiner alten Homepage anspielst, möchte ich noch einmal darauf hinweisen, dass sie deshalb seit anno 1999 nicht verändert wurde, weil ich sie damals als irreparabel beschädigt aufgegeben habe.

Cheatah

[Ludger]

Hi,

das wäre mir jetzt ehrlich gesagt nicht bewusst. Wenn Du auf etwas Bestimmtes meiner alten Homepage anspielst, möchte ich noch einmal darauf hinweisen, dass sie deshalb seit anno 1999 nicht verändert wurde, weil ich sie damals als irreparabel beschädigt aufgegeben habe.

so wars nicht gemeint. Ich vermute doch, das die "Seiten", die Du produzierst - soz. anforderungsgemaess - ggf. nicht ohne JS auskommen, oder? Kann doch sein, oder?

Gruss,
Ludger

[Cheatah]

Hi,

so wars nicht gemeint. Ich vermute doch, das die "Seiten", die Du produzierst - soz. anforderungsgemaess - ggf. nicht ohne JS auskommen, oder? Kann doch sein, oder?

ach so. Nein, ich habe selbst bei anderen Vorgaben immer drauf geachtet, dass die Nutzbarkeit ohne JavaScript u.ä. gegeben ist. Lediglich im Intranet-Bereich habe ich gelegentlich entsprechende Vorgaben gemacht; da habe ich dann aber auch den zu verwendenden Browser befohlen :-)

Cheatah

[Ludger]

Hi,

ach so. Nein, ich habe selbst bei anderen Vorgaben immer drauf geachtet, dass die Nutzbarkeit ohne JavaScript u.ä. gegeben ist. Lediglich im Intranet-Bereich habe ich gelegentlich entsprechende Vorgaben gemacht; da habe ich dann aber auch den zu verwendenden Browser befohlen :-)

und sind u.a. solche Befehle auch wirtschaftlich OK?

Gruss,
Ludger

[Cheatah]

Hi,

und sind u.a. solche Befehle auch wirtschaftlich OK?

ja. Erstens habe ich mir damit sehr (_sehr_) viel Aufwand gespart, und zweitens haben mich die Betroffenen eh mit einer "Wie, gibt's noch was anderes?"-Miene angesehen ;-)

Cheatah

[Ludger]

Hi,

und sind u.a. solche Befehle auch wirtschaftlich OK?

ja. Erstens habe ich mir damit sehr (_sehr_) viel Aufwand gespart, und zweitens haben mich die Betroffenen eh mit einer "Wie, gibt's noch was anderes?"-Miene angesehen ;-)

reingefallen, war ne Fangfrage, ja, Du hast recht, aber wirtschaftliche Ueberlegungen koennen doch auch im Web Einschraenkungen begruenden, oder?

Gruss,
Ludger

[Cheatah]

Hi,

reingefallen, war ne Fangfrage,

fein. </ignore> ;-)

ja, Du hast recht, aber wirtschaftliche Ueberlegungen koennen doch auch im Web Einschraenkungen begruenden, oder?

Sicher, nur werden wohl die wenigsten den IE ausschließen wollen. Und der umgekehrte Weg ist keine wirtschaftliche Überlegung, sondern bloß Inkompetenz. Davon abgesehen: Im Internet kennt *niemand* 100% aller User, wie es in einem Intranet der Fall sein kann. Die beiden Welten sind unvergleichbar.

Cheatah

[Ludger]

Hi,

Sicher, nur werden wohl die wenigsten den IE ausschließen wollen. Und der umgekehrte Weg ist keine wirtschaftliche Überlegung, sondern bloß Inkompetenz.

ich habe festgestellt, dass man mit "Inkompetenz" eine ganze Menge Geld verdienen kann. Und wir beide sollten dabei sein!

Gruss,
Ludger

[Cheatah]

Hi,

ich habe festgestellt, dass man mit "Inkompetenz" eine ganze Menge Geld verdienen kann. Und wir beide sollten dabei sein!

sorry, ich reihe mich nicht gerne in klägliches Versagen ein. Du hast übrigens nicht festgestellt, wie viel Geld Du durch Inkompetenz _nicht_ verdient hast. Und wirst es nie feststellen.

Cheatah

[Ludger]

Hi,

sorry, ich reihe mich nicht gerne in klägliches Versagen ein. Du hast übrigens nicht festgestellt, wie viel Geld Du durch Inkompetenz _nicht_ verdient hast. Und wirst es nie feststellen.

kennst Du nicht die Consulting-Profis, die nach vielen Jahren Beratung feststellen, dass alles umsonst war, dass sie nicht zum Consulting taugen, weil andere - Duemmere - offenkundig besser sind, wegen zugegebenermassen zweifelhafter sozialer Kompetenz und sò?

Bist Du wirklich der Meinung, dass die bessere Mittelmaessigkeit im Management _nicht_ langfristig gewinnt?

Gruss,
Ludger

[Frank (no reg)]

Hi,

du wirst in der großen weiten Providerlandschaft nicht sehr oft andere DBMS antreffen als mySQL.

Die Frage, die sich dir stellen sollte: Erfüllt mySQL deine Anforderungen? Wenn ja, warum dann weiter um die Ecke denken?

by the way: wie würdet ihr den Warenkorb machen, mit Cookies?

Serverseitig ohne Cookies

Ciao, Frank