Jump to content
Latest News: (loading..)

MrPhil

Members
  • Content count

    7,819
  • Joined

  • Last visited

  • Days Won

    101

Everything posted by MrPhil

  1. MrPhil

    Moving from HTTP to HTTPS

    This redirect will not work correctly. If the incoming URL is http://domain.com..., it will rewrite to https://domain.com..., when the OP wants https://www.domain.com... Or, if the incoming URL is https://www.domain.com, it will redirect to... https://www.domain.com...! (probably a 500 error loop) This is why you never use HTTP_HOST in the rewrite -- you always hard code the domain name (with or without the www, as the version you are trying to use). %{HTTP_HOST} is not some canonical form. It is what the visitor typed in as the address, and could have (at a minimum) www or be missing it.
  2. MrPhil

    SEO friendly URL Issue

    Perhaps if the administrator has not filled in the Title Tag - URL, Ultimate SEO should ignore the order to use the "alternate setting"? Either that, or force the administrator to fill in that field. It sounds like the code is not robust enough.
  3. MrPhil

    Removing fake customers

    Then either the wrong "JOIN" is being used for the purpose, or the resulting data needs to be validated (fixed) in some manner before being used (e.g., creating dummy array). It's still not robust code. Unfortunately, it's probably not trivial to fix it.
  4. MrPhil

    Removing fake customers

    If simply missing data will blow up osC, that's a code error. I'm guessing that this is a very old (2.3.4) version of osC, and it might have been fixed in Frozen.
  5. MrPhil

    Removing fake customers

    Just be careful that if it's a blind person using a screen reader that they don't get blocked by your anti-bot measures. That could even be illegal. You might want to label the input field "anti-spambot measure, leave empty" or something like that, until the spammers wise up and catch on to it! (looking for "leave empty", "leave blank", "don't fill in", "for office use only", etc.) Then you might need to use Javascript to scramble the label so bots can't see it without processing the JS (like email hiding can be done), but a screen reader can still speak it. Or maybe the prompt/label could say "enter 735 here:", where the number is randomly generated. It's a never-ending war...
  6. MrPhil

    os crashed when switched to https

    HOW did you switch to https (SSL)? How did you update BOTH configure.php files? Did you update .htaccess to redirect all incoming http: to https: (R=301)?
  7. MrPhil

    Can't log into Admin

    If you're still having trouble with logging in to admin account, follow these instructions: to wipe out the old administrator(s) and allow you to enter a new one (and its password). If you're still trying to run an old osC on a newer PHP, you may run into problems. Also, go over both your admin files with a fine-toothed comb to see if you have any changes to file paths, domain name, SSL usage, cookies, or anything else that you forgot to update when you moved over to the new server. If you have .htaccess password protection on the admin directory, that's a different issue. You should remove any osC password protection files and use your host's "password protect a directory" function. Or did you already get past that point? As for being unable to install "Frozen", that should probably go in a different thread, in the Community Edition area.
  8. MrPhil

    Removing fake customers

    I presume that's the "official" osC 2.3.4? I'm not sure it will properly run at PHP 5.6. The community-supported osC 2.3.4.1BS "Frozen" (see link in my signature) will go to at least PHP 7.1, so you should strongly consider upgrading your shop. As for why only "fake" accounts exhibit this behavior, I have never heard of this behavior. I suppose it's somewhat possible that there is some fishy data stored with these accounts, but offhand I can't think of what it could be. Maybe you could go into phpMyAdmin and take a look at one of these problem-causing fake accounts, and compare them with a normal real account, and see if there is anything in the customer data that looks like a script (HTML tags) or something else odd. Are you sure it's only fake accounts, or are those the only ones you tried this operation on? This is only selecting the account, and you haven't pressed Delete yet?
  9. MrPhil

    Removing fake customers

    Exactly what osC version? What PHP version? Yes, you should worry about such errors.
  10. This might have something to do with an old problem about MySQL changing precedence of certain operations, so that 'p' is unknown at that point (search this forum for 1054). That might be a fairly simple Band-Aid fix you could do (it was years ago... I don't remember the particulars). Anyway, I agree with Jack that you're wasting your time trying to patch up such an old version of osC to work with (more) current MySQL (and PHP) versions. You'd be much better off biting the bullet and moving to osC 2.3.4.1BS "Frozen". Unfortunately, if you have a lot of code customization, you'll have quite a bit of work ahead of you, but in the long run it will be worth it. Converting even an ancient osC database to run on Frozen isn't a terrible amount of work, but you will then have a vanilla shop.
  11. MrPhil

    Removing fake customers

    Well, the idea is that if the spammer knows that you will be previewing their mailings and weeding out spam (for a while, anyway), hopefully they won't sign up in the first place.
  12. MrPhil

    Removing fake customers

    Fake accounts are usually opened for the purpose of either spamming you, or using the store as a platform for spamming others via tell-a-friend, messaging, etc. Thus, it is good to keep them under control. I don't know if removing a country from the list will do any good -- they'll simply pick another country. In the (presumably made up?) example, they would just pick some other random country than Angola. That would be like playing whack-a-mole until you're down to one last country. I suppose you could do something to publish a list of countries you will (or won't) sell to, and silently automatically trash any account signed up for the banned countries. The fake account will simply vanish into the memory hole. Something more productive might be to put new accounts' outputs (tell-a-friend, etc.) on preview of some sort, where nothing actually goes out until you've reviewed it. That's more work for you, of course. To avoid running afoul of privacy laws, you'd probably have to tell the "customer" that you're reading their posts and mailings, and even then, there might be trouble. However, it might be enough to discourage those looking to abuse your system (unless you simply turn off t-a-f etc.). Forums and blogs face the same problem. If you can't stop them at the border (CAPTCHAs, etc. on signup to stop bots), you have to monitor what they're outputting to others and clamp down if they appear to be abusive. At least, on a forum or blog posting no one can claim a right to privacy in their communications. Almost anything you can do to stop spamming is going to create more work for you or more work for a real customer. Welcome to the Real World. Can tell-a-friend, etc. be disabled until a customer has purchased something? Can tell-a-friend mailings be checked that they have a legitimate link to one of your products or categories, otherwise they're silently trashed? Just some ideas.
  13. First of all, you installed the official osCommerce, which is way obsolete and won't run on modern systems. Your system does not have the MySQL library for PHP use (actually, it's deprecated and therefore almost unusable), but will have the MySQLi library. The only usable osC, 2.3.4.1BS Frozen (a.k.a. CE), is available on GitHub (see links below). I would avoid "Edge" unless you're a skilled programmer and like working on the bleeding edge.
  14. MrPhil

    Display map to track shipment progress

    How much package location information does a shipper provide (for free), and do they have limits on how frequently a given package may be queried, or an IP address (your store) can do any query? I wouldn't be surprised if any shipper has limits to prevent abuse (e.g., live tracking of your package, with your phone hitting their server every second). Latitude/longitude is nice, but city/state + delivery status would do. Even if the shipper's site is not set up for a map, as long as information is consistently presented it should be possible to scrape it off their site and present it to a mapping app. An alert (text or voice) to the customer phone that the package has been left at the address might prove very useful in this age of increasing thefts from the doorstep. If a shipper charges extra for advanced tracking, and the customer requests it, that fee could be passed on to the customer at checkout.
  15. MrPhil

    Cart loses products seemingly randomly

    Yeah, I'd check if current versions use a wider database field for session information than your (old) code does. If you've been keeping up on changes for new PHP levels and security issues, you can keep running as you are, although the fact that you're having this cart problem suggests that you may be overlooking some changes. It may be time to step back and consider whether this is a good approach, as opposed to moving to the current release and building something resembling a template over it. Let others do the work of keeping up with the basics, while you concentrate on code to make your store stand out and improve the UX. It could well be less work overall to copy your changes to a new release than to constantly patch an old base. For example, did you do a lot for Responsive/Mobile-friendly? That's built right into "Frozen". What you have to keep in mind is that the longer you stay with an old, old base, the less help you can get from this forum and the more you're on your own. You've essentially made your own fork of the product. Whichever way you choose to go, good luck and best wishes.
  16. MrPhil

    mutliple domain names? redirects?

    If it's possible one way or another to have several names pointing to the same site, where %{HTTP_HOST} is various strings, it might be interesting to feed %{HTTP_HOST} to the program (as URL Query String). The value would be used to override the domain name used in configure.php settings, making it look like a number of domains are hosting this store. Has anyone seen something like that? Offerings might be adjusted depending on "who" is hosting the store. I would be worried that some bad actor could point a random domain to your store and somehow hijack it. That might be prevented by having a hard coded whitelist of domains allowed to do this.
  17. MrPhil

    mutliple domain names? redirects?

    The domain names in the configure.php files are used for generating outbound links from the store, and perhaps a few miscellaneous items such as canonical tags. They do not change what name the server it's running on sees or uses. If you have a store running under a given domain name, and you want to change that domain, you need not only to change the configure.php entries to the new domain, but also register the new domain and point it to the server (it could be on a new server). If you are looking to redirect (point) another domain to this cart (as an alias?), you can certainly do a redirect from wherever the other domain is hosted (a redirect within .htaccess is one way). However, you will have some problems, as the store will still be hard coded to the first domain's name, and produce links, etc. under that name. If you are looking to change the name of the store, but allow it to be accessed under an old name, that can be done, too. Perhaps you could explain in detail what effect you're looking to achieve here?
  18. MrPhil

    Hack attempt - is there a way to prevent this?

    This is only appearing in this one order's data, and is not in everyone's (or in your osC code)? They are definitely trying to provoke your server into running what's presumably some nasty script code, but it's being disabled by osC. If it's just this one guy, cancel any payment made (so you're not in legal trouble for keeping payment and not delivering) and cancel the order, and fuhgettaboudit. Unless you want to jump through the hoops of reporting them to the payment processor. If everyone is seeing this, you've got some cleanup to do and security holes to patch. They're trying to inject and run some script code that creates more script, invisible images, and input field elements on your page. Some server in Guyana (they have computers there???) is involved (perhaps to load more malicious code). I haven't dived more deeply into it, but it looks like something you don't want running. Just be thankful it was (apparently) disabled before it could do the nasty.
  19. MrPhil

    Cart loses products seemingly randomly

    13 years? If you're still using a 2005 vintage osCommerce (probably osC 2.2 MS2), it wouldn't be surprising if your host has upgraded PHP or made some other change that is making an old store unstable. What version are you using, and what is your host's PHP version? The current (and only supported) version of osC is 2.3.4.1BS "Frozen". Note that the official osC 2.3.4.1 release does not work with current PHP releases.
  20. Sorry, I'm not familiar with the UPS add-on. Now, why are they sending the address to UPS in the first place? I assume that it's to get a rate quote. If the address is only off a little, the error in the rate charged may be small, but if the customer gave the wrong state by accident, that could be catastrophic. What if they want the package sent to Carlsbad, NM instead of Carlsbad, CA? Watch out for auto-completion giving a wrong state! If UPS returns a flag that such-and-such a field in the shipping address appears to be in error, and the customer is still there in checkout, it should be possible for osC to present the shipping address and ask the customer to check/update it. I'd be surprised if it didn't do that already, but if it doesn't, it should be possible to add that to osC. If you managed to turn off the address verification, what would be the expected results? You would still manually fix the address before shipping out the package, but would you have quoted the wrong shipping rate? I think you may be fixated on the wrong thing (turning off verification, rather than letting the customer fix an incorrect address).
  21. MrPhil

    New UPS XML Shipping Module available

    Hope this isn't too late... it sounds like you may have the CE/Edge/Frozen version installed. This is GOOD. However, the code has been updated, replacing $HTTP_POST_VARS by $_POST and module name defines (FILENAME_MODULES) with hard-coded strings. The code is functionally identical (works the same way). If you are installing this into an older osC, you may need to back out those updates (change $_POST back to $HTTP_POST_VARS... you may be able to leave the hard-coded module name). Be careful if installing older add-ons into a new osC or vice-versa. By the way, PHP 5.3 is terribly ancient. Any up-to-date system should be at PHP 7.1 by now (the earliest supported PHP version). 5.6 and 7.0 are somewhat tolerable (they went out of support a week ago) but should be planned for replacement soon. Incidentally, the CE/Edge/Frozen version will run on PHP 7.1 or below (PHP 7.2 may need a few fixes), while the "official" 2.3.4.1 won't run reliably at that level. I won't swear that CE/Edge/Frozen will still work properly on PHP 5.3 -- it might.
  22. Maybe a better approach would be to leave the UPS interface alone, but validate the address before you send it to UPS? Unfortunately, it sounds like a manual operation on your end right now. If it can be automated (USPS, Google Maps?) you could alert the customer right then and there that the address looks "off" -- please check your entry and update if necessary. As a bonus, a verified address might also make available additional address information such as county and inside/outside city limits, useful for determining sales tax jurisdictions and thus, rates. Does UPS bounce back the bad address right away, while the customer is still in the checkout process? At least, the customer could correct the address themselves at that point (new code needed on the osC end). I think that in general, address validation during checkout would be quite useful.
  23. Why would blocking the reading of PHP files have any effect on JS and CSS files? The point of that segment is to keep people from looking inside your PHP files. Hasn't Apache 2.4 been around for a long time now? I would have thought this would have been seen (and sorted out) long ago. Perhaps there were some outdated commands such as phpflag, phpvalue, or options?
  24. So what happens if you remove address validation, and UPS is unable to deliver? It seems like that would be a major inconvenience for all parties. What's the downside of having UPS verify that they can deliver to that address? They're going to know the customer's address anyway, so it's not like they're being let in on a secret.
  25. Is the admin side under SSL and the public side not? Is the admin side under password protection? I don't think either of those should bar access, but anything's possible. Are the problem .css and .js files on YOUR site or are they remote (e.g., the Bootstrap server)? Can you bring up some of the blocked files in your browser? That would be like on the shop side, so it may not tell you anything about the admin side problem. Usually it turns out to be a problem with incorrectly set paths in the configure.php files (you did update the admin copy, too, right? And be careful not to mix up the two -- they're different).
×