Jump to content

yahalimu

Members
  • Content count

    75
  • Joined

  • Last visited

  • Days Won

    1

yahalimu last won the day on November 10

yahalimu had the most liked content!

Profile Information

  • Real Name
    iain
  • Gender
    Male
  • Location
    Normal For Norfolk

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. yahalimu

    Ultimate Seo Urls 5 Pro

    HI. I have SEO URLS 5 working on 2.3.4. Works well. If I install your recent version on Phoenix, can I configure it so my Product & Categories URL's remain the same as on my old site? (Using roughly the same Db, product names etc)
  2. Hi, My current 2.3.4 site uses SEO URLS 5. I'm just about to start on a a Phoenix site replacement. What is the latest compatible version should I use for this and can I configure it to keep the URL's the same on the new site as the old?
  3. yahalimu

    Fake accounts

    I wish you luck, I would wait a while before celebrating though, I also have had no attempts last weekend and this week so far. My only change so far was to change the URL of contact and create account pages. (I already have a maths question) I was going to implement the honeypot afterwards if it didn't help. Then if absolutely necessary a Captcha after that. The server logs indicated a human interaction about a minute and a half after a failed maths question, that was then answered correctly, so it is possible they may start again if the URL change is noticed and manually updated. Fingers crossed.
  4. yahalimu

    Fake accounts

    Well excuse me for being an idiot. Despite my 15 years on OsC. But please explain how a web user cannot submit the create _account form if he has Algeria as country, yet it is still getting inserted into the Db. Surely a Captcha just prohibits submission of the form, which I have already implemented.
  5. yahalimu

    Fake accounts

    Hi, I meant my installation of 2.3.4 was up to date. I don't think a captcha will help, they somehow have got round the ''error out if country is Algeria' code on create_account.php, which works as I have tested it. To me this indicates something else is going on, bypassing the normal create account procedure. I have started on a Pheonix version but my site is SO custom it will be along time before I have added all the various contributions, added code and changes to code on the back office side, let alone made it look similar to the current layout. Work in progress!
  6. yahalimu

    Fake accounts

    Hi Y'all, A while ago we had a problem with bots filling in the contact_us page. I cured this with an adaption of a simple maths test found somewhere. (Generates a simple random maths question). It worked a treat, stopped all the fake store emails, once I changed for eg. 'What is 3+4' to 'what is the sum of 3 & 4'. Clever bots... Recently though (Last 3 weeks) a new problem has emerged. About 5 times a day currently, a store contact_us email is sent with rubbish text and at the same time a new store account is created. I have previously added code to the create_account to stop the bots we had a while ago, (Ones that used Google as the company name), this worked well. I noticed that the new accounts created recently always used the first country in the country list (Algeria), so I added some code to error out if that country was selected. (We hardly ever sell to Algeria). I tested this by trying to set up an account and it worked well, I could not create a new customer with Algeria as the country. To my surprise this did NOT stop accounts being created with that country. Not only that but I was then then unable to delete the customer via the customer admin page. I removed the code I added and now I can delete them from Admin again if they were added after I removed it. To me this indicates they are not using the create_account page in a normal way. My code seemed to break the a Db customer index (so it couldn't be deleted from admin) when they tried an insert but didn't stop the customer being inserted into the Db. I am now suspicious this is a new exploit so far undiscovered. The originating IP's are all over the world according to the server logs so no IP blocking is going to work. My version is 2.3.4 fully up to date. I'm going to change the create_account file name to something random but I am not confident this will be a cure as they could easily find the proper URL if they looked. Server logs don't seem to tell me much apart from the pages visited and originating IP. I have also checked there are no extra files anywhere, seems ok. Anyone else with this issue or any suggestions?
  7. yahalimu

    Advice needed on shipping module

    OK I got the new Realex/Global Payments SCA HPP payment working. (see attachment) The new code provided by global payments is faulty DO NOT USE. One of them has not been changed/upgraded for 9 years and the other one was missing the final ?> and also an } symbol. Both just typos but would break the server. I also updated the final call URL call which has changed. I left mine using MD5 not SHA1 for ease of commissioning. Post Code extraction software added to make AVS work. Some extra country ISO code conversions back to GB to handle my site using different county codes for zone rate shipping. These also had to be corrected for the HPP additional fields, so extra table entries added. realex.php
  8. yahalimu

    Advice needed on shipping module

    Modesty doesn't apply. To think of a novel way around the problem deserves some credit. The SCA was supposed to be mandatory in EU as of tomorrow (14th Sept) but it has been extended another 2 weeks. Lots of time, I think in my instance I will adjust the payment code to change the ISO-2 code, seems easier. Oh for a post code based shipping module.. Tnx agn.
  9. yahalimu

    Advice needed on shipping module

    Clever. Yes I know what cloning means, just needed confirmation. It is certainly one solution. Have to change database references also I suppose, will check the modules install code. Good bit of lateral thinking though, I will have to balance the choice of payment module code additions verses shipping module changes. It would be handy though, for example Greek islands and some parts of the Alps in France & Spain attract a delivery surcharge with many couriers. The Royal Mail has a flat rate wherever it is in the UK, not so FedEx etc. Definably a need for a more flexible shipping module. Thanks Heather
  10. yahalimu

    Advice needed on shipping module

    That's interesting Heather. When you say How do you mean? I've just installed table rate and I can see where you can set shipping zones but as far as I can see it only allows one zone/instance so its so far, a lot less useful than zone rates. Did you change the module name/ID name and install a few different named but identical shipping modules?
  11. Hi, For years now I have used zone rates shipping. It is useful because for example shipping to the the highlands, Isle of Wight & Scottish offshore islands is much more expensive than mainland UK with most of our couriers.. I had to create a new country and country code for the areas so it would work with zone rate shipping module. Has worked fine for years. My issue is with the new SCA payment regime I'm implementing, the ISO-2 country code sent to the payment gateway MUST be accurate, so my made up code for the offshore islands will now create an error with them and payments may be refused.. Other than hard coding, to convert the made up ISO codes to 'GB' in the payment module, is there another shipping module that would work, for example a post code system for UK orders that would still leave the country code as GB. Or am I doing it all wrong??
  12. yahalimu

    Realex payment gateway

    Hi. Yes the SCA will then start sending purchasers confirmation texts as well as needing a password. Email addresses are also sent to the payment system. I've noticed it on some sites already but will soon be mandatory. Upon closer investigation I think I originally used 'Milestone-3' version whatever that is. The only difference between the two 2011 versions is the assigning of 'my_currency'. In realexmsoscms2: $my_currency = $SESSION_CURRENCY; in realexmsoscms3 $my_currency = $osC_Session->value('currency'); I'm not enough of an expert to know what Osc version upgrade necessitated this change, but the second one works for me on 2.3.4 I shall try implementing the new realex module in the next week or so. Unsure whether I still need the extra postcode formatting for the AVS and mobile URL change but only one way to find out. I wish I could remember why I had to add all that code. It was over 5 years ago and not pro enough to use proper version control! I'll post here results for future searchers.
  13. yahalimu

    Realex payment gateway

    Hi, I shall keep to this thread if that's OK. Comments welcome. We've been running realex for a while. Had some issues with orders paid but missing on the system but turned out to be session timeout issue.(redirected back to login) Increased it on the server and now forced cookie usage on the Db, seems to have cured most but not all issues. In 2012 I used the number 2 version on the realex Osc page.. https://apps.oscommerce.com/eU9NA A few changes had to be made to work properly, some extra postcode check/formatting code for the AVS 3D secure system to format/deal with UK postcodes and some code to handle mobile purchases on my site. For some reason we had to use another URL and change account name. I will attach the file if interested. I used that version because, as MrPhil mention ages ago, there is no such thing as 2.2 Milestone-3. My version is 2.3.4 so to be sure I worked on the milestone-2 code. NOW. My issue is.... We now have to implement this new SCA thing. (Essentially new fields needed) I've been waiting for realex to release some new code as promised. From the link above you can see an new contribution BUT the 'Milestone-2' version is EXACTLY the same as the old one. The 'Milestone-3' version DOES have the extra code needed. No way to contact the devs I can find. realex.php
  14. yahalimu

    Removing fake customers

    This issue has become a big annoyance in the last 4 weeks. I have had about 30 accounts a day created that are obvious bots, starting just before Xmas 2018. (Create account) I solved it (currently) without yet implementing the honey pot trap but am unwilling to publish it explicitly online for obvious reasons. Suffice to say I deleted the gender question many years ago due to customer complaints about the question. (trans-gender sensitivities I assume) If the field is still now sent despite not now being on the form you can assume its a bot. From my investigations it is probably only 1 or 2 bots currently causing the problem. Personally, I detected all the account's and deleted from the admin panel. I did not want to just delete via PHP-My-admin because of possible field link issues. If they get more adventurous I will have to install jacks honeypot trap. Thanks Jack_mcs.
  15. Hi, To send them newsletters or anything they need to consent to yes. But the GDPR also says it is also a requirement to inform all customers of any changes to the privacy policy, whether they are a newsletter subscriber or not and does not need consent. This obviously can be at any time.
×