Bogus
C64 Generation
|
hi wieder heute hab ich es - nach vielen vorsätzen - endlich geschafft mich mit ajax auseinander zu setzen. ausserdem hab ich es gleich in ein aktuelles projekt eingebaut. das ist genau das was ich schon lange gebraucht hätte. wäre weit weniger arbeit gewesen als ständig irgendwelche variablen mit zu schleifen. zum punkt: ich möchte einen shop teilweise auf ajax umbauen. konkret erstmal die funktion zum 'in den warenkorb' legen. das spart zeit, traffic und nerven. funktioniert in der demo auch schon aber alle user ohne javascript bzw. mit deaktiviertem javascript können dann nicht mehr im shop bestellen. wie macht ihr das im allgemeinen? zweigleisig fahren? diverse user/kunden einfach ausschließen? wenn ich auf die hrefs/forms und variablen nicht verzichten kann, dann seh ich darin nur mehr aufwand..... thnx for feedback
|
Obermotz
Fünfzylindernazi
|
Wenn dich der Mehraufwand abschreckt, dann schließe die betroffenen User (es sind mittlerweile wirklich wenige) aus, gib aber eine explizite Meldung aus, dass für ordnungsgemäße Funktion JS aktiviert sein muss.
|
Neo1010
.
|
hab in den letzten jahren diverse projekte mit ajax (jquery/ext) gemacht, und bin zu folgendem schluss gekommen.
verlangt der kunde unbedingt das es ohne js funktioniert, verwende ich ajax nur für kleine hilfe widgets aber nicht für seiten relevante inhalte.
ist es dem kunden egal, versuch ich ihm die vorteile von js klar zu machen (auch die nachteile...), und dann wird die seite meist so entwickelt das ohne js gar nichts geht und mit js ein viel besseres arbeiten möglich ist.
[x] Nicht auf Ajax verzichten, da die meisten js sowieso aktiviert haben. Ajax bringt einfach viele vorteile und ich möchte darauf nicht mehr verzichten
Bearbeitet von Neo1010 am 18.12.2009, 20:21
|
Obermotz
Fünfzylindernazi
|
btw; wäre es nicht eine neuerfindung des rades wenn du ein shopsystem von null aufbaust? da gibts doch x-tausend opensourceprojekte auf denen man aufbauen kann.
|
mat
AdministratorLegends never die
|
Ajax ist dann nötig, wenn durch das ständige Reloaden der Webseite die Arbeit unerträglich wird. Zu 95% ist sowas nur in einem Backend der Fall, bzw. in irgendwelchen speziellen Intranet-Webapplikationen. Wenn du es unbedingt fürs Frontend machen willst, dann sollte es auch gscheid sein ... sonst ist der (vielleicht eh unnötige ) Komfort sogar kontraproduktiv. Also würde ich mindestens einen Blocker für Nicht-JS-Gäste (zB einige mobile Surfer) machen bzw. zweigleisig fahren.
|
that
ModeratorHoffnungsloser Optimist
|
Wenn der Shopbetreiber es sich leisten kann, auf Kunden zu verzichten, dann kannst du ruhig alles Mögliche voraussetzen. Manche Shops setzen z.B. sogar Windows voraus, die verzichten dann halt auf Mac- oder Linux-Kunden.
|
Bogus
C64 Generation
|
@obermotz: jöses.....auf opensource aufbauen? nen shop für nen kommerz-kunden? imho ist das ein no go. hab keine lust rund um die uhr verfügbar zu sein um kurzfristig ein sicherheitsupdate einzuspielen weil wieder irgendwo ein loch in der opensource-lösung gefunden wurde.
@mat: im shop bringt's was beim 'in den warenkorb' legen. bisher hab ich immer alle möglichen variablen mitschleifen müssen, und der seiten-reload ist in nem shop auch extra-nervig imho.
btw: habe bereits einen <noscript> header eingebaut, der user auf den umstand hinweist.
|
wutzdutz
owned by 50''
|
@obermotz: jöses.....auf opensource aufbauen? nen shop für nen kommerz-kunden? imho ist das ein no go. hab keine lust rund um die uhr verfügbar zu sein um kurzfristig ein sicherheitsupdate einzuspielen weil wieder irgendwo ein loch in der opensource-lösung gefunden wurde. du hattest schon im mysql thread interessante sichtweisen... an sonsten wie bereits erwähnt, wenns vorteile für den benutzer (und nicht primär für den entwickler), dann setz ajax gezielt ein. ein nur so vor ajax effekten strotzender shop kann imho auch nicht überzeugen.
|
Bogus
C64 Generation
|
@wutzdutz: ganz deiner meinung
|
mat
AdministratorLegends never die
|
@obermotz: jöses.....auf opensource aufbauen? nen shop für nen kommerz-kunden? imho ist das ein no go. hab keine lust rund um die uhr verfügbar zu sein um kurzfristig ein sicherheitsupdate einzuspielen weil wieder irgendwo ein loch in der opensource-lösung gefunden wurde. Ich hoffe du weißt, dass das BS ist. Der einzige negative Fall, der mir einfällt ist/war die Forensoftware phpBB. Da wurde einiges an Schindluder betrieben. Aber man muss eben sorgfältig auswählen zu welcher Open Source-Software man greift. Ich rate dir zu jquery ... smart, gut maintained und mehr als praktisch. @mat: im shop bringt's was beim 'in den warenkorb' legen. bisher hab ich immer alle möglichen variablen mitschleifen müssen, und der seiten-reload ist in nem shop auch extra-nervig imho. Das Zauberwort heißt Session. Ein Array (oder noch besser eine Klasse) und der Warenkorb ist gespeichert. Willst du AJAX nutzen um die Komplexität deiner aktuellen Software zu verringern?
|
jives
And the science gets done
|
@obermotz: jöses.....auf opensource aufbauen? nen shop für nen kommerz-kunden? imho ist das ein no go. hab keine lust rund um die uhr verfügbar zu sein um kurzfristig ein sicherheitsupdate einzuspielen weil wieder irgendwo ein loch in der opensource-lösung gefunden wurde. Sorry wegen OT, aber glaubst du wirklich, dass eine kommerzielle Software die unter Zeit- und Profitdruck entwickelt wurde, besser getestet und sicherer ist, als eine OS-Variante? Oder dass man als einzelner Programmierer bei einem Eigenbau-Projekt alle möglichen Sicherheitslücken bedenken, austesten und schließen könnte? BTT: Gerade bei einem Shop würde ich so wenig wie möglich voraussetzen, vor allem da bei dieser relativ einfachen Anwendung wohl alle Funktionen auch ohne JS/AJAX umzusetzen sind und mit ein bisserl Aufwand bei der Konzeption auch so verpackt werden können, dass gleich automatisch ein sauberes Fallback entsteht. Ich persönlich würde nicht lieber in einem Shop einkaufen, nur weil dort ein AJAX-Warenkorb vorhanden ist. Welche (wirklichen) Vorteile bringt das denn auch? Dafür werden halt Kunden ausgesperrt - ob das ein gutes Tradeoff ist? Bei komplexen Anwendungen, die nur für einen relativ kleinen Kundenkreis oder gar fürs firmeneigene Intranet geschrieben werden, sehe ich aber an AJAX-only kein Problem.
Bearbeitet von jives am 20.12.2009, 16:47
|
semteX
begehrt die rostschaufel
|
zum thema "open source gelumpe": zum thema "ajax aussperrn": imho eine absolute bad practice. ajax muss klare vorteile bringen und ned "dem entwickler irgendwie schwindlich das arbeitn erleichtern". eine website, die ohne ajax UNBEDIENBAR ist, ist in meinen augen defekt. wenn ich dann hier was les von "variablen mitschleifen", dann ist die frage ob ma ned "handwerklich" was verbessern könnte e: Und bitte ned glauben, dass nen web security experten "nicht vorhandener source" abschreckt. der macht dir die seite innerhalb von minuten gaaaaaanz weit auf... alles schon gesehen
Bearbeitet von semteX am 19.12.2009, 17:56
|
ica
hmm
|
@obermotz: jöses.....auf opensource aufbauen? nen shop für nen kommerz-kunden? imho ist das ein no go. hab keine lust rund um die uhr verfügbar zu sein um kurzfristig ein sicherheitsupdate einzuspielen weil wieder irgendwo ein loch in der opensource-lösung gefunden wurde. wenn ich deine posts so lese kann ich wohl davon ausgehen, dass so ziemlich jeder opensource shop dens da draußen gibt, sicherer ist als deine lösung.
|
watchout
Legendundead
|
wenn ich deine posts so lese kann ich wohl davon ausgehen, dass so ziemlich jeder opensource shop dens da draußen gibt, sicherer ist als deine lösung. Würde ich nicht so schlicht sagen, das ganze hat sogar einen Namen und nennt sich "Security through obscurity" (Security-VU hats ja doch gebracht ). Microsoft setzt genau darauf (Oder hat eben das gemacht) und viele andere auch. Da man da nicht mehr so einfach nach zB. nicht initialisierten Variablen im Code suchen kann dauert es länger und ist vor Allem mehr Aufwand für den Angreifer. Dafür wenn mal einer was findet sieht's böse aus. Mit Sicherheitslücken wird gehandelt und Geld verdient, die wären schon sehr blöd diese an den Entwickler zu melden. Der Erfährt es dann von Kunden die Opfer davon wurden. Außer er kauft sich die Sicherheitslücke selbst Mit einer aktiven Community erfährt der OSS Entwickler aber eigentlich rechtzeitig von solchen Sicherheitslücken, oft genug vor einem Release.
|
kleinerChemiker
Here to stay
|
So lange der Shop nicht besonders groß oder reich wird, ist es sehr unwahrscheinlich, daß er Ziel solcher gezielter Angriffe wird. Handelt es sich jedoch um eine weit verbreitete Software (egal ob open source oder kommerziell) und eine publik gewordene Sicherheitslücke nicht rechtzeitig geschlossen (und die User spielen die Updates auch ein), ist die Wahrscheinlichkeit daß Bots oder Skriptkiddies die Lücke ausnutzen ungleich größer. Insoferne ist es schon eine gewisse Sicherheit. Kommt mir aber so vor, wie wenn jemand sagt, er nimmt keinen Sicherheitsgurt, weil es sicherer ist nur auf kaum befahreren (Feld-)Wegen zu fahren und bei dem Gerumpel ist es bequemer ohne Gurt Bin aber generell der Meinung, JS (und damit auch AJAX) soll eine Seite besser machen, fehlende JS-Unterstützung beim Client darf die Seite jedoch nicht unbenutzbar machen.
|