Beiträge von itsmeJAY

    Hallo,

    Clientseitige Verschlüsselung der Zugangsdaten

    mich würde der konkrete Grund interessieren, weshalb die Verschlüsselung in diesem Fall auf clientseitig umgestellt wurde. Wirklich nur aus Interesse. Nach meinem Verständnis ergibt sich dabei nämlich ein mögliches gleiches Problem wie bei der Verschlüsselung auf dem Server:

    Wenn ein Angreifer den Server bereits kompromittiert hat, könnte er ebenso das Upload-Formular oder den ausgelieferten Client-Code manipulieren. In diesem Fall wäre die clientseitige Verschlüsselung doch ebenfalls angreifbar – im Grunde also ähnlich wie bei einer serverseitigen Verschlüsselung. Eventuell sogar noch stärker, da ein Angreifer zusätzlich das ausgelieferte JavaScript manipulieren und so direkt im Browser eingreifen könnte. Daher erschließt sich mir der sicherheitstechnische Vorteil der clientseitigen Verschlüsselung in diesem Szenario nicht ganz. 🤔

    Außerdem muss das Frontend die öffentlichen Schlüssel ja ebenfalls von irgendwo beziehen. Wenn der Server kompromittiert ist, könnte ein Angreifer auch diese einfach austauschen oder manipulieren.

    Gerade bei einer Webanwendung wie der WoltLab Suite sehe ich daher nicht unmittelbar den sicherheitstechnischen Mehrwert in Bezug auf den Schutz der Daten. Vielleicht übersehe ich hier aber auch einen wichtigen Aspekt, daher würde mich die konkrete Motivation für diese Änderung interessieren.

    Danke auch von mir.

    Noch ein kleiner Einwand: Der Fehler, den ich hier noch zusätzlich gemeldet habe, wurde in ein separates Thema verschoben. Du hast mir dort geantwortet, allerdings habe ich mit dem Account hier keinen Zugriff auf das Lexikon. Hanashi und meine Wenigkeit können Fehler in der Regel sicherlich gut einordnen und ggf. direkt mit einem Hinweis "beheben" und Dir so ggf. Arbeit abnehmen. Ich betreue zudem einige Installationen. Deshalb wäre es sinnvoll, uns oder mir ggf. Zugriff auf den Support-Bereich zu geben - auch weil ich nicht immer über Kunden- oder Unternehmenskonten schreiben kann bzw. darf.

    Liebe Grüße,
    Jonas

    Ich habe rating nun einen Ordner höher gelegt, das passt jetzt.

    Folgenden Fehler kann ich nicht reproduzieren. Hanashi hast du auch wirklich in V 7.2.1 geprüft?

    Zusätzlich habe ich noch einen Fehler gefunden in der Klasse lexicon\data\entry\Entry. Im Konstruktor steht als Parameter ?$row = null müsste aber $row = null oder ?array $row = null heißen, führt sonst zu einer Fehlermeldung.

    Hallo,


    ich hatte dazu neulich eine externe Schulung im Betrieb. Korrekt ist, dass der Empfang ab 2025 verpflichtend ist bzw. man in der Lage sein muss diese empfangen zu können und ab 2027 der Versand. Das Problem ist, dass viele große Unternehmen freiwillig bereits ab 2025 ausschließlich eine E-Rechnung akzeptieren und ab 2027 eine Nicht-E-Rechnung nicht mehr zum Vorsteuerabzug berechtigt - bzw.. nur noch in Ausnahmen. Und jetzt kommt es: Der Empfänger muss eine X-Rechnung nicht akzeptieren, sondern kann auch eine ZUGFeRD Rechnung anfordern, die der Leistende ebenfalls generieren können muss. Das Format ist leider noch nicht einheitlich geklärt.


    BTW gilt dies auch für Kleinunternehmen.

    Hallo

    Nein, beim Shop kann man generell keine Artikelnummern pflegen.

    das wundert mich doch sehr. Versandware hat, es sei denn man strickt selber paar T-Shirts, immer Artikelnummern. :)

    Schade, aber Danke! Möglicherweise sollte in dem Rahmen das Versandwaren-Modul noch einmal überdacht werden. Wofür genau ist das denn da? Wirklich nur für „eigene“ Ware, die man produziert? Aber selbst die hat oft eine Artikelnummer.

    Hallo,

    für Versandware ist es oftmals üblich, dass es für unterschiedliche Ausführungen, unterschiedliche Artikelnummern zur Verfügung stehen.

    Beispiel:

    T-Shirt, Rot, Größe M = TS-RM1

    T-Shirt, Rot, Größe S = TS-RS1

    T-Shirt, Blau, Größe M = TS-BM1

    Das ist natürlich ein einfaches Beispiel. Oft bezieht es sich auf Ware des Großhändlers, wo es für jegliche Variante eines Produkts unterschiedliche Artikelnummern und/oder Eigenschaften gibt. Theoretisch kann ein Artikel (Produkt) x verschiedene Varianten haben in Abhängigkeit von allen möglichen Eigenschaften wie Länge, Breite, Farbe, usw.

    Grundsätzlich geht es aber nicht um Preise, sondern eher um die Artikelnummern, die der Großhändler mitgeteilt bekommen muss.

    Die Frage wäre hier: Sind Varianten pro Artikel abbildbar für Versandware? Kann ein Benutzer also das T-Shirt wählen und dann Zusätze wie „Blau“ oder „Rot“, für die eigene Preise gelten und eigene Artikelnummern?

    Das ist relativ Standard bei Großhändlern, egal in welcher Branche. Oder ist der Shop dafür eher nicht ausgelegt?

    Grüße

    Hallo,

    Wie unschwer zu erkennen ist, beziehen sich die Daten, die im Formular des Shops abgefragt werden, auf ein existierendes Benutzerkonto. Es handelt sich hier um ein simples Login-Formular.

    wieso funktioniert dann ein Klick auf „Registrieren“ nicht, wenn das Formular nicht ausgefüllt ist? Wenn ein Benutzer sich registrieren möchte und den Button „Registrieren“ betätigt, sollte er vorher nicht die Daten in das von Dir eingegebene „Formular für ein existierendes Benutzerkonto“ eingeben müssen. Wenn er keins hat, und auf registrieren klickt, dann müsste er sich eins erstellen können und zum Formular weitergeleitet werden. Davon mal abgesehen, dass die Daten, die dort eingegeben werden, sowieso inkonsistent übernommen werden. Die Mail wird in den Benutzernamen übernommen und das Kennwort wird gar nicht übernommen.

    Faktisch ist es so: Man suggeriert dem Kunden sich einzuloggen, er sagt aber „nö, ich möchte mich registrieren, weil ich kein Account habe“, aber muss vorher das Formular, welches eigentlich zur Anmeldung dient, ausfüllen.

    tl;dr: Der Registrieren-Button sollte die Form nicht absenden. Möglicherweise handelt es sich in Version für WSC 6 auch um einen Fehler, da deine Aussagen gegen den Prozess sprechen, den ich gestern gesehen habe.