Forum Moderators: phranque
My webhost says it is likely that the customers are using older browsers and nothing can be done because their script that runs the FormMail is using the 'latest mods' and the only remedy is to get the potential customer to upgrade their browser (yeah, right!).
Can anyone throw any light on this problem - is there a solution? (change web host?).
Thanks,
Namniboose
>Can anyone suggest a good question to ask the host company which might throw more light?
Why are you idiots using port 5522 for connections to the secure server instead of port 443 like everybody else in the world? I might leave out "idiots" in my question but I'd probably add, IT'S CAUSING ME PROBLEMS AND COSTING ME SALES! FIX IT!
and then maybe refer them to this:
same problem [swelltech.com]
I recently set a 2nd form on another website and was given the port number 8351 for the secure server.
Both sites are hosted on a virtual server - is that why I am being given non-standard port numbers? Can I just use the standard port number 443 without them allocating it?
namniboose - 5522 is not the port number, it's your account number. If you are still hosted where you used to be, they use a standard SSL set-up and shouldn't cause any problems.
When I asked about using the standard 443 port, tech support said 'no, you'll need to stick with the port number we've assigned you', which indicates that they don't use 443.
Maybe it is simpler for a clueless hoster to set their secure sites up with non-standard port numbers, especially in a virtual hosting environment. But that's not really a good argument for really doing so. In fact, it looks like yet another reason to avoid virtual hosting. In theory, virtual hosting should work just as well as IP based hosting, in practise it translates to suboptimal service almost every time.
Can I just use the standard port number 443 without them allocating it?
It's unlikely that this will work. Your host's secure server will need to be monitoring port 443 in addition to 5522 and 8351. Simply surfing to their secure server without a port number (using the default 443) may answer this question for you.
Bird, yes it is in fact the port number as well. However I think the issue was been pointed at the SSL config, avoiding the fact that she installed her own script instead of using the one supplied by the host, which I have never had a problem with in 3 years and fill about a dozen orders in this manner weekly. Without knowing how this custom script is config'd, I wouldn't venture to guess at other possible causes.
My experience is that this host* consistantly upgrades their servers and script versions to meet security demands and delivers next to flawless resources, so I would not label them as "clueless" :)
The virtually hosted secure server , BTW, is a free service and offered as a convience. It is recommened that biz sites use their own professional secure set-up and maintain their appropriate certificates through the various security companies available for this.
* if namniboose is still using the same host as before.
As a principle, I can't think of any good reason to use non-standard port numbers for anything on a site that is meant to be accessible to the general public. There's also no necessity to do so, unless it is supposed to make things easier for those setting it up (which may be an acceptable reason when it's really a free "bonus feature").
Anothher question that somewhat tickles me is: Why in the world would anyone need a ssl connection just for posting a message or two to a formmail script? Unless you collect cc numbers this way, there's really no point to that.
I believe I have my formmail configured correctly - it works most of the time (as far as I know). I am troubled by those 3 instances in which it didn't work, however.
As I said earlier in my post, the message reported to me by last customer who couldn't send the form was 'This tunnel port is invalid. The administrator is not allowing tunneling on this port' which indicates that the problem isn't with the script.
Bird, I'm not quite sure who this refers to:
'Why in the world would anyone need a ssl connection just for posting a message or two to a formmail script?'
but, for the record, I am taking credit cards!
Well this doesn't help solve your mystery namniboose, but "stuff happens" LOL
I've had my site hosted by 4 different servers and all of them periodically report mysterious 404s, script failures and denial of services. Every so often I see "file not found" in my error logs when the file is where it's supposed to be and the code is correct - go figure. Occasionally, I see a script failure in the error log as well. Did this script actually fail when it works thousands of other times? Or was the users's browser non supportive, thus not letting the script complete? Or how many other arbitrary reasons for the report - if in fact the report is accurate?
If your script is called via an html form, is this form code supported across the board? How about for MAC browser versions? My site code validates at W3C without error, but a few of my utilities do not work for older MAC browsers.
My Analog stats report about 300 failed requests from Yahoo! each week. Well my URL is correct at Y! so go figure once again, and I'm certainly not going to worry about it considering they supply 11k of sucessful weekly referrals.
I would (if I were you) be alarmed if you saw a consistent string of script failures from different IP address for any considerable amount of time. And the more detail your log analyzer software reports, the better you can follow this. The Webstats report that our server supplies us is, once again, offered as a free, helpful resource but certainly not the professional level necessary to gain insight into eCommerce.
If you're collecting the credit card data through formmail, then the air of security provided by the SSL connection may be misleading. I hope those e-mails it generates aren't going off-site? Even if they stay on the same machine, I'm not sure if I would like my data stored in someones inbox on a shared server without any further protection.
If you think you really need SSL for that script, then you seem to have three possibilities:
- Live with the fact that people behind firewalls may be unable to reach it.
- Find a hoster offering SSL protected scripts on the standard port per default.
- If I understand keyplyr correctly, then you could get your own certificate, and configure a more standard SSL setup with the same hoster on your own.
What do you mean by 'I hope those e-mails it generates aren't going off-site?'. The emails are presently sent to my AOL inbox (yes, I know AOL sucks etc).
Is that MORE, or LESS secure than having it sent to an address associated with my URL on a shared server?
Well I now have some new information to think about - thanks for that keyplyr and bird.
This means that you're transmitting your customers financial details over the net without any protection. That's definitively not recommended, and may make you liable in case anything goes wrong.
Sending it to an address on the local machine is marginally better, but still leaves the information available in plain text in case the box is cracked. What you should do is use a shopping cart script that encrypts the sensitive information before either sending it elsewhere or storing it to disk.
Do you mean sending it to an email address associated with my domain name?
'What you should do is use a shopping cart script that encrypts the sensitive information before either sending it elsewhere or storing it to disk'
I need to have the credit card details myself. How does 'storing it to disk' work?
Do you mean sending it to an email address associated with my domain name?
The domain name has no influence on security. As soon as the data leaves the machine (where it was sent through an encrypted SSL channel), it will be out in the open for those who know how to grab it.
I need to have the credit card details myself. How does 'storing it to disk' work?
Well, whatever you do, unencrypted credit card data shouldn't be left unattended. Neither by sending it through public networks, nor by saving it to a file on a shared server. What's the point of showing the customers that nice lock on the browser window, if you then drop all security measures after you have gained their trust?
I quite agree Bird. I thought it was being sent securely! I do delete all credit card info from my inbox and filing cabinet as soon as I have received it but I can see that I'm going to have to change my system completely.
Can anyone suggest a good way? Know of any good encrypted shopping cart scripts?
And what do you mean by 'saving it to a file on a shared server'.
Thanks for your help,
Namniboose
I assume you know what "saving to a file means"... ;)
The machine where you site resides is probably used for many other sites as well, which makes it a "shared server". If you save files from a CGI script, then those files will be owned by the user ID that runs the web server software, which normally is the same for all sites. In other words, any other user on that system might be able to read it again with a CGI script of their own.
There are ways for the hoster to make this difficult, but it's almost impossible to stop completely. There are also ways to change the user ID of the file to that of your own account (through cgiwrap), but this rquires that the hoster offers the cgiwrap service, and you need to configure the script correctly to use it. Even then, the machine can get hacked, so that's not really a secure solution either.
So the general rule is not to store unencrypte financial details on a networked machine, let alone transmit it across unsecured connections, and e-mail is unsecure almost by definition.
I know the info is sent to the shared secure server but does it stay there after it has been sent on to my email address?
Note:
I reserve the right to ask ignorant questions in the pursuit of wisdom ;)
my advice:
option 1 - modify the formmail script to use PGP to encrypt card and order details before sending them anywhere, whether to a mailbox on your domain or to your AOL mailbox. when you have downloaded the emails, you unencrypt them on your computer. if you don't know how to do this yourself, hire someone in.
option 2 (preferred) - use online card processing from 2checkout / worldpay or other online payment system. they handle the security and the orders are processed for you, saving you the time and effort of having to do it yourself. yes it might be more expensive than processing the details yourself, but look at the figures - if you currently pay 3% through your bank merchant account and 5% through an online processing company, the additional cost is just 2% - a mere $0.20 on a $10.00 order (this is just a very basic example and you'll need to look at the actual costs properly).
it could be very worthwhile paying that little bit extra to know that your customer orders are being taken and processed securely. the extra costs are fairly low and can easily be passed on to the consumer by changing your pricing very slightly. you could choose to swallow the additional cost yourself - the time saved in manually processing orders can give you more time to promote your site and generate more sales, or maybe to take a couple of hours a week to yourself to relax etc.
there may also be trust factors involved - i generally don't trust sites using plain SSL as too many of them use little or no security beyond the initial HTTPS page. i would rather purchase from a site using a well known payment solution provider, even if it costs a little bit more, as the security measures are far greater than through most SSL based sites.
Encrypting the details sounds feasible.
I am familiar with 2checkout.com - I set that up for a friend but she doesn't like having to leave $600 in the account the whole time.
The other thing is that for the vacation rental business, I do want to have the actual credit card details myself for 2nd payment and then for damage deposit.
Is there some sort of shopping cart script which would send the c.c. details to me encrypted? And then would I have to decrypt them with some other software? :o
Note: I reserve the right to invent new words until I know the correct term.
- get a personal email certificate through Thawte (or any of the others.) This encrypts your email. They are a bit ambiguous about the nature of how this service can be used, but the only people who will be able to unencrypt the data is you or whoever you give your 'key' to. Sorry, I can't/won't give any advice on this because of liability issues, but it is an option you may wish to explore... it's free - LOL
[thawte.com...]
I WILL CHECK IT OUT :)
THANKS!
'I think port 443 is for dedicated certificates which would cost you 4-5 hundred dollars'
Do other webhosts allocate port 443 for SHARED secure servers?
Unfortunately, I no longer take tech support's answers too seriously.
We were originally hosted by Verio and when I looked into SSL and a digital certificate it was exhorbitantly expensive for a small business.
I decided to go the cheap way, not really knowing the difference.
I need a reliable webhost with good tech support that uses port 443 for secure servers.
I haven't had any problem being hosted on a virtual server, probably because the host has zero tolerance for spam (which I found out when someone spammed from our formmail!).
Any ideas?
They think? :o
Certificates are issued per domain, not per machine or port number. That may be what they wanted to tell you, but it comes through a little garbled.
Do other webhosts allocate port 443 for SHARED secure servers?
I don't use the feature myself, but with my hoster, a shared ssl setup would result in an URL like this: "http://ssl#.hoster.com/username/....". In your situation, the /username/ distinction is replaced by varying port numbers, which is exactly what is causing you trouble. In either case, if you want ssl under you own domain, then you'd have to buy your own certificate, which may or may not be worth the cost.
This option is not available for all accounts, the cheapest combination costs a total of $28.- per month. On the positive side, it's really one of the most competent hosting companies around, and has collected praise high and wide in other threads around here.
