Jump to content
Latest News: (loading..)

greasemonkey

Members
  • Content count

    1,242
  • Joined

  • Last visited

  • Days Won

    24

greasemonkey last won the day on December 28 2017

greasemonkey had the most liked content!

Profile Information

  • Real Name
    Scott
  • Gender
    Male

Recent Profile Visitors

29,131 profile views
  1. greasemonkey

    HoneyPot Captcha

    lol nope, just had an account created with Russian Federation as country and Ukraine as IP. Working on installing @burt action recorder to get the correct IP...
  2. greasemonkey

    HoneyPot Captcha

    @Jack_mcs thanks again Jack, this is going off topic for your support thread... Mods, please feel free to move this to its own discussion. Yes, the bot is clearly not using a "browser" anyway to input the values so using a regex HTML5 form to validate is, as you suggest, not a good idea. I deliver the site via Cloudflare, so I'm a little surprised they can even get to the site - almost every Proxy IP I've tried from eastern EU lands on Clouldflare's reCaptcha2 page. SOOO, what I have succeeded in doing so far is pissing the spammer off! They've gone from creating 2-4 accounts per day to 2-4 accounts per hour. Good news, on the create account page I use GEO targeting to enter the Country by IP - so (I think) I'm getting an accurate country for each account. I'm now using htaccess (with Cloudflare's CF-IPCountry) to block large area's of the world like: So far so good.... I add a new country every time they create an account.... 99.8% of our business is from Canada and USA - so no worries really..... but would like to think this is temporary.
  3. greasemonkey

    HoneyPot Captcha

    Wow, this spammer just won't go away.... I'm not sure you can help me any more @Jack_mcs I'm currently trying to use the pattern variable with a negative regex on the company input to validate the form - it works when I test it: pattern="^(?!google$).*" But he is still able to get around it - or at least able to create the account. Looking at Track Delivery in cPanel the email is still going out and being received.
  4. greasemonkey

    HoneyPot Captcha

    Can't quiet get this working Jack Sorry to bug for any more assistence - here is the HTML for the Company Name <div class="form-group"> <label for="inputCompany" class="control-label col-sm-4">Company Name</label> <div class="col-sm-8"> <input type="text" name="company" id="inputCompany" placeholder="Company Name" class="form-control" /><!-- BOF Separate Pricing Per Customer: field for tax id number <!-- EOF Separate Pricing Per Customer: field for tax id number --> </div> </div> And the IsSpammer function, I'm not sure... but it's still validating the form with or without the company name being "google". For the value I've tried both "google" and \'google\'. function IsSpammer() { if(!document.getElementById("honeypot").value) { // The field is empty, submit the form. return true; } else if ((document.getElementsByName("company")[0].value) == \'google\') { return true; } else { // the field has a value it\'s a spam bot return false; } }
  5. greasemonkey

    HoneyPot Captcha

    @Jack_mcs thanks so much... so this? function IsSpammer() { if(!document.getElementById("honeypot").value) { // The field is empty, submit the form. return true; } else if ((document.getElementsByName("company")[0].value) == 'google') { return true; } else { // the field has a value it\'s a spam bot return false; } }
  6. greasemonkey

    HoneyPot Captcha

    @Jack_mcs hey Jack, I'm trying this addon out to help reduce a number of spam accounts being created - and hoping not to have to resort to a captcha solution. So far it hasn't help this specific spammer - he's skipping the new hidden field. I presume it will help prevent future spammers however...... I'm wondering if changing your code around slightly may work? So far, every spam account is created has the company name "google" - all lower case without the quotes. Do you think adding an id=google to the company entry could work (I have no worry Google not my customer... lol) and if so - how could I validate that is says google? <script type="text/javascript"> function validateMyForm(create_account) { var ok = check_form(create_account); if (! ok) return false; return IsSpammer(); } function IsSpammer() { if(!document.getElementById("google").value) { // The field is empty, submit the form. return true; } else { // the field has a value it's a spam bot return false; } } </script>
  7. Just as a quick follow up to the bandwidth above. Server Requests on the 22/23rd were 6 times normal volume - probably a better measure....
  8. Yes, I wouldn't expect it is a wide spread problem - like I said, I've only ever seen this a couple other times, and again it was under extremely high traffic volume. So far so good.... We will be sending out another newsletter in a few days which always gives a good boost to traffic - not like Black Friday & Cyber Monday however. Here's a screen cap from my Cloudflare account showing the bandwidth use - triple normal....
  9. Guess you’re happy I didn’t cut and paste all 30,000 lines???? 😂
  10. @MrPhilYes I wasn't... figured it was a cascading effect. My sessions function file matches Gold (this could be an issue... see below).... I have done as @burt suggested, emptied, optimized and repaired the table - and have changed sesskey from varchar 128 to 255 (as it is in 2.4 Joli). I will monitor over the next few weeks - although I'm not expecting any huge rush of traffic for the neat future........ Looking more deeply, there have been some changes to includes/functions/sessions from Gold (where my file base started) to Frozen/EDGE that I have not kept up to date. Many the change from $HTTP_COOKIE_VARS to $_COOKIE which I presume could???? make a difference????
  11. I agree... what’s the benefit of text column vs increasing to varchar 255?
  12. I've just edited out my domain...
  13. Hey All, I'm having an intermittent issue, under heavy traffic (happened this weekend just after our Black Friday newsletter) where I'm seeing TONS of Sessions errors: Running a 2.3.4 (mostly updated to EDGE).... The DB table for Sessions is InnoDB with utf8_unicode_ci... My configuration, and config file settings are below: define('STORE_SESSIONS', 'mysql'); These above errors are repetitive... and caused my error_log to blow up to over 7mb in 12 hours... almost 30,000 lines. I used a DB optimizer addon cron - so my sessions table only (currently) has a little more than 400 records. Doing a little research, I cannot see anyone with the same obvious problem - except maybe this note: I don't have a timezone defined in my config files - and I find it very unlikely the issue was/is multibyte emjoi characters. The only thing I have come up with is - I've seen a couple people mention on stackoverflow about making sure the DB column is large enough. Its currently set to Varchar(128). I do see, plans to increase the length to the column to 255 in 2.4... Any guesses???????
  14. You found it @burt... thank you. And yes that explains it. I must have assumed Harald added it to the update but never actually did. And I have been using it for the past 18 months, not noticing he didn't... It's mentioned in his reply here that he was going to: That said.... I feel less like I'm losing my mind now. If interested in this fix (which I presume you won't be for this "official" release).... It has a minor, intermittent problem (which was the entire reason for this post). I believe I may have it sorted however will have to test more in my live store under traffic to see if it actually works.
  15. @burtI did a fresh install to test and the story deepens - to force an update I did as you suggest and changed the version.txt file to a previous version (5.010). Ran the PayPal app update and it would seem the PayPal app has changed significantly since I last ran the update on my live store (although the version number has NOT changed) and no longer includes the features I mentioned above. I've spent the last hour trying to find the lengthy discussion I had with Harald in the forum about why and how the PayPal app should be fixed to allow the customers selected shipping option to be carried through the PayPal Express checkout - in place of reverting back to the "cheapest" shipping logic always included with PayPal Express.... and the entire discussion seems to be "nuked". Sorry, to ring your bell ... I just have no clue why Harald would have nuked the best feature of the newest part of OsC 😒
×