nicht angemeldet Patrick Andrieu
Der Martin
Kai345
Der Martin
Hallo zu später Stunde,
Ich habe über meinen noch nicht eröffneten E-Shop eine Scherzbestellung erhalten. Die Bestellmail sieht so aus:
Anrede: a
Vorname: b
Name: c
GebDatum: dd.mm.jj
StrasseNr: e
Plz: 99999
Ort: g
Land: h
Email: i@jogi.com
Zahlweise: Vorkasse
Vambox: 1
Pos00: 0,0 Euro
Forest: 2
Pos01: 0,0 Euro
Meadow: 3
Pos02: 0,0 Euro
Ocean: 5
Pos03: 0,0 Euro
Fire: 0
Pos04: 0,0 Euro
Fuel: 0
Pos05: 0,0 Euro
Rubber: 0
Pos06: 0,0 Euro
Death: 0
Pos07: 0,0 Euro
Smoke: 5
Pos08: 0,0 Euro
Pool: 0
Pos09: 0,0 Euro
Sweat: 0
Pos10: 0,0 Euro
Femstyle: 0
Pos11: 0,0 Euro
Malestyle: 1
Pos12: 0,0 Euro
C1: on
Die Felder Netto-Preis,MwSt und Brutto-Preis fehlen ganz. Auf eine E-Mail anfrage an die oben eingefüllte Adresse bekomm ich das:
217.26.49.140_does_not_like_recipient./Remote_host_said:_550_no_such_address_here/Giving_up_on_217.26.49.140./
Da mein HTML- Formular alles auf dem Client rechnet, kann man da ja natürlich amJavaScript manipulieren. In der Praxis wird das aber nichts Nützen,da die Bestellungen ja sowieso vor Hand nachgerechnet werden.
Trotzdem hätte es mich interessiert, wer der Scherzkeks ist.
Hab ich ne Möglichkeit das heraus zu finden ?
gruss gary
Hello Gary,
GebDatum: dd.mm.jj
Das ist doch eindeutig *kicher*
Was hasst Du denn sonst noch im Log stehen?
Solche Bestellungen wirst Du bestimmt öfter bekommen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hi Tom,
Ich weiss was ein log ist. Das Zeichnet Vorgänge auf PC und Server auf. Jetzt ist das aber ne gute Frage von Dir - Welches log, wo finde ich es, und was sehe ich dort ?
Ich hab meinen Webspace gemietet. Kann mich aber ziehmlich frei bewegen, was rwx- Rechte betrifftund son kram...
Gruss gary
Hello,
Ich weiss was ein log ist. Das Zeichnet Vorgänge auf PC und Server auf. Jetzt ist das aber ne gute Frage von Dir - Welches log, wo finde ich es, und was sehe ich dort ?
Ich hab meinen Webspace gemietet. Kann mich aber ziehmlich frei bewegen, was rwx- Rechte betrifftund son kram...
Hast Du den Apachen laufen? Wenn ja, welchen?
Kannst Du an die Konfigurationsdateien ran von Apache?
Ich gehe davon aus, dass Du auf einem Linux-System arbeitest.
Ich rate jetzt mal, dass die Virtual-Host definitionen unter
/etc/apache2/sites-available
stehen.
Da schaust Du mal in die Datei, die zu der entsprechenden Domain gehört, wo die Log-Dateien für access-Log und error-log abgelegt sind.
In diesen kannst Du dann nachsehen, wer Dir den Scherz geschickt hat und wann.
Aber eigentlich könnte bei einer Bestellung Dein Script das auch loggen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
hinochmal tom,
Ob der "Indianer" läuft, kann ich dir nich sagen. Ich ab mich als admin eingeloggt und auchdass accsess log gefunden. Habe es dann runterkopiert und in der WordPad MFC Anwendung angesehen. Das Log reicht vom 22.10 bis 23.1o. die Mail kam am 21.10 um 17:06 an. Dass heisst alles was vor dem 22.10 liegt,kann ich nicht sehen.
Gruss gary.
P.S. Mache Morgen weiter, zu müde zum Tastendrücken -
Merci und schlaf gut :-)
Ach so,
Ich habe das Paket von: www.kreativmedia.ch
Vorerst die Light-Version.Vielleicht kann man dort sehen, ob es Apachen oder Irokesen oder Sioux sind,die sich auf dem Server tummeln.
So, jetzt aber schlafi-schlafi, sonst morgen nix aufwachi!
Bye Tom
Hallo Gary,
Ob der "Indianer" läuft, kann ich dir nich sagen. Ich ab mich als admin eingeloggt und auchdass accsess log gefunden. Habe es dann runterkopiert und in der WordPad MFC Anwendung angesehen. Das Log reicht vom 22.10 bis 23.1o. die Mail kam am 21.10 um 17:06 an. Dass heisst alles was vor dem 22.10 liegt,kann ich nicht sehen.
Dann führt dein Provider wahrscheinlich eine Log-Rotation durch, d.h. dass alte Logs archiviert werden, damit das aktuelle Log, nicht in unüberschaubare Größen wächst. Wahrscheinlich gibt es also irgendwo auch ein archiviertes Log für einen längeren Zeitraum, möglicherweise werden die Daten aber auch komplett gelöscht, statt archiviert zu werden.
Ich verstehe auch nicht ganz, was du dir davon versprichst. Selbst wenn du die IP-Adresse hast, wirst du damit sehr wahrscheinlich nicht mehr herausfinden, als dass der Besteller bei T-Online oder einem anderen bekannten Internet-Provider ist.
Schöne Grüße,
Johannes
Hallo gary!
Ob der "Indianer" läuft, kann ich dir nich sagen.
In eine Datei mit der Endung .pl speichern, ins cgi-bin hochladen(ASCII-Modus), Rechte auf 755 setzen:
#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
print "Content-Type: text/html\n\n";
print $ENV{SERVER_SOFTWARE};
Bei mir kommt: Apache/1.3.33 (Unix)
Viele Grüße aus Frankfurt/Main,
Patrick
Mahlzeit,
wir hatten ja schonmal das Vergnügen ... :-)
GebDatum: dd.mm.jj
Fehlende Werteüberprüfung?
Pos00: 0,0 Euro
Pos01: 0,0 Euro
Pos02: 0,0 Euro
Pos03: 0,0 Euro
Pos04: 0,0 Euro
Pos05: 0,0 Euro
Pos06: 0,0 Euro
Pos07: 0,0 Euro
Pos08: 0,0 Euro
Pos09: 0,0 Euro
Pos10: 0,0 Euro
Pos11: 0,0 Euro
Pos12: 0,0 Euro
Falsche Preise? Oder Manipulation auf dem Client?
Die Felder Netto-Preis,MwSt und Brutto-Preis fehlen ganz. Auf eine E-Mail anfrage an die oben eingefüllte Adresse bekomm ich das:
217.26.49.140_does_not_like_recipient./Remote_host_said:_550_no_such_address_here/Giving_up_on_217.26.49.140./
Tja, kein Wunder.
Da mein HTML- Formular alles auf dem Client rechnet,
BÖÖÖÖÖSER FEHLER! Hätte dir mindestens jeder zweite hier vorher sagen können. Merke: ALL INPUT IS EVIL!
Wenn du Angaben wie Adresse, Email, Geburtsdatum usw. nicht auf dem Server auf gültige Angaben überprüfst, dann darfst du dich über solche "Bestellungen" nicht wundern. Und Preise vom Client errechnen zu lassen und dann einfach zu "glauben", ist in höchstem Maße fahrlässig!
kann man da ja natürlich amJavaScript manipulieren. In der Praxis wird das aber nichts Nützen,da die Bestellungen ja sowieso vor Hand nachgerechnet werden.
Hm? Wieso dann den EDV-Aufwand betreiben, wenn eh alles per Hand gemacht wird? Dann lieber ein Bestellsystem mit Hand und Fuß, auf das man sich auch verlassen kann - dann spart man sich nämlich die manuelle Nacharbeit.
Trotzdem hätte es mich interessiert, wer der Scherzkeks ist.
Hab ich ne Möglichkeit das heraus zu finden ?
Also in Deutschland nur, wenn du ein Richter bist. Weiß nicht, wie das in der Schweiz ist ...
MfG,
EKKi
Hello,
Pos12: 0,0 Euro
Falsche Preise? Oder Manipulation auf dem Client?
Gary hat seine mit JavaScript gebaut, um dem Kunden gleich on-the-fly auszurechen zu können, was es kosten wird. Allzu große Paranoia würde ich hier auch nicht haben. Die JavaScript-Lösungen sind, wenn der Client sie untersützt (Was doch heute in über 90% der Fälle so ist), schön schnell und für den Kunden nachvollziebar. Sie funktionieren eben wie Excel. Man sieht, dass sich was tut.
Ich hab's mir gerade nochmal angesehen unter http://www.vam-shop.com/shop_de.htm
Er hat eben ein rechnendes Formular
Wer nur so eine begrenzte Anzahl Artikel hat, kann das so manchen. Da erspart man sich die ganze Vorgangverarbeitung auf dem Server, braucht keine Sessions usw.
Was aber auf jeden Fall fehlt, sind die gesetzlich vorgeschriebenen Hinweise für den Fernabsatz.
Die sollte er schnellstens ergänzen, bevor der Shop "heiß" wird.
Was ist mit den Kunden ohne JavaScript? Ich wollte meins eben nicht extra abschalten. Das ist im IE immer so umständlich.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Mahlzeit,
Er hat eben ein rechnendes Formular
Das ist ja auch schön und gut - für die optische Darstellung beim Client. Für die tatsächliche Bestellung ist dagegen eine Validierung der (Benutzer-)Eingaben und eine Berechnung auf dem Server absolut unerlässlich.
Wer nur so eine begrenzte Anzahl Artikel hat, kann das so manchen. Da erspart man sich die ganze Vorgangverarbeitung auf dem Server, braucht keine Sessions usw.
Bitte? Im Leben nicht! Wer den Preisangaben, die ein Client an den Server sendet, einfach glaubt und daraufhin zum Beispiel Versand- oder Buchungsvorgänge auslöst, handelt grob fahrlässig. Ich wiederhole es gerne nochmal: ALL INPUT IS EVIL! Man kann sich NIE darauf verlassen, dass der Benutzer sinnvolle Eingaben gemacht hat oder ob nicht irgendwo irgendeine Art von Manipulation stattgefunden hat.
Was ist mit den Kunden ohne JavaScript? Ich wollte meins eben nicht extra abschalten. Das ist im IE immer so umständlich.
Tja, wenn ich das richtig verstanden hab, können die dann entweder nicht bestellen oder bekommen alles kostenlos - keine Ahnung. Aber wie ich gary in einem seiner vorherigen Threads verstanden habe, interessieren ihn (potentielle) Kunden ohne (aktiviertes) Javascript im Browser eh nicht.
MfG,
EKKi
Hi EKKI
Für die tatsächliche Bestellung ist dagegen eine Validierung der (Benutzer-)Eingaben und eine Berechnung auf dem Server absolut unerlässlich.
Die E-Mails sollen nach erhalt ausgedruckt werden. Eine Sekretärin müsste halt eben die Bestellliste noch mal durchrechnen. Vielleicht kann man die Kontrolle der Order auch irgendwie automatisieren.
Bitte? Im Leben nicht! Wer den Preisangaben, die ein Client an den Server sendet, einfach glaubt und daraufhin zum Beispiel Versand- oder Buchungsvorgänge auslöst, handelt grob fahrlässig.
Wie gesagt,vor dem Ausdruck steht der Mensch, der die Mail öffnet und überfliegt. So sind sinnlose Angaben zu entdecken. Nur die Summenkontrolle könnte aufwendig werden.
Aber wie ich gary in einem seiner vorherigen Threads verstanden habe, interessieren ihn (potentielle) Kunden ohne (aktiviertes) Javascript im Browser eh nicht.
So krass ist es nun auch wieder nicht gemeint. Nur diese Produkte sind für angefressene PC-Spieler gedacht,und die haben "meist" das neuste vom neusten installiert. Ich meine das JavaScript Standart ist. Besuche doch mal Seiten von grossen Automobilhersteller. Da geht ohne JavaScript oder Flash nicht viel. Und wenn ich ein wenig komfort haben möchte, dann hat "man" in der Regel JavaScript eingeschaltet. Entsprechende Hinweise möchte ich noch auf der Homepage anbringen, das man JavaScript benötigt. Und in die AGB soll noch rein, wer versucht mit gefälschten werten zu bestellen wird angezeigt oder so ähnlich. Bringt mir natürlich nur was wenn man technisch die Person ermitteln kann.
Gruss gary
MfG,
EKKi
Hello,
[...] Und in die AGB soll noch rein, wer versucht mit gefälschten werten zu bestellen wird angezeigt oder so ähnlich. Bringt mir natürlich nur was wenn man technisch die Person ermitteln kann.
Warum so hart?
Du kannst die gefälschten Werte doch erkennen. Dann kann man nachfragen. Wenn das nicht geht, wird die Bestellung eben einfach nicht angenommen. Warum Aufwand treiben, der die Kunden verscheucht und Dich Geld kostet?
Was Du besser tun solltest, wäre Werkzeuge für die bequeme Verarbeitung zu bauen, die dann nur Dir und Deinen Mitarbeitern zur verfügung stehen.
Bestelleingänge Roh mit eben dieser Datenjontrolle (Übermittelte Werte zu nachgerechneten)
Weitergabe an den Versand nur die als richtig markierten.
Weitergabe an die Buchhaltung nur die als versandt markierten
Ausdruckbare Auswertungen dafür bauen. Das im einfachsten Fall im reinen HTML (also erzeugt z.B. durch PHP) oder aber, wenn die Listen komplexer werden, eben mit PDF-Funktionen der Scriptsprache Deines Vertrauens.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hi Tom,
Ich könnte mir im Excel eine geeignete Vorformatierung schaffen, in die ich den E-Mail Inhalt hinein kopiere. Dort kann ich die Stückzahlen mit einem Fest hinterlegten Wert multiplizieren. Die so erhaltenen Ergebnisse stimmen somit. Nur müsste ich dann eben 6 verschiedene Vorformatierungen haben - wegen der unterschiedlichen MwSt Sätze.
Im Excel kenn ich mich recht gut aus (Habe mal für einen früheren Arbeitgeber ein Komplettes Ersatzteilprogramm mit Preisberechnung geschrieben)
Oder doch alles vor Hand ?
Gruss gary
Hello,
Oder doch alles vor Hand ?
Ich würde mir hierfür ein eigenes internes Verarbeitungsformular (HTML) bauen, dass vom Server mit den Werten gefüllt wird, die zu einer bestellung gehören. Das Script kann dann auch gleich nachrechnen/nachschauen, ob die Daten plausibel sind. Es holt sich die Werte aus einer Datei.
CSV-Format (Vollständig bitte, mit Einschlusszeichen und Trennzeichen) bietet sich da an, weil Du diese Datei dann zur Not auch direkt mit Excel lesen kannst.
Dazu benötigst Du dann auf dem Server natürlich eine Scriptsprache.
Auf den eMail-Versand würde vollkommen verzichten.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Die E-Mails sollen nach erhalt ausgedruckt werden. Eine Sekretärin müsste halt eben die Bestellliste noch mal durchrechnen. Vielleicht kann man die Kontrolle der Order auch irgendwie automatisieren.
Warum bietest Du nicht einfach ein Faxformular zum Download an, das der Kunde dann per Hand ausfüllt und faxt? Das spart Dir viel Zeit und Nerven, die Du in die Programmierung eines Webshops investierst. Ansonsten kann ich mich FraFu und Ekki nur anschließen: Wenn Du schon einen Webshop programmierst, dann mache es richtig, alles andere ist vertane Zeit, die Du sicher besser nutzen kannst.
Siechfred
Hello,
Warum bietest Du nicht einfach ein Faxformular zum Download an, das der Kunde dann per Hand ausfüllt und faxt? Das spart Dir viel Zeit und Nerven, die Du in die Programmierung eines Webshops investierst. Ansonsten kann ich mich FraFu und Ekki nur anschließen: Wenn Du schon einen Webshop programmierst, dann mache es richtig, alles andere ist vertane Zeit, die Du sicher besser nutzen kannst.
Was ist denn an einem "Mailformular mit JavaScript" so falsch, außer dass er beim Fax eventuell noch eine Information gewinnt, die Absendernummer. Aber auch die muss nicht stimmen. Da kann man dann demnächst nur leichter auf die Vorratsdaten des Telefonanbieters zurgreifen (lassen).
Für den Kunden ist die von Gary gewählte Vorgehensweise die richtige, weil sie keinen Medienbruch verursacht!
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Was ist denn an einem "Mailformular mit JavaScript" so falsch, außer dass er beim Fax eventuell noch eine Information gewinnt, die Absendernummer. Aber auch die muss nicht stimmen. Da kann man dann demnächst nur leichter auf die Vorratsdaten des Telefonanbieters zurgreifen (lassen).
Es geht hier um die Möglichkeit, eine Onlinebestellung aufzugeben, nicht um einen Formmailer, oder habe ich was verpasst? Wenn ich einen Onlineshop ansurfe, dann erwarte ich auch einen, so einfach ist das. Und der bietet mir alle Funktionen von der Eingabe meiner persönlichen Daten über die Auswahl der Artikel, der Versandmethode und der Zahlungsweise, der Ausgabe (Berechnung) meiner Rechnungssumme einschließlich Versandkosten pp. bis hin zu einer Bestätigung meiner Bestellung, ob als ausdruckbare Seite oder als E-Mail ist mir dabei egal. Und davon ist Gary m.E. noch ein Stück weit entfernt.
Für den Kunden ist die von Gary gewählte Vorgehensweise die richtige, weil sie keinen Medienbruch verursacht!
Was ist "Medienbruch"?
Siechfred
Hi Siechfred,
Es geht hier um die Möglichkeit, eine Onlinebestellung aufzugeben, nicht um einen Formmailer, oder habe ich was verpasst?
Ich habe abe einen Formmailer der nur anders heisst ;-)
Wenn ich einen Onlineshop ansurfe, dann erwarte ich auch einen, so einfach ist das. Und der bietet mir alle Funktionen von der Eingabe meiner persönlichen Daten
Hab ich...
über die Auswahl der Artikel..
Hab ich auch...
der Versandmethode und der Zahlungsweise
Hab ich ebenfalls...
der Ausgabe (Berechnung) meiner Rechnungssumme einschließlich Versandkosten... pp.
Hab ich schon wieder..
bis hin zu einer Bestätigung meiner Bestellung, ob als ausdruckbare Seite oder als E-Mail ist mir dabei egal.
Es gibt eine Versandbetätigung vom FormMailer-Prog:
www.vam-shop.com/order_answer_de.htm
Und ich habe ein Tool auf dem Server entdeckt, mit dem Namen Autoresponse. Das wird ein automatischer E-Mail versender sein. Also quasi die vom Besteller gemachte E-Mail Adresse auslesen und dem Besteller eine Antwort schicken
(Ist ein anderes Thema und wird wahrscheinlich nicht so einfach sein)
Und davon ist Gary m.E. noch ein Stück weit entfernt.
Aber nicht allzuweit - kann die Küste vom Deck bereits sehen...
Für den Kunden ist die von Gary gewählte Vorgehensweise die richtige, weil sie keinen Medienbruch verursacht!
Was ist "Medienbruch"?
Siechfred
Ich habe abe einen Formmailer der nur anders heisst ;-)
Dann ist es doch in Ordnung. Wenn Du jetzt noch die Eingaben serverseitig prüfst und dem User die Möglichkeit der Korrektur gibst, die Berechnung des Endpreises auch ohne Javascript verfügbar machst, bist Du doch auf Userseite schon fast fertig. Was halt komplett fehlt, ist die Anbieterseite, nämlich Deine. Was da alles noch geht, wurde Dir ja schon mehrfach gesagt, sei bitte nicht so leichtsinnig, die technischen Möglichkeiten nicht auszuschöpfen. Langfristig wirst Du damit mehr Freude haben, ggf. mit der Sekretärin, die dann nichts mehr nachrechnen muss und Zeit für andere Dinge hat ;))
Siech*ein Euro in die Machokasse werf*fred
Hi Siechfred
ggf. mit der Sekretärin, die dann nichts mehr nachrechnen muss und Zeit für andere Dinge hat ;))
Jo, *lol*...
Der war gut...oder wie der Ammi sagt "give me five !" (Ich meine jetzt nicht Sekretärinen - wäre doch zuviel...) :-))
Güsse gary
Mahlzeit,
Der war gut...oder wie der Ammi sagt "give me five !" (Ich meine jetzt nicht Sekretärinen - wäre doch zuviel...) :-))
Aha. Schon so alt und unfit? ;-P
MfG,
EKKi
Mahlzeit,
Und davon ist Gary m.E. noch ein Stück weit entfernt.
Aber nicht allzuweit - kann die Küste vom Deck bereits sehen...
Ich hoffe für dich, dass du deinen "Online-Shop" ausführlichst - auch und insbesonders von Dritten - testen lässt, bevor du ihn "scharf schaltest". Und dass du genügend Zeit für Fehleranalyse und Bugfixing einplanst. Im Moment klingt die ganze Geschichte (für mich und ausgehend von deiner im Ursprungsposting genannten Mail) nämlich nicht sehr vertrauenerweckend.
MfG,
EKKi
Hallo EKKi,
Danke - Hoffnung ist ja was gutes. Betreffend Spamschleuder haben wir (ich und SelfHtml) glaube ich alle Schäfchen im Trockenen.
Und solange der Shop nicht plötzlich zum Supershop wird, muss das halt vorerst so gehen. Kompromisse muss man halt auch mal eingehen. Besser kann es immer noch werden. Und von nichts kommt nichts. So ne Schreibkraft im Büro ist ja nicht gerade billig, da kann sie auch ruhig mal ein paar Zahlen eintippen , oder ?
Danke dir, gruss gary
Mahlzeit,
Und solange der Shop nicht plötzlich zum Supershop wird, muss das halt vorerst so gehen. Kompromisse muss man halt auch mal eingehen. Besser kann es immer noch werden. Und von nichts kommt nichts. So ne Schreibkraft im Büro ist ja nicht gerade billig, da kann sie auch ruhig mal ein paar Zahlen eintippen , oder ?
Wie ich bereits schrieb: Menschen machen Fehler.
Ich würde JEDER ausführlich getesteten Schnittstelle zum automatischen Datenaustausch (z.B. zum Auslesen von Bestelldaten aus einem Onlineshop und Importieren in Excel) erheblich mehr vertrauen als einem Menschen (egal, wie teuer, wie gut, wie persönlich bekannt), der Emails überfliegt, ausdruckt, nachrechnet und abhakt.
MfG,
EKKi
Hallo,
So ne Schreibkraft im Büro ist ja nicht gerade billig, da kann sie auch ruhig mal ein paar Zahlen eintippen , oder ?
so gesehen mag das okay sein.
Aber mir widerstrebt es immer sehr, wenn ich sehe, dass Informationen irgendwo elektronisch vorliegen, und dann doch wieder von Hand übertragen werden. Sei es aus falsch verstandener Sparsamkeit, oder sei es wegen inkompatibler Systeme und/oder Datenformate. Informationen, die in einer bestimmten Form schon elektronisch erfasst sind, sollte man immer auch elektronisch weiterverarbeiten - nach gründlicher Kontrolle, versteht sich. Und auch diese Kontrolle kann man zum Großteil automatisieren, manchmal zu 100%.
Schönen Abend noch,
Martin
Hello,
Aber mir widerstrebt es immer sehr, wenn ich sehe, dass Informationen irgendwo elektronisch vorliegen, und dann doch wieder von Hand übertragen werden. Sei es aus falsch verstandener Sparsamkeit, oder sei es wegen inkompatibler Systeme und/oder Datenformate. Informationen, die in einer bestimmten Form schon elektronisch erfasst sind, sollte man immer auch elektronisch weiterverarbeiten - nach gründlicher Kontrolle, versteht sich. Und auch diese Kontrolle kann man zum Großteil automatisieren, manchmal zu 100%.
Daran arbeiten wir doch in diesem Thread.
Aber Gary hat uns mitgeteilt, dass er nur ein wenig Perl kann.
Perl lernt man aber nun wirklich nicht an einem Nachmittag. Sonst könnte ich es ausreichend gut .-O
Die Lernkurve von PHP ist da schon wesentlich angenehmer.
Und bis zum Umgang mit Dateien benötigt man etwa acht Lerntage, wenn man Anleitung hat und jeden Tag ungefähr zwei Stunden durchhält. Repitition dann natürlich auch eigene Zeitrechnung...
Es hat mMn nach keinen Sinn, einen Fragesteller, der schon einen Teil geleistet hat, gleich mit dem ganzen Rest zu konfrontieren, den er noch nicht geschafft hat.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hello,
Was ist "Medienbruch"?
Jetzt willst Du mich aber hochnehmen, du alter Schlawiner Du ;-)))
Wer Online-Shops bauen und/oder kritisieren kann, weiß das doch.
Und für alle anderen Mitleser
http://de.wikipedia.org/wiki/Medienbruch
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Jetzt willst Du mich aber hochnehmen, du alter Schlawiner Du ;-)))
Das liegt mir fern, ich hab's im Kreuz ;)
Wer Online-Shops bauen und/oder kritisieren kann, weiß das doch.
Offenbar hast Du nicht verstanden, was ein Medienbruch ist, denn wie sonst kämst Du zu dieser Aussage:
"Für den Kunden ist die von Gary gewählte Vorgehensweise die richtige, weil sie keinen Medienbruch verursacht!" (Quelle)
Wenn das Ausdrucken und händische Nachrechnen von elektronisch übermittelten Bestelldaten kein Medienbruch ist, was dann? Übrigens, "Bingo!" *vbg*
Siechfred
Hello,
"Für den Kunden ist die von Gary gewählte Vorgehensweise die richtige, weil sie keinen Medienbruch verursacht!" (Quelle)
Stimmt doch. Lies doch mal richtig! FÜR DEN KUNDEN gibt es bei der von Gary geählten Variante keinen Medienbruch. Dieser Satz zielte auf deine Aussage, dem Kunden doch ein Bestellformular zum Ausdrucken, manuell Ausfüllen und Zurückfacxen anzubieten.
Dass auf der Bearbeiterseite noch 'was zu tun ist, habe ich doch ebenfalls erwähnt.
Die Vermeidung von Medienbrüchen sollte natürlich überall angestrebt werden, wo sie nicht absichtlich (aus Sicherheitserwägungen) eingefügt wurden. Aber zuerst sollte man dies auf Kundenseite tun, wenn man eben nicht überall zur gleichen Zeit tun kann.
Ich denke, dass Gary auf den richtigen Weg kommt, genauso wie Andere hier im Forum.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Stimmt doch. Lies doch mal richtig! FÜR DEN KUNDEN gibt es bei der von Gary geählten Variante keinen Medienbruch. Dieser Satz zielte auf deine Aussage, dem Kunden doch ein Bestellformular zum Ausdrucken, manuell Ausfüllen und Zurückfacxen anzubieten.
Wenn auf dem Weg, den eine Information nimmt, ein Medienwechsel stattfindet, ist das ein Medienbruch, Punkt. Ich weiß nicht was Du hier mit dem Kunden willst, aus seiner Sicht findet genauso ein vermeidbarer Medienbruch statt wie aus Garys Sicht. Und aus Kundensicht birgt dieser Medienbruch genauso wie aus Garys Sicht die Gefahr des Informationsverlustes.
Siechfred
Hello,
Wenn auf dem Weg, den eine Information nimmt, ein Medienwechsel stattfindet, ist das ein Medienbruch, Punkt. Ich weiß nicht was Du hier mit dem Kunden willst, aus seiner Sicht findet genauso ein vermeidbarer Medienbruch statt wie aus Garys Sicht. Und aus Kundensicht birgt dieser Medienbruch genauso wie aus Garys Sicht die Gefahr des Informationsverlustes.
*huch*
Eben wusstest Du noch gar nicht, was ein Medienbruch ist, und nun traust Du Dich schon
PUNKT.
zu schreiben?
Magst Du noch ein wenig lesen?
[http://de.wikipedia.org/wiki/Ignorant]
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Eben wusstest Du noch gar nicht, was ein Medienbruch ist, und nun traust Du Dich schon
PUNKT.
zu schreiben?
Wer einen Begriff gebraucht, sollte wissen, was er bedeutet. Mir war nicht klar, warum Du den Begriff "Medienbruch" ins Spiel gebracht hast, deshalb meine Nachfrage. Jetzt scheint mir, dass Du den Begriff einfach nur falsch verwendet hast, und das kann man auch einfach mal zugeben. Aber wenn ich das hier:
Magst Du noch ein wenig lesen?
[http://de.wikipedia.org/wiki/Ignorant]
lese, habe ich eigentlich keine Lust mehr auf diese Diskussion.
Siechfred
He Leute,
kriegt euch wider ein. Ich hab ja nur gefragt, ob die möglichkeit besteht, ip und user zu idetifizieren (OP). Das ist kein Grund sich gegenseitig den Kopf abzureisen. Also bitte - peace !
Ich muss jetzt eh weiter, also bringt es nichts sich zu streiten...
Danke für die offenen Einschätzungen bezüglich meines Systems
Grüsse gary
Mahlzeit,
entschuldige bitte, wenn ich mich grad könglich amüsiere.
Für die tatsächliche Bestellung ist dagegen eine Validierung der (Benutzer-)Eingaben und eine Berechnung auf dem Server absolut unerlässlich.
Die E-Mails sollen nach erhalt ausgedruckt werden. Eine Sekretärin müsste halt eben die Bestellliste noch mal durchrechnen. Vielleicht kann man die Kontrolle der Order auch irgendwie automatisieren.
Du bastelst dir also mit viel Aufwand ein Formularsystem ("Online-Shop" passt wirklich nicht), mit dem deine Kunden Bestellungen erfassen und nach ihrem Gutdünken manipulieren können, lässt deinen Server, der vor Langeweile gar nicht weiß, wieviele Milliarden Schäfchen er noch zählen soll, die Bestellungen grad mal per Email an dich schicken, druckst diese Emails dann aus, eine Sekretärin rechnet die dann per Hand (lass mich raten: mechanische Additionsmaschine? Bleistift?) nach ...
... da kenne ich absolute Offline-Shops, die effektiver arbeiten. Warum nutzt du die dir zur Verfügung stehende Technologie nicht effizienter?
Wie gesagt,vor dem Ausdruck steht der Mensch, der die Mail öffnet und überfliegt. So sind sinnlose Angaben zu entdecken. Nur die Summenkontrolle könnte aufwendig werden.
Aber der Server kann dir doch bei der Vorkontrolle helfen! Warum willst du die Chance, dir (und deinen Mitarbeitern) reichlich Arbeit zu ersparen, nicht nutzen? Der Server könnte doch alle Bestellungen mit ungültigen Personendaten gar nicht erst annehmen bzw. weiterleiten und statt der auf dem Client berechneten (und evtl. manipulierten) Summen einfach korrekte Preise auf Basis der bestellten Mengen mit echten, gültigen Preisen und Steuersätzen berechnen - dann hast du in deinen Mails korrekte Summen und musst nichts aufwändig per Hand (und Additionsmaschine bzw. Bleistift) überprüfen ... das spart Zeit und damit Kosten.
MfG,
EKKi
Hi EKKi,
Du bastelst dir also mit viel Aufwand ein Formularsystem ("Online-Shop" passt wirklich nicht).
Weiss du, die Grundidee war ein System ohne diesen lästigen Warenkorb(Auch Einkaufswagen genannt). Ich wollte dass man auf einen Blick (auf einer Seite) gleich alles sieht. Was ist ausgewählt, wieviel Stück, was kostet die einzelne Position, gesamt,Brutto,Netto MwSt , Adresse und fertig. Und dieses "Alles auf einen Blick"- Design hab ich doch hinbekommen.
.. mit dem deine Kunden Bestellungen erfassen und nach ihrem Gutdünken manipulieren können, lässt deinen Server, der vor Langeweile gar nicht weiß, wieviele Milliarden Schäfchen er noch zählen soll, die Bestellungen grad mal per Email an dich schicken, druckst diese Emails dann aus, eine Sekretärin rechnet die dann per Hand (lass mich raten: mechanische Additionsmaschine? Bleistift?) nach ...
Ja das stimmt. Aber bis jetzt würde es sofunktionieren - wenn auch mit abstrichen (manipulationen). Diese könnte man aber mit entsprechendern Anweisungen an das zukünftige Personal begegnen:"Kontrolliert bitte sämmtliche Bestelleingänge auf Plausibilität und korrekte Preise"
Warum nutzt du die dir zur Verfügung stehende Technologie nicht effizienter?
Ich bin ja dran. Das Problem ist das ich Serverseitig nicht programmieren kann. Mein Pearl hat mit hilfe von SelfHtml gerade ausgereicht, um die Leerzeile \n in der E-Mail zu entfernen.
»»Warum willst du die Chance, dir (und deinen Mitarbeitern) reichlich Arbeit zu ersparen, nicht nutzen? Der Server könnte doch alle Bestellungen mit ungültigen Personendaten gar nicht erst annehmen bzw. weiterleiten und statt der auf dem Client berechneten (und evtl. manipulierten) Summen einfach korrekte Preise auf Basis der bestellten Mengen mit echten, gültigen Preisen und Steuersätzen berechnen - dann hast du in deinen Mails korrekte Summen und musst nichts aufwändig per Hand (und Additionsmaschine bzw. Bleistift) überprüfen ... das spart Zeit und damit Kosten.
Das wäre ja traumhaft, wenn das so einfach ginge...
BTW. So sieht normal eine korrekte Bestellung mit allen Feldern aus:
Anrede: Herr
Vorname: Gary
Name: Mustermann
GebDatum: 13.08.1975
StrasseNr: Musterstrasse 13
Plz: 12345
Ort: Musterhausen
Land: Deutschland
Email: MrAcryl@gmx.de
Zahlweise: Vorkasse
Vambox: 1
Pos00: 119,95 Euro
Forest: 0
Pos01: 0,0 Euro
Meadow: 0
Pos02: 0,0 Euro
Ocean: 1
Pos03: 3,95 Euro
Fire: 1
Pos04: 3,95 Euro
Fuel: 1
Pos05: 3,95 Euro
Rubber: 1
Pos06: 3,95 Euro
Death: 1
Pos07: 3,95 Euro
Smoke: 0
Pos08: 0,0 Euro
Pool: 0
Pos09: 0,0 Euro
Sweat: 0
Pos10: 0,0 Euro
Femstyle: 0
Pos11: 0,0 Euro
Malestyle: 0
Pos12: 0,0 Euro
Netto: 117,39 Euro
Steuer: 22,31 Euro
Brutto: 139,70 Euro
C1: on
Und geht auch auf eine Din A4 Seite...
Gruss gary
Mahlzeit,
Ja das stimmt. Aber bis jetzt würde es sofunktionieren - wenn auch mit abstrichen (manipulationen). Diese könnte man aber mit entsprechendern Anweisungen an das zukünftige Personal begegnen:"Kontrolliert bitte sämmtliche Bestelleingänge auf Plausibilität und korrekte Preise"
Menschen machen Fehler. Immer.
Wieso nicht diese Fehlerquelle minimieren bzw. ausschließen, indem fehlerhafte Bestellungen vom System erst gar nicht akzeptiert bzw. per Email weitergeleitet werden?
Warum nutzt du die dir zur Verfügung stehende Technologie nicht effizienter?
Ich bin ja dran. Das Problem ist das ich Serverseitig nicht programmieren kann. Mein Pearl hat mit hilfe von SelfHtml gerade ausgereicht, um die Leerzeile \n in der E-Mail zu entfernen.
Das Thema hatten wir schon in einem anderen Thread: wieso willst du alles selbst machen? Insbesonders, wenn du einerseits die entsprechenden Kenntnisse nicht hast, auf der anderen Seite z.B. in diesem Fall eine serverseitige Validierung der Daten dir und deinen Mitarbeitern haufenweise Arbeit, Zeit und damit Geld sparen und darüber hinaus dein Bestellsystem erheblich vereinfachen und im Hinblick auf Sicherheitsaspekte stark verbessern kann?
Das wäre ja traumhaft, wenn das so einfach ginge...
Geht es doch. Das einzige, was du tun musst, ist genau zu definieren, wie gültige Daten aussehen, welche Prüfungen vorgenommen werden sollen, das Ganze aufzuschreiben und dich anschließend an jemanden zu wenden, der sich damit auskennt (allein hier im Forum vagabundieren sicherlich einige Hände voll entsprechend qualifizierter Leute herum).
Und geht auch auf eine Din A4 Seite...
Aha. So viel zum "papierlosen Büro". ;-) Wäre es nicht einfacher, alle Bestellungen eines Tages, die auf dem Server so aufgelaufen sind, per Mausklick in Excel oder Access (oder eine beliebige Warenwirtschafts- oder Buchhaltungssoftware) einzulesen - anstatt jede Email auszudrucken, nachzurechnen, abzuheften, zu kopieren usw. ...?
MfG,
EKKi
Hi EKKi,
Das Thema hatten wir schon in einem anderen Thread: wieso willst du alles selbst machen? Insbesonders, wenn du einerseits die entsprechenden Kenntnisse nicht hast, auf der anderen Seite z.B. in diesem Fall eine serverseitige Validierung der Daten dir und deinen Mitarbeitern haufenweise Arbeit, Zeit und damit Geld sparen und darüber hinaus dein Bestellsystem erheblich vereinfachen und im Hinblick auf Sicherheitsaspekte stark verbessern kann?
Warum fahr ich Passat und nicht Audi ? Weil der Audi teurer ist. Alles was man nicht selber macht kostet richtig viel Geld. Und arbeitsscheu bin ich nicht, nie gewesen. Mein Opa hat sein leben lang gearbeitet. Tagsüber als Maurer, Wochenende im Hotel als Portier Nachtschicht. Hat mit seiner Hände arbeit mehrere Häuser aufgebaut
und sich nie beklagt. Das waren die Leute vom alten "Schlag". Wenn es halt kostenmässig nicht anders geht, dann verlage ich von meinen (zukünftigen) Mitarbeiter eben Einsatz. Arbeit ist eben Arbeit. Und umsonst ist nunmal nichts. Gerne würde ich den Shop noch "besser" und "komfortabler" machen. Aber aufgeschoben ist nicht aufgehoben. Ich wollte alles bis 01.01.2008 fertig bekommen. Der Termin wird eng...
Aha. So viel zum "papierlosen Büro". ;-) Wäre es nicht einfacher, alle Bestellungen eines Tages, die auf dem Server so aufgelaufen sind, per Mausklick in Excel oder Access (oder eine beliebige Warenwirtschafts- oder Buchhaltungssoftware) einzulesen - anstatt jede Email auszudrucken, nachzurechnen, abzuheften, zu kopieren usw. ...?
Wenn das soweit ist, rentiert auch OCR über Scanner,...jojo
Merci gary
Mahlzeit,
Wenn es halt kostenmässig nicht anders geht, dann verlage ich von meinen (zukünftigen) Mitarbeiter eben Einsatz. Arbeit ist eben Arbeit.
Es geht nicht darum, von seinen Mitarbeitern Einsatz zu verlagen. Es geht nicht darum, ob jemand arbeiten will oder nicht. Es geht schlicht und ergreifend um das Risiko bei der nachträglichen Prüfung per Hand. Das würde ich NIEMALS eingehen wollen - ganz einfach weil ich WEISS, dass bei immer wiederkehrenden, relativ anspruchslosen Tätigkeiten IMMER mit einer Fehlerquote von 5% - 10% zu rechnen ist.
Willst du das riskieren? Alle Bestellungen, Kommissionierungsbelege, Rechnungen usw. nach dem 4- oder gar 6-Augen-Prinzip immer und immer wieder überprüfn zu müssen, um sicherzugehen, dass alles korrekt ist? Wofür hast du dann Computer? Nur um hübsche Word-Briefchen darauf zu erstellen? Lass die Geräte doch mal was tun für dich ...
Und umsonst ist nunmal nichts. Gerne würde ich den Shop noch "besser" und "komfortabler" machen. Aber aufgeschoben ist nicht aufgehoben. Ich wollte alles bis 01.01.2008 fertig bekommen. Der Termin wird eng...
Umsonst ist nix. Das stimmt. Aber ich behaupte einfach mal, dass dich auf mittlere bzw. längere Sicht die manuelle Nacharbeit teurer kommt als die einmalige Investition in eine serverseitige Gültigkeitsprüfung. Ganz abgesehen vom latent vorhanden Risiko bei einer derartigen Anhäufung von potentiellen Fehlerquellen ...
Achja - und mit "besser" und "komfortabler" hat das IMHO nichts zu tun. Es ist eher "absolut notwendig", dass ich mich auf mein Bestellsystem verlassen kann (ohne alles mehrfach gegenchecken zu müssen).
Aha. So viel zum "papierlosen Büro". ;-) Wäre es nicht einfacher, alle Bestellungen eines Tages, die auf dem Server so aufgelaufen sind, per Mausklick in Excel oder Access (oder eine beliebige Warenwirtschafts- oder Buchhaltungssoftware) einzulesen - anstatt jede Email auszudrucken, nachzurechnen, abzuheften, zu kopieren usw. ...?
Wenn das soweit ist, rentiert auch OCR über Scanner,...jojo
Noch eine Fehlerquelle mehr. Ich halte nichts davon, Symptome zu bekämpfen - ich versuche lieber, die Ursachen zu erkennen und abzustellen.
MfG,
EKKi
Hello,
Ich bin ja dran. Das Problem ist das ich Serverseitig nicht programmieren kann. Mein Pearl hat mit hilfe von SelfHtml gerade ausgereicht, um die Leerzeile \n in der E-Mail zu entfernen.
Dann klinke Dich doch einfach in den kleinen PHP-Kursus ein, der hier gerade entsteht.
https://forum.selfhtml.org/?t=160669&m=1045118
Vielleicht macht dann später auch nochmal jemand sowas für Perl.
Aber das kann ich nicht gut genug. Daran müsste ich dann wohl selber teilnehmen :-)
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Grütze .. äh ... Grüße!
BTW. So sieht normal eine korrekte Bestellung mit allen Feldern aus:
Anrede: Herr
Vorname: Gary
Name: Mustermann
GebDatum: 13.08.1975
StrasseNr: Musterstrasse 13
Plz: 12345
Ort: Musterhausen
Land: Deutschland
Email: MrAcryl@gmx.de
Zahlweise: Vorkasse
Vambox: 1
Pos00: 119,95 Euro
Forest: 0
Pos01: 0,0 Euro
Meadow: 0
Pos02: 0,0 Euro
Ocean: 1
Pos03: 3,95 Euro
Fire: 1
Pos04: 3,95 Euro
Fuel: 1
Pos05: 3,95 Euro
Rubber: 1
Pos06: 3,95 Euro
Death: 1
Pos07: 3,95 Euro
Smoke: 0
Pos08: 0,0 Euro
Pool: 0
Pos09: 0,0 Euro
Sweat: 0
Pos10: 0,0 Euro
Femstyle: 0
Pos11: 0,0 Euro
Malestyle: 0
Pos12: 0,0 Euro
Netto: 117,39 Euro
Steuer: 22,31 Euro
Brutto: 139,70 Euro
C1: on
Das ist ziemlich unübersichtlich und daher nur sehr schwer manuell auszuwerten.
WENN du es schon so machen willst, dann würde ich die Felder mit Stückzahl 0 und Preis 0
komplett unterdrücken, so daß nur die wirklich angewählten Artikel in der Bestellung
erscheinen.
Cü
Kai
Grütze .. äh ... Grüße!
WENN du es schon so machen willst, dann würde ich die Felder mit Stückzahl 0 und Preis 0
komplett unterdrücken, so daß nur die wirklich angewählten Artikel in der Bestellung
erscheinen.
Das ist eine _sehr_gute_ Idee. Würde ungeheuer die Augen schonen und die Konzentration länger erhalten. (einer der praktisch denkt, gut !)
Dafür müsste ich warscheinlich am FormMailer drehen, oder ?
Das heisst der FormMailer muss die Datenfelder die Leer sind nicht verschicken. Eine if-Abfrage mit dem Wert"" ?
Ja, Perl ist sehr speziell. Ich hab im FormMailer viele Zeilen mit Gatter "#" gesehen.
Das wär aujeden Fall mal ein Thema für die Perl-Rubrik.
Gruss gary
Hello,
Dafür müsste ich warscheinlich am FormMailer drehen, oder ?
verabschiede Dich vom Formmailer und beschäftige Dich damit, wie man aus dem Post des Formulares eine CSV-Datei generieren kann auf dem Server.
Die kannst Du dann in einen geschützen Bereich stellen und nur zugänglich machen für die entsprechenden Mitarbeiter. Oder Du lässt sie über ein weiteres Script (ebenfalls geschützt) anzeigen, das dann im Broswser eine schöne bunte Liste erzeugt.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hallo Tom,
verabschiede Dich vom Formmailer und beschäftige Dich damit, wie man aus dem Post des Formulares eine CSV-Datei generieren kann auf dem Server.
Damit ich die Datenfelder (Input auf dem Client) überhaupt verschicken kann, muss ich ja ein Programm im CGIOrdner auf dem Server starten. Wenn du also sagt vergiss FormMailer, dann muss zwangsläufig ja ein anderes Programm die Connection übernehmen - oder lieg ich da falsch ?
Ich habe ein bischen mit google über CSV (Character Seperated Values) gestöbert. Dort hat man den Voteil die Daten relativ einfach ins Excel zu importieren. Der Nachteil sind die Trennung der Dateninhalte. Man kann ":" , ";" , "/" oder senkrechter Strich benutzen. Für Excel bietet sich ein Semikolon an. Ist jetzt aber eines dieser Trennzeichen ein Dateninhalt, dann gehen die Probleme los. Diese müssen maskiert werden in "". Das heisst ich müsste alle Datenfelder auf Trennzeichen kontrollieren und ggf. maskieren. Sonst stimmt die Anzahl der Felder nicht mehr mit der Excelvorlage überein.
Gruss gary
Die kannst Du dann in einen geschützen Bereich stellen und nur zugänglich machen für die entsprechenden Mitarbeiter. Oder Du lässt sie über ein weiteres Script (ebenfalls geschützt) anzeigen, das dann im Broswser eine schöne bunte Liste erzeugt.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
Hallo Tom,
Und nochwas anderes ist bei CSV nicht so glücklich gelösst:
Bei E-Mail- Bestellungen kann ich dem Personal die E-Mail login- Daten geben. So dass sie die E-Mails auf dem Server abholen können.
Habe ich mit viel Aufwand eine CSV-Datei auf dem Server, dann musste das Personal die Zugangsdaten für meinen Server haben, um (z. B. mit Filezilla) an die datei heranzukommen. Und das wäre mir nicht recht, da man dort viel verstellen und beschädigen kann.
Grüsse gary
hi,
Habe ich mit viel Aufwand eine CSV-Datei auf dem Server, dann musste das Personal die Zugangsdaten für meinen Server haben, um (z. B. mit Filezilla) an die datei heranzukommen. Und das wäre mir nicht recht, da man dort viel verstellen und beschädigen kann.
du kannst die datei ganz normal wie jede andere zum download anbieten (am besten in einem verzeichnis das mit pwd geschützt ist).
shadow
Hello,
du kannst die datei ganz normal wie jede andere zum download anbieten (am besten in einem verzeichnis das mit pwd geschützt ist).
mit ".htaccess" zum Beispiel. Googel mal danach oder suche hier im Forums-Archiv
Du musst wahrscheinlich noch etwas an Deinem Excel umkonfigurieren, damit es CSV-Dateien auch mit activeX ordentlich öffnet...
Oder Du lädst sie eben einfach erst herunter und öffnest sie dann über den Datei-Öffnen-Dialog von Excel, dann klappt es auf jeden Fall.
Beispiel: http://selfhtml.bitworks.de/forum/D0000001.csv
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hello,
Du musst wahrscheinlich noch etwas an Deinem Excel umkonfigurieren, damit es CSV-Dateien auch mit activeX ordentlich öffnet...
Oder Du lädst sie eben einfach erst herunter und öffnest sie dann über den Datei-Öffnen-Dialog von Excel, dann klappt es auf jeden Fall.
In der Datei sind leider ein paar ~ und & drin.
Das kann Excel nicht so gut vertragen.
Aber das Prinzip ist hoffentlich klar geworden.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hi Tom,
Ja, ich seh es. Alles hübsch in Anführungszeichen gekleidet.
Oder Du lädst sie eben einfach erst herunter und öffnest sie dann über den Datei-Öffnen-Dialog von Excel, dann klappt es auf jeden Fall.
Das kan man ja auch so manuell machen.
PS.: Bitte nicht schreien - ist nur so ne Idee:
Wenn ich den FormMailer so änder, dass er alle Datenfelder in Anführungszeichen packt und den Zeilenumbruch, den ich entfernt habe (\n) könnte man in ein Semikolon umbenennen. Dann hätte ich doch eine CSV- Mail oder ?
Soviel zum abstrakten Denken eines Rookies...
Gruss gary
Mahlzeit,
Wenn ich den FormMailer so änder, dass er alle Datenfelder in Anführungszeichen packt und den Zeilenumbruch, den ich entfernt habe (\n) könnte man in ein Semikolon umbenennen. Dann hätte ich doch eine CSV- Mail oder ?
Öhm, nein. Schließlich wird in deiner Mail ja noch mehr enthalten sein als nur Zeilen mit "blablubb";"2";"dideldei";3.23 ... z.B. Header-Zeilen usw.
MfG,
EKKi
Hallo,
Ich habe ein bischen mit google über CSV (Character Seperated Values) gestöbert. Dort hat man den Voteil die Daten relativ einfach ins Excel zu importieren.
stimmt, wenn man die CSV-Datei "ordentlich" anlegt.
Der Nachteil sind die Trennung der Dateninhalte. Man kann ":" , ";" , "/" oder senkrechter Strich benutzen. Für Excel bietet sich ein Semikolon an.
Auch, ja. Aber warum nicht das Komma? Die Abkürzung CSV steht ja ursprünglich für Comma Separated Values.
Ist jetzt aber eines dieser Trennzeichen ein Dateninhalt, dann gehen die Probleme los.
Nein, eigentlich gar nicht. Die einzelnen Feldinhalte sollten generell in Anführungszeichen eingeschlossen werden, so dass nur noch das Anführungszeichen selbst maskiert werden muss, falls es in den Nutzdaten vorkommt.
Das heisst ich müsste alle Datenfelder auf Trennzeichen kontrollieren und ggf. maskieren.
Nein, nur eventuell auftretende Anführungszeichen maskieren (z.B. durch Verdopplung oder durch einen vorangestellten Backslash), und dann den gesamten Wert in Anführungszeichen einschließen.
Wenn man's jetzt noch besonders schön machen will, setzt man in die erste Zeile noch anstatt eines regulären Datensatzes die Spaltenüberschriften (Feldnamen), und schon hat man ein wunderbares Format, das einfach zu erstellen und einfach zu verarbeiten ist, zur Not sogar "zu Fuß".
Ich kann da auch Svens Abneigung nicht nachvollziehen. CSV ist ein Format, das einfach zu "handeln" ist, es ist menschenlesbar, es lässt sich, falls nötig, mit jedem Texteditor bearbeiten.
Dass eine CSV-Datei nur im Kontext der Anwendungen brauchbar ist, mit denen sie erzeugt und verarbeitet wird, ist logisch. Das gilt aber für fast alle Dateiformate. Aus diesem Kontext herausgelöst *kann* es vorkommen, dass bestimmte Informationen nicht mehr eindeutig sind oder keinen Sinn ergeben. Das ist aber bei XML oder jeder beliebigen Datenbank oder einer gegebenen Excel-Tabelle oder einem auf Papier gemalten Diagramm auch so.
So long,
Martin
Moin!
Ich kann da auch Svens Abneigung nicht nachvollziehen. CSV ist ein Format, das einfach zu "handeln" ist, es ist menschenlesbar, es lässt sich, falls nötig, mit jedem Texteditor bearbeiten.
CSV hat keinerlei Möglichkeit, die Codierung zu kennzeichnen. Ist es ISO-8859-1, ist es Windows-1252, ist es gar UTF-8? Keiner weiß es, es läßt sich nicht innerhalb der Datei festlegen. Außerhalb - natürlich, per Konvention geht natürlich alles, aber darauf kann man sich eben nicht verlassen.
CSV hat keinerlei Möglichkeit, die verwendeten Trennzeichen innerhalb der Datei festzulegen. Auch hier gilt: Externe Konvention ist natürlich möglich, hilft aber im zweifel nicht viel. Man nehme nur mal die deutsche Excel-Version: Produziert lustig deutsches Zahlenformat mit Kommas als Dezimalzeichen und Semikolons als Trennzeichen, was absolut nicht harmoniert mit der englischen Excel-Version, die die Kommas als Trennzeichen erkennt, und mit den Semikolons absolut nichts anfangen kann.
Alleine schon die Idee, dass es multiple Trennzeichen geben kann, ist im Prinzip der Horror. Und dass es obendrein keine verpflichtenden Trennzeichen für die Feldinhalte gibt, verschlimmert die Sache nur noch.
Als generisches Speicher- und Datenaustauschformat ist CSV daher absolut unbrauchbar.
Als "letzte Rettung" zur Anwendung bei einer konkreten Applikation, deren CSV-Parameter bekannt sind oder erforscht werden können, kann man es mit Schmerzen verwenden.
Wenn es darum geht, konkret für Excel einen Export zu erstellen, wäre mein Ratschlag: Nimm eine HTML-Tabelle. Wenn die URL auf ".xls" lautet und mit den passenden Mime-Headern versehen wird, speichert der Browser den Download direkt passend bzw. lädt direkt das Excel-Plugin. Oder ein Doppelklick auf den Download öffnet die Datei direkt. Trennzeichen- und Codierungsprobleme treten nicht auf (passendes Meta-Element in die Datei packen). Wenn es sein muß, kann man sogar die Trennlinien in der Tabelle nett formatieren (ansonsten ist das hellgraue Raster leider etwas abwesend).
Alternativ ist XML als Datenaustauschformat definitiv vorzuziehen. Das ist mindestens genauso editorfreundlich, kann dabei aber intern wesentlich übersichtlicher daherkommen, und eliminiert sämtliche von mir angesprochenen Probleme, die CSV hat.
Dass eine CSV-Datei nur im Kontext der Anwendungen brauchbar ist, mit denen sie erzeugt und verarbeitet wird, ist logisch.
Das Problem ist eben: CSV ist nicht gleich CSV. Der Output des einen Programms ist inkompatibel zum Input des anderen Programms, und umgekehrt. Einfacher Datenaustausch sieht für mich anders aus.
- Sven Rautenberg
Hi Sven,
Dank auch dir,für deine Meinung zu CSV.
Das Thema mit der html- Tabelle scheint auch ein guter Weg zu sein. Besonders die Möglichkeit eineDatei als .xls abzulegen, um diese direkt im Excel zu öffnen macht einen komfortablen Eindruck.
Grüsse gary
Hallo Martin,
Danke für die Verdeutlichung von CSV. Natürlich kannich auch Kommata zur Trennung verwenden. Ich meine nur auf Wiki gelesen zu haben, dass Excel ein Semikolon preferieren würde.Aber das scheint mir eine Einstellungssache beim Import zu sein.
Wenn es allerdings noch komplizierter wird, lerne ich doch gescheiter weise Perl und verabreiche meinem FormMailer Flügel,so dass dieser lernt, was leere Datensätze sind und wo Preise manipuliert wurden.
gruss gary
Moin!
verabschiede Dich vom Formmailer und beschäftige Dich damit, wie man aus dem Post des Formulares eine CSV-Datei generieren kann auf dem Server.
CSV ist ein Müllformat! Absolut unzureichend spezifiziert, keinerlei Encoding-Information, Escaping problematisch, etc. Jedes Programm kocht da sein eigenes Süppchen!
Wenn es sich irgendwie machen läßt, sollte man um CSV einen großen Bogen machen - insbesondere der freiwillige Einsatz führt direkt ins Chaos.
- Sven Rautenberg
Hello,
verabschiede Dich vom Formmailer und beschäftige Dich damit, wie man aus dem Post des Formulares eine CSV-Datei generieren kann auf dem Server.
CSV ist ein Müllformat! Absolut unzureichend spezifiziert, keinerlei Encoding-Information, Escaping problematisch, etc. Jedes Programm kocht da sein eigenes Süppchen!
Darum benutze ich ausschließlich die Variante von CSV, sie sich früher "SDF" nannte.
Das hatte jahrzehntelang Bestand, bis M$ kam.
Standard Data Format wurde von IBM vorgschlagen, um die Ashton Tate dBase-Dateien über PC-Connect (das war der Requester) mit System 36 Dateien austauschen zu können.
Da auch alle damals gängigen Hochsprachen das Format konnten (wenn nicht mit eigenen Funktionen, dann eben mit schnell selbst erstellten) hat es sich sher schnell verbreitet. Die Regeln sind einfach.
Felder werden grundsätzlich in " " eingeschlossen.
Kommt im Feld selber ein " vor, wird es verdoppelt
Die so eingeschlöossenen Felder werden durch Semikolon voneinander geetrennt
Das Satzende markiert ein Zeilenumbruch
Da EBCDIC und ASCII schon immer zwei Welten waren, wurden Platzhalter vereinbart
DELIMITER = das Zeichen, das die Felder begrenzt
SEPARATOR = das Zeichen, das die Felder trennt
CRLF = Zeilenumbruch
Erlaubt waren alle Bytecodes aus dem Bereich 0 bis 255
Welcher Code (Codegruppe) nun welches Zeichen darstellte, war eben Sache des Zeichensatzes
Außerdem durften nur vollständige Datensätze übergeben werden. D.h.: alle Zeilen müssen genausoviele Felder haben.
fgetcsv() kann diese Variante lesen.
fputcsv ist aber leider die Microschrott-Variante, in der auch versucht wird, Typen zu übergeben, also numerische Daten _nicht_ in Häkchen einzuschließen, da sie sich daduech von Strings unterscheiden sollen.
Diese Funktion kommt dem gewünschtern Ziel scjhon etwas näher,
allerdings erzeugt sie auch noch keine "vollständigen" Zeilen
function make_csv($_data)
{
$row ='';
if(is_array($_data))
{
foreach($_data as $fieldname => $field_value)
{
$_data[$fieldname] = str_replace('"','""',$field_value);
}
$row = implode('";"',$_data);
if(strlen($row) > 0) ## Datensatz mit Inhalt
{
$row = '"'.$row.'"'."\n";
}
else ## leerer Datensatz
{
$row = "\n";
}
}
return $row;
}
Ich bevorzuge Dateien mit fester Satzlänge und festem Feldaufbau.
Das ermöglicht die volle Wahlfreiheit, vorwärts wie rückwärts
Leider bietet PHP dafür auch keine fertigen Funktionen an. dabei musste es nur endlich die einfache Definition eigener Datenstrukturen einführen. Dann wäöre daw Thema durch.
pack() und unpack() sind da nicht übersichtlich genug.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hello,
Wer nur so eine begrenzte Anzahl Artikel hat, kann das so manchen. Da erspart man sich die ganze Vorgangverarbeitung auf dem Server, braucht keine Sessions usw.
Bitte? Im Leben nicht! Wer den Preisangaben, die ein Client an den Server sendet, einfach glaubt und daraufhin zum Beispiel Versand- oder Buchungsvorgänge auslöst, handelt grob fahrlässig. Ich wiederhole es gerne nochmal: ALL INPUT IS EVIL! Man kann sich NIE darauf verlassen, dass der Benutzer sinnvolle Eingaben gemacht hat oder ob nicht irgendwo irgendeine Art von Manipulation stattgefunden hat.
Man kann sich nicht darauf verlassen, deshalb muss man sie ohnehin nachprüfen.
Warum dann also mehr Aufwand treiben, als notwendig ist?
Man muss nur relavante Daten von abhängigen unterscheiden können.
Der Server wird doch wohl Menge * Preis nachrechnen können, um dem Bearbeiter der Bestellung das Leben ein wenig zu vereinfachen. Es geht hier nicht um maschinelle Massenverarbeitung à la Volkszählung, sondern um eine überschaubare Menge von Bestellungen am Tag.
Es ist nicht immer wirtschaftlich, das technisch machbare anzustreben. Es ist wirschaftlich, das technisch vernünftige zu tun und das steh immer immer Kontext von Aufwand und Nutzen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hallo Tom,
Es ist nicht immer wirtschaftlich, das technisch machbare anzustreben. Es ist wirschaftlich, das technisch vernünftige zu tun und das steh immer immer Kontext von Aufwand und Nutzen.
Der Satzt hat was wahres und mich jetz sehr beeindruckt. Muss ich mir für alle weiteren anfallenden Vorgänge merken !
Gruss gary
Mahlzeit,
Warum dann also mehr Aufwand treiben, als notwendig ist?
Ähm, sorry - aber bei einem Bestellsystem ist für mich absolute Minimalanforderung, dass das, was hinten rauskommt und auf Basis dessen ich komissioniere und Rechnungen erstelle, in sich schlüssig ist. Und das war die Email, die gary in seinem Ursprungsposting zeigte, eben absolut gar nicht (insbesondere, da Personendaten ungültig und Preise falsch waren). So eine Bestellung kann direkt auf dem Server in den Rundordner wandern und muss überhaupt nicht erst auf den Weg gebracht werden.
Man muss nur relavante Daten von abhängigen unterscheiden können.
Der Server wird doch wohl Menge * Preis nachrechnen können, um dem Bearbeiter der Bestellung das Leben ein wenig zu vereinfachen. Es geht hier nicht um maschinelle Massenverarbeitung à la Volkszählung, sondern um eine überschaubare Menge von Bestellungen am Tag.
Schon klar. Aber anscheinend kann garys Bestellsystem ja nicht einmal das. In der in seinem ursprünglichen Posting abgebildeten Mail waren offenbar nur vom Client errechnete, falsche Preise enthalten - jedoch keine vom Server aufgrund gültiger Artikelpreise errechnete Zwischensummen und Gesamtpreise.
Es ist nicht immer wirtschaftlich, das technisch machbare anzustreben. Es ist wirschaftlich, das technisch vernünftige zu tun und das steh immer immer Kontext von Aufwand und Nutzen.
EINMAL ein saubere Bestellsystem zu programmieren oder zu kaufen und einzurichten ist sicherlich auf einen mittleren bis längeren Zeitraum erheblich weniger kostenintensiv als JEDE EINZELNE Bestellung per Hand auf offensichtliche Manipulationen oder Fehler hin zu überprüfen und ggf. auszusortieren (was maschinell ohne Probleme möglich wäre).
MfG,
EKKi
Hello,
Mahlzeit,
Warum dann also mehr Aufwand treiben, als notwendig ist?
Ähm, sorry - aber bei einem Bestellsystem ist für mich absolute Minimalanforderung, dass das, was hinten rauskommt und auf Basis dessen ich komissioniere und Rechnungen erstelle, in sich schlüssig ist. Und das war die Email, die gary in seinem Ursprungsposting zeigte, eben absolut gar nicht (insbesondere, da Personendaten ungültig und Preise falsch waren). So eine Bestellung kann direkt auf dem Server in den Rundordner wandern und muss überhaupt nicht erst auf den Weg gebracht werden.
.. jedenfalls nicht per eMail. Da sind wir uns auch einig.
Trotzdem ist seine Vorgehensweise nicht falsch.
Sie vermeidet auf Kundenseite einen Medienbruch, das ist ein wesentliches Argument für meine vehemente Verteidigung seiner Lösung.
Sie iat aber unvollständig. Auf Bearbeiterseite hat er noch viel zu tun.
Das hat er aber gar nicht abgestritten.
Und ich denke mir, dass diese Diskussion ihm dabei helfen sollte,
anstatt ihn dauernd "rund zu machen"!
Man muss nur relavante Daten von abhängigen unterscheiden können.
Der Server wird doch wohl Menge * Preis nachrechnen können, um dem Bearbeiter der Bestellung das Leben ein wenig zu vereinfachen. Es geht hier nicht um maschinelle Massenverarbeitung à la Volkszählung, sondern um eine überschaubare Menge von Bestellungen am Tag.Schon klar. Aber anscheinend kann garys Bestellsystem ja nicht einmal das.
Es ist doch noch gar nicht fertig. Darauf hat er in seinem Posting zum Design doch hingewiesen.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Trotzdem ist seine Vorgehensweise nicht falsch.
Das hat auch niemand behauptet, sie ist nur unausgereift und unvollständig.
Und ich denke mir, dass diese Diskussion ihm dabei helfen sollte,
anstatt ihn dauernd "rund zu machen"!
Niemand macht ihn rund, aber Deine Postings scheinen ihm den Eindruck zu vermitteln, dass seine Vorgehensweise richtig ist, doch das ist sie nicht. Er ist auf dem richtigen Weg, aber noch lange nicht am Ziel. Ihm etwas anderes vorzugaukeln hieße, ihn ins offene Messer rennen zu lassen.
Siechfred
Mahlzeit,
.. jedenfalls nicht per eMail. Da sind wir uns auch einig.
Trotzdem ist seine Vorgehensweise nicht falsch.
Habe ich ja auch nie behauptet. Es ist nur in meinen Augen (noch lange) kein Online-Shop. Dazu gehört eindeutig mehr als sich manipulierbare Formulare vom Server per Email zuschicken zu lassen und diese dann mit vorsintflutlichen Mitteln manuell überprüfen und weiterverarbeiten zu müssen.
Sie vermeidet auf Kundenseite einen Medienbruch, das ist ein wesentliches Argument für meine vehemente Verteidigung seiner Lösung.
Ähm. Wenn wir uns darauf einigen können, dass das (noch) keine "Lösung" ist, allenfalls ein "Lösungsansatz" oder ein "Konzept", dann stimme ich dir zu. Wobei ich in der heutigen Zeit auch schlicht und ergreifend erwarte, dass ein "Online-Shop" (bzw. "Online-Bestellsystem") dem Benutzer keinen Medienbruch zumutet.
Sie iat aber unvollständig. Auf Bearbeiterseite hat er noch viel zu tun.
Wenn ich ehrlich bin, mehr als viel. Ein in sich geschlossenes Shop-System ist halt doch viel komplexer, als sich das mancher vorstellt. Die Erfahrung habe ich auch schon machen müssen ... ;-)
Und ich denke mir, dass diese Diskussion ihm dabei helfen sollte,
anstatt ihn dauernd "rund zu machen"!
Falls das so rübergekommen sein sollte: das war nicht meine Absicht. Ich möchte mit meinen eindringlichen Worten lediglich davor warnen, ein derart unsicheres, unvollständiges und ineffizientes System produktiv zu nutzen.
Es ist doch noch gar nicht fertig. Darauf hat er in seinem Posting zum Design doch hingewiesen.
Naja. Er sprach im Ursprungsposting dieses Threads von seinem "noch nicht eröffneten Online-Shop" - das klingt schon so gut wie "fast fertig". Abgesehen davon, dass er anscheinend auf seinem Produktiv-Server entwickelt, frage ich mich, wieso ein Entwicklungs- oder Testsystem für alle frei zugänglich ist (und nicht z.B. ber .htaccess geschützt ist, wenn es schon auf einem öffentlichen Server liegen muss).
MfG,
EKKi
Hallo!
Trotzdem hätte es mich interessiert, wer der Scherzkeks ist.
Soviel Aufwand weil dein Webshop Müll ist? Was erwartest du davon, wenn du dann eine IP Adresse hast? Dann weißt du, dass das Scherzkeks über T-Online oder sonst was online ist. Das wars aber auch schon. Oder aber es war irgendein Spambot.
mfg
frafu
Hello FraFru, (was auch immer das heißt *)
Soviel Aufwand weil dein Webshop Müll ist?
Warum sollte ein Webshop gleich Müll sein, nur weil er den User nicht in endlose Sinnlosdialoge über die Richtigkeit seiner Angaben zwingt?
Im wahren Geschäftsleben reichen eigentlich ein Namen und eine Telefonnummer, die der Kunde übermittelt. Dann kann ich ihn anrufen und fragen "haben Sie uns eine Bestellung geschickt?"
Wenn er dann "nein" sagt, muss ich freilich abbrechen, denn sonst wäre es eventuell Kaltaquise...
Aber derartige Shops sollen doch für den Kunden die Kontaktaufnahme vereinfachen, und ihn nicht wie einen zu verhörenden Schwerverbrecher behandeln oder ihn als Deppen dastehen lassen, nur weil er ein Feld einfach nicht ausgefüllt bekommt, so wie die vielleicht sogar kurzsichtige Validierungsregel das erwartet.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hallo frafu
Soviel Aufwand weil dein Webshop Müll ist?
Mal abgesehen von deiner Art dich auszudrücken ist die Aussage "Müll" nicht gerade konstruktiv. Besser du sagst was du für nicht so gut gelungen hältst.
Was erwartest du davon, wenn du dann eine IP Adresse hast? Dann weißt du, dass das Scherzkeks über T-Online oder sonst was online ist.
Ich dachte das man vielleicht die e-mail herausbekommt. Dann könnte ich mich wenigstens bei ihm bedanken. Ich halte seine E-Mail für einen freundlichen "Wink mit dem Zaunpfahl", um auf bestehende Probleme hinzuweisen. Weiter vermute ich, das es jemand der Selfhtml-Leser war - da ich noch keine Werbung geschaltet habe und meine URL quasi unbekannt ist.
Oder aber es war irgendein Spambot.
Mit sicherheit war es kein Spambot. Ich habe bisher noch von keinem Spambot gehört, der nur die Preisfelder auf null setzt. Dies setzt doch eine Intelligenz voraus. Vor allem bei meinem Script, das sowas von nicht standartmässig ist...
Und noch dazu wurden die Netto-Summe , MwSt und Brutto-Summe entfernt. Das machen Bots ja immer...
Gruss gary
Mahlzeit,
Soviel Aufwand weil dein Webshop Müll ist?
Mal abgesehen von deiner Art dich auszudrücken ist die Aussage "Müll" nicht gerade konstruktiv. Besser du sagst was du für nicht so gut gelungen hältst.
Nunja. In gewisser Hinsicht hat der gute FraFu leider Recht: anscheinend werden grundlegende Sicherheits-relevante Aspekte in deinem Online-Shop überhaupt nicht beachtet. Wer sich blind auf Benutzereingaben verlässt, ohne diese auf dem Server zu überprüfen und ggf. zurückzuweisen, der handelt grob fahrlässig.
Was erwartest du davon, wenn du dann eine IP Adresse hast? Dann weißt du, dass das Scherzkeks über T-Online oder sonst was online ist.
Ich dachte das man vielleicht die e-mail herausbekommt.
Wäre mir neu, wenn jeder IP-Adresse eine feste Email-Adresse zugeordnet wäre. Sicher könntest Du dich an den Netz-Verantwortlichen des jeweiligen Netzblocks wenden und lieb "Bitte, bitte!" machen. Aber wie bereits von dem Einen oder Anderen hier angesprochen: zumindest in Deutschland würdest du ohne einen richterlichen Beschluss mit der IP-Adresse nicht viel anfangen können.
Dann könnte ich mich wenigstens bei ihm bedanken. Ich halte seine E-Mail für einen freundlichen "Wink mit dem Zaunpfahl", um auf bestehende Probleme hinzuweisen.
Könnte sein. Könnte natürlich auch sein, dass er einfach mal schauen wollte, welche Lücken dieser neue Shop denn so hat.
Weiter vermute ich, das es jemand der Selfhtml-Leser war - da ich noch keine Werbung geschaltet habe und meine URL quasi unbekannt ist.
Möglich. Aber ich würde mich auch darauf nicht verlassen. :-)
MfG,
EKKi
Hello,
Nunja. In gewisser Hinsicht hat der gute FraFu leider Recht: anscheinend werden grundlegende Sicherheits-relevante Aspekte in deinem Online-Shop überhaupt nicht beachtet. Wer sich blind auf Benutzereingaben verlässt, ohne diese auf dem Server zu überprüfen und ggf. zurückzuweisen, der handelt grob fahrlässig.
Wo ist denn da eine Sicherheitslücke?
Es bestehen vielleicht Zweifel an der Plausibilität der Daten, aber deshalb richten die doch keinen Schaden an. Wenn sie unbrauchbar sind, werden sie eben in die Rundablage oder DEV NUL geschöben.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Mahlzeit,
Wo ist denn da eine Sicherheitslücke?
Anscheinend auf dem Server.
Es bestehen vielleicht Zweifel an der Plausibilität der Daten, aber deshalb richten die doch keinen Schaden an. Wenn sie unbrauchbar sind, werden sie eben in die Rundablage oder DEV NUL geschöben.
Genau. Aber das könnten sie genausogut bereits auf dem Server. Erspart Emails, Nerven sowie Zeit und/oder Personalkosten. Insofern ist die Sache mit dem Schaden relativ ...
MfG,
EKKi
Hallo!
Soviel Aufwand weil dein Webshop Müll ist?
Mal abgesehen von deiner Art dich auszudrücken ist die Aussage "Müll" nicht gerade konstruktiv. Besser du sagst was du für nicht so gut gelungen hältst.
Sorry! Offizielle Entschuldigung meinerseits.
Wenn du aber schon soviel Zeit und Energie in einen Webshop steckst, der sich auf clientseitigen Code verläßt, könntest du auch noch gleich eine serverseitige Überprüfung der Daten einbauen. Dann bekommst du solche Emails erst gar nicht.
Was passiert mit deinem Formular, wenn der Client JS ausgeschalten hat und einfach auf Abschicken klickt? Könnte ja auch aus versehen passieren. Ohne serverseitige Überprüfung wird dann wahrscheinlich auch ein Mail getriggert.
mfg
frafu
Hello Gary,
hello @ All,
ich bin doch erstaunt, was so eine Scherzkeks-Bestellung alles so in Gang bringen kann.
Da bekommt man die "schnelle Hilfe", die da lautet, ist soch sowieso alles Quatsch, was Du da machst, nimm doch was Fertiges, egal ob es Deiner ursprünglichen Intention entsprucht und Du überhaupt verstehst, was die Fertiglösung alles macht.
Und das in einem Forum, das sich einmal das SELF auf die Fahnen gesschrieben hatte.
Da wird auch gar nicht mehr nachgefragt, was der OP eigentlich wirklich will.
Gerade die "alten Hasen" gehen da eher den Weg, schmeiß ihm lieber schnell ein paar Brocken hin, damit er schnell wieder verschwindet. Schämt Euch Jungs!. Die Mädels haben sich bieher ja zurückgehalten...
Jedenfalls entwickelt sich der Thread momantan so gut, dass ich Hoffnung habe, dass endlich mal wieder fachliches Leben in diese verschlafene Gesellschaft fährt. Hier gibt es soviele kompetente Leute, dass sie zusammen die Welt verändern könnten, aber wollen die das überhaupt noch?
Da muss ich manchmal schon verdammt dämlich Fragen stellen hier und mich ständig als DAU outen, damit dann doch mal vernünftige und nachvollziehbare Antworten kommen. Egal, ob es um Firewalls gegen fsockopen() geht oder um die Möglichkeit, Schops mit den Bildern seiner Produkte zu bestücken.
Leute, der Mittelbau ist weggebrochen.
Es gibt keine Leute mehr, wie Fastix oder Lulu (ok der war gelegentlich wieder hier), Fabian Transchel, usw., die die in einfachen Laienworten gestellten Fragen in die fachsprache unserer Koryphäen übersetzen. Diese sind ja augenscheinlich nicht in der Lage aoder nicht mehr gewillt, sich im Sinne der Sache mit Fragen auseinanderzusetzen...
Ich wünsche mir von Herzen, dass sich das wieder ändert!
Ich habe auf die Dauer auch leine Lust, den Dau zu mimen, nur damit Ihr mal aus dem Knie kommt.
Ich hoffe nur, dass Gary solange durchhält, bis sein automatisiertes Bestellformular tatsächlich zu einem kundenfreundlichen und auch für die bearbeiter ergonomischen System gewachsen ist.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Hallo,
Trotzdem hätte es mich interessiert, wer der Scherzkeks ist.
Hab ich ne Möglichkeit das heraus zu finden ?
Wie die anderen schon geschrieben haben, ist das seeehr schwierig bis unmöglich. Nur um Spekulationen vorzubeugen: Ich war's nicht.
Wenn ich mich recht erinnere, habe ich dir schon einmal geschrieben, dass ich es für riskant halte, HTML, PHP, JavaScript und Perl on-the-fly lernen zu wollen, indem man als erstes seinen eigenen Online-Shop bastelt.
Wenn du etwas online verkaufen willst, ok. Wenn du Webdesign und Programmieren lernen willst, auch ok. Aber ich würde beides nicht verknüpfen. Es ist ein gewaltiger Unterschied, ob man eine Homepage à la "Hi, ich heisse XY und meine Hobbys sind Bla Bla Blu" ins Netz stellt, oder einen Shop.
Gute Webdesigner und Programmierer gibt's doch wie Sand am Meer, das kostet nicht die Welt, sich von einem Profi das Ganze mit Hand und Fuß erstellen zu lassen, jedenfalls nicht in deinem Fall. Anschließend kannst du dann nachschauen, wie's gemacht ist, und hast auch was gelernt.
Gruß, Don P