Jump to content

PatStevens

Members
  • Posts

    106
  • Joined

  • Last visited

Everything posted by PatStevens

  1. In the mean time, thought about using the webservice, which gave me some troubles (doesn't accept to PUT the same XML content it gave me). So I might end up changing the data directly in the database and then programatically load the Product Objects and call update() on them (just to fire all needed triggers for indexing and whatnot etc.)
  2. Hello there, we've added a new language to our shop. Now I've got a csv with product descriptions for all products in the new additional language. Any convienient way to do this? (I also thought about writing a little script that inserts data directly to the database (ps_product, ps_porduct_shop) etc.)
  3. Macht Sinn, Bestellungen sollte man auch nicht löschen - gibt im täglichen Ablauf keinen Grund dazu. Außer, der Kunde möchte entsprechend DSGVO sein "Recht auf Vergessen" einfordern. Wenn man dann den Kunden löscht, werden auch die dazugehörigen Bestellungen gelöscht, wie ich gerade sehen durfte.
  4. Hallo zusammen, wärmen wir diesen Thread mal wieder auf... Ein Kunde schreibt heute, dass er nach Artikel 17 DSGV alle seine Daten gelöscht haben möchte. Wenn ich hier von Datenbank-Inskonsistenzen lese, habe ich begrenzt Lust, Kunde und Bestellungen zu löschen. Oder ist das kein problem mehr heutzutage? Spricht alternativ etwas dagegen den Kunden zu deaktivieren und alle seine personenbezogenen Daten zu anonymisieren? (Austauschen durch xxxx oder Ähnliches)
  5. ..vermutlich reicht es, dort ein Constraint hinzuzufügen (mit addConstraint). Das Constraint wäre dann eine Callback-Methode, die das eingegebene Datum parsed und prüft, ob es schon mindestens 18 Jahre alt ist.
  6. Hello altogether, I would like to fix some bugs in prestashop, but I feel a little stupid. I have cloned out the public Prestashop Repository (https://github.com/PrestaShop/PrestaShop) and ran a docker-compose up. After this, of course, the installation scripts run, showing no error messages. From here, the documentation becomes unclear. I cannot access the Shop Frontend (localhost:8001), when I try, I'm instantly greeted by an error message: (1/1) ContextErrorException Notice: Undefined offset: 0 in ImageRetriever.php line 271 at ImageRetriever->getNoPictureImage(object(Language))in FrontController.php line 1515 Am I supposed to run the /install-dev/ flow? Well, if I do, it doesn't help either. What is still missing? Couldn't find much documentation on this.
  7. The way I understand it, new clients that get their password hashed by bcrypt shouldn't have any problems, as I understand the code in: src/Core/Crypto/Hashing.php private function initHashMethods() { $this->hashMethods = array( 'bcrypt' => array( 'option' => array(), 'hash' => function ($passwd, $staticSalt, $option) { return password_hash($passwd, PASSWORD_BCRYPT); }, 'verify' => function ($passwd, $hash, $staticSalt) { return password_verify($passwd, $hash); }, ), 'md5' => array( 'option' => array(), 'hash' => function ($passwd, $staticSalt, $option) { return md5($staticSalt . $passwd); }, 'verify' => function ($passwd, $hash, $staticSalt) { return md5($staticSalt . $passwd) === $hash; }, ), ); } The closures (see bcrpyt) for 'init' and 'verify' don't make any use of $staticSalt (which is the COOKIE_KEY passed in). Only the second hashMethod 'md5' makes use of the COOKIE_KEY. Or am I getting something wrong? I just tested it on my installation and suddenly old users could log in again, while newly created users still can. I'm on 1.7.6.2
  8. Hello UniArt, You're right. So I will ask more comprehensive. I agree that overrides are at least way better than chaning actual Prestashop Code. But still, they are not granted to work for the next updates to come. Especially now, where whole parts of the shop-software are under rewrite from the Prestashop Team. You've seen yourself that you needed to make changes for your ovveride to work with Version 1.7.6.4. I'm writing this, because I'm struggling with what I think about overrides in Presta, not to diss you Guess one should probably have an automated test-suite to make sure nothing breaks after an update
  9. Did so, tested it. Old Users can log in with the "old" cookie_key present. Newly registered users can still login
  10. These overrides only work as long as the overriden class is not changed too much, right? Doesn't seem so susatinable to me 😕 Why do you do the override anyway? Isn't the functionality that md5 is checked as a second step on validation (and even overwriting the password with the new encrpytion method bycrpt) done by prestashop itself already?
  11. I see it in the Hashing.php, thank you. So actually, the $staticSalt (_COOKIE_KEY_) is never used for bcrypt method. There could have no new password been created since 1.7 using _COOKIE_KEY_. Only passwords were created using bcrypt (which doesn't use salt anyway, so no problem). Users that have registered under 1.7 won't even lose their session, since their cookie was encrpyted with the new_cookie_key.
  12. Hello altogether, I post in this thread since my tpoic is exaclty the same. (Just that we went from Prestashop 1.6 to 1.7. (at least not such a huge jump like KickMe )) Our Presta1.6 did password hashing using just md5. The new Prestashop1.7. does it differently. I understand I should have used the same values for cookie_key and cookie_iv as in the old version. Didn't do that due to lack of knowledge (isn't documented anywhere, is it?) 'cookie_key' => 'newlyGeneratedUnfortunately', 'cookie_iv' => 'alsoNewlyGeneratedUnfortunately', 'new_cookie_key' => 'reallyLongNewCode', So in the mean time the shop is running for a few months like this. With 400 newly users registered. These can log in just fine, of course. The old users can't log in, I guess. If I change cookie_key and cookie_iv to the former values from the old installation, can these new 400 users still log in? What cookie keys are used for hashing passwords of new users since 1.7? Cheers, Pat
  13. I see that I should have done so. I have: 'cookie_key' => 'something new', 'cookie_iv' => 'some other code', 'new_cookie_key' => 'reallyLongNewCode', These cookie_key and cookie_iv weren't changed to the values from the old installation. In the mean time the shop is running for a few months like this 400 new users registered. If I change cookie_key and cookie_iv to the former values, can these new 400 users still log in? What cookie keys are used for new users since 1.7?
  14. nobody knows? or is it the wrong part of the forum? 😕
  15. Hallo Wuschel, wie sieht denn dieser Aufwand aus / was müsste man da einbauen? LG, pat
  16. Hello community, I have just migrated a prestashop 1.6 installation to prestashop 1.7. I noticed that some users cannot login anymore. Their credentials don't fit anymore. A quick look into the databases reveals, that the old user's passwords are hashed by MD5 and the newly registered users use another algorhitm. Since hashes are what they are, there could have been no way to "convert" the passwords to the new hashing scheme, alright. And MD5 is not secure, and thus changed, alright, I get it. But: What is the official suggestion to tackle this? What do other merchantes do to ensure that all the users can log in? I cannot be the first person who migrated and encountered this problem - yet I haven't found much official information. Cheers, Pat
  17. Der Weg von eleazar kann bei dir gar nicht funktionieren, weil dies sich auf die Version 1.6 bezieht und du die Version 1.7 hast Habe mal im Code geschaut und habe es einmal kurz getestet. Ging bei mir soweit. in classes/form/CustomerFormatter.php, Zeile 197 heisst es bei mir: if ($this->ask_for_birthdate) { $format['birthday'] = (new FormField()) ->setName('birthday') ->setType('text') ->setLabel( $this->translator->trans( 'Birthdate', [], 'Shop.Forms.Labels' ) ) ->addAvailableValue('placeholder', Tools::getDateFormat()) ->addAvailableValue( 'comment', $this->translator->trans('(E.g.: %date_format%)', array('%date_format%' => Tools::formatDateStr('31 May 1970')), 'Shop.Forms.Help') ); } wenn du dort ans Ende noch einen weiteren Methodenaufruf anhängst, also: if ($this->ask_for_birthdate) { $format['birthday'] = (new FormField()) ->setName('birthday') [...] ->addAvailableValue( 'comment', $this->translator->trans('(E.g.: %date_format%)', array('%date_format%' => Tools::formatDateStr('31 May 1970')), 'Shop.Forms.Help') ) ->setRequired(true); } ...sollte es gehen. Das Layout ("Optional" verschwindet) und die Logik (ist Pflichtfeld) folgen dann dieser Vorgabe. Da das aber eine Codeänbderung im Prestashop-Code ist, kann das bei einem Update wieder rausfliegen, nur mal so als Hinweis.
  18. Moin Ritter, dann wäre ja nur der eine Kunde in der "Schweiz" Gruppe. Ich dachte eher an einen Weg, ALLE Schweizer Kunden und zukünftigen Schweizer Kunden in einer Gruppe zu haben. Das geht wohl nicht. Kann es dann wohl nur über's Land lösen. Sonderpreis für Land eintragen. Wenn es dann nur für Kunde, Gast und Besucher gelten soll, muss ich drei Sonderpreise eintragen.
  19. Den höheren Preis nur als absoluten Preis eintragen zu können.. Das war auch das einzige was ich gefunden hatte. Schade, aber das könnte ich wohl per Skript, dass die preise selbst errechnet und in die Datenbank schreibt erledigen, würde gehen. Aber wie packe ich alle Schweizer in eine Kundengruppe? Habe in der Gruppenverwaltung nichts gefunden, wie ich das machen könnte 😕 Die Plugins schaue ich mir gleich mal näher an, vielleicht sind da auch welch dabei, die den Preis entsprechend erhöhen, danke schon mal.
  20. Über Warenkorb- und Katalogpreisregeln kann ich nur Preisermäßigungen eingeben, keine Erhöhungen, oder? Auch für Katalog / Artikel kann ich auf Artikelebene unterhalb von "Preise" als Sonderpreise nur Ermäßigungen oder fete preise hinzufügen, keine prozentuale Erhöhung, oder? Verdammt. Gibt es noch einen anderen Weg? LG, Pat
  21. Zur Erklärung, warum das gewünscht ist, ist folgender: Auf den Warenwert bei Lieferungen nach CH soll ein kleiner Prozentsatz draufgeschlagen werden, als Provision für eine Agentur (die dann Marketing für das Land (nicht EU) macht). Es soll also relativ zum Warenwert sein. Über die Versandkosten ließe sich das ja nur pauschal machen... PS: Mit dem Geotargeting in den Voreinstellungen kann ich User ja nur blockieren, oder? Die Herkunft der Besucher zu erkennen per Geotargeting, dafür scheint dieses Modul brauchbar: https://addons.prestashop.com/en/international-localization/27368-geo-targeting-pro-by-country-prices-taxes-currency-.html#specifications So könnte ich für alle Artikel dann einen besonderen (höheren) Preis setzen, für das Land (CH). Das wäre nur eine ganz schöne Arbeit, das für alle Artikel zu machen. Ein prozentualer Aufschlag wäre da eine Erleichterung..
  22. Hallo Andi, ist jetzt nicht was du wissen willst, aber soweit ich weiß (mit meinem rechtlichen Halbwissen) ist es nicht mehr Rechtens, laut bestehenden Datenschutzrichtlinien, grundsätzlich bei jeder Bestellung das Geburtsdatum zu erheben. Da müssen triftige Gründ vorliegen (z.B. nur Artikel (Bildträger etc.) ab 18). Und dann auch nur, soweit ich weiß, in Verbindung mit Versandverfahren, die sicherstellen, dass der Artikel bei genau der Person die bestellt hat, ankommt (PostIdent etc.). Selbst, wenn man nur einige entsprechende Artikel im Shop hat, "darf" man nicht grundsätzlich bei jeder Bestellung das Geburtsdatum erheben, soweit ich weiß. Siehe Grundsatz der Datensparsamkeit und Datenvermeidung.
  23. Mal angenommen, man möchte für ein bestimmtes Land die Preise etwas höher ansetzen. Da kann man unter Katalog / Artikel und bei den Preisen durchaus Preisregeln einstellen, die für ein bestimmtes Land gelten. Hierzu meine Fragen: Woran erkennt Prestashop, ob jemand aus diesem Land kommt? Anhand der IP wohl nicht. Anhand der Sprache im Browser? Kann man das irgendwo einstellen? Mir ist schon klar, dass spätestens wenn der Kunde seine Adresse eingibt, oder sich einloggt, Prestashop "erkennt" dass der User aus diesem Land kommt -> und die Preisregel Anwendung findet. Jedoch passiert das stillschweigend. Beispiel: Ich gehe als Gast in den Shop, sehe die niedrigen Preise, fülle den Warenkorb, logge mich ein, und stillschweigend ist der Warenkorb deutlich teurer. Das ist unheimlich für den Benutzer. Kann mann die höheren Preise eventuell an eine Währung binden (CHF + Wechselkurs + Erhöhungsfaktor) Dann könnte man es wiederum umgehen, indem man die Währung wechselt -> blöd Gibt es ein Modul für soetwas? Oder einen anderen Weg? LG, Pat
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More