mhsuffolk

Still getting this problem. I also have the issue that the maths captcha stops everybody, even legit sign ups, getting through create account. Switch it off and all is well.

Still getting these, followed by Password reset and then a contact us attempt which is being stopped by Honeypot. They must have Java off as I have hard coded the create_account code to display UK as default hence Afghanistan appearing. Suggestion, as Afghanistan is 1 could we create a country named "Select Country" and number it 0 using a SQL query. You would then replace in create_account.php echo tep_get_country_list(NULL, 'required aria-required="true" aria-describedby="atCountry" id="inputCountry"'); With echo tep_get_country_list('country','0', NULL, 'required aria-required="true" aria-describedby="atCountry" id="inputCountry"'); Then get Honeypot to look for country 0 and then snag it? Just a thought as this is a recurring pattern that could be exploited by Honeypot

Using v1.8 In my Phoenix test shop, Frozen live shop and Frozen back up test site I am getting the following behaviour. 1. Install module and all basic settings including pages create account, contact us and tell a friend appear in admin 2. Edit module to alter various settings e.g.check account, disallow letters and numbers etc 3. Save module. The settings have been retained but the list of enabled pages is empty. 4. Checked in the database and the relevant field is empty. 5. Uninstall module 6. Reinstall module and the pages reappear. 7. Edit module, save it and the pages have gone again. I have worked round it by adding the pages manually in the relevant field in phpmyadmin

Looks good, but for OSC should UK be GB

I am using the latest Honey pot on Frozen. I am now getting many fake accounts purportedly from Afghanistan which are following a set pattern of operations. The account is created by populating every field in create account with a string of random letters and presumably their email address. They log off and then go through the password reset procedure. They then use the contact us page to send another random string of letters. Often, but not always I then get a Mail delivery failed message from my host which is the password reset email bouncing back. The action recorder shows two entries for the reset, one with a tick and one with a cross just 1 second apart, then the contact us, which is either from the account just created or 0 in the brackets if the email bounced. Just a suggestion. Would it be possible use this behaviour to get Honeypot to look for this password resetting immediately after account creation and either blocking the IP or alerting the store owner?

Yes, that is the correct behaviour. A payment intent on the Stripe website has to be created first before the card input field can be displayed. An OSC order creation is the first part of this process. I leave any of these in place for 7 days as the customer can still return and complete the order correctly without having to create a new/second order. If it has not been completed by then, simply delete the order in admin. The PayPal app behaves in a similar way.

Hi Jack Thank you for you great add ons. I get this in the server log when accessing the configure page. (In my Phoenix test shop PHP 7.3) PHP Warning: Use of undefined constant BOX_WIDTH - assumed 'BOX_WIDTH' (this will throw an Error in a future version of PHP) in D:\\Phoenix_7_3\\htdocs\\**********\\sitemonitor_configure_setup.php on line 404, referer: http://localhost/*********/sitemonitor_admin.php

Cancel that, brain failure has occurred. I was looking at it in normal mode rather than test mode. All OK now.

Yes. I upgraded from 1.2.1 which worked correctly. I have uninstalled and reinstalled both modules but no change.

I cannot get the MODULE_CONTENT_HEADER_STORE_MODE_CHECKOUT_MESSAGE to show on index.php and checkout pages. Only the admin message " The store is actually in CHECKOUT Mode. Don't forget to switch it back to Online Mode once you finished" shows. Phoenix 1.3.0.0

Try Stripe instead, it is cheaper and now has a fully SCA compliant addon Stripe SCA

Thanks for that. The Stripe issue has been fixed, it was the new Stripe SCA module at fault, now corrected

Us users of Stripe have been very fortunate in that a new forum member @asro2004 appeared from nowhere and has updated the Stripe module for SCA and, along with some testing support from @raiwa and myself, we now have a compliant system. Hopefully somebody will offer their help, but I am afraid it will not be HPDL.

Try this, it is not very pretty but it should help to lead the blind includes/languages/modules/payment/stripe_sca.php Find define('MODULE_PAYMENT_STRIPE_SCA_CREDITCARD_TYPE', 'Credit or Debit card'); Replace with define('MODULE_PAYMENT_STRIPE_SCA_CREDITCARD_TYPE', 'Credit or Debit card_____Expiry Date Security No');

To illustrate, discount rate is 30%