Hi,
I am using 1.4.9.6 and even though I had an installed SSL certificate the store was not automatically switching to HTTPS during the checkout.
So I forced HTTPS in my ".htaccess" for EVERYTHING and the checkout is now working fine BUT for some reason the Contact Form complains about sending unsecure info on a secure page (which is OK because nobody cares about that in a contact form) BUT it no longer sends me the contact request email like it did before in unsecure mode.
Has anyone run into this problem before? Even if you have not could you at least point me to the php file I need to debug ? Or could you reply back with the ".htaccess" code that will unsecure the contact form while securing everything else.
Thanks,
Phil
I am using 1.4.9.6 and even though I had an installed SSL certificate the store was not automatically switching to HTTPS during the checkout.
So I forced HTTPS in my ".htaccess" for EVERYTHING and the checkout is now working fine BUT for some reason the Contact Form complains about sending unsecure info on a secure page (which is OK because nobody cares about that in a contact form) BUT it no longer sends me the contact request email like it did before in unsecure mode.
Has anyone run into this problem before? Even if you have not could you at least point me to the php file I need to debug ? Or could you reply back with the ".htaccess" code that will unsecure the contact form while securing everything else.
Thanks,
Phil
When going to a contact form you should NOT be on SSL. Your forced SSL in .htaccess is what is causing this issue. If you actually go into your control and fix the issue to begin with you can us the control to .....you guessed it...."control" which page uses SSL and which does not lol.
I'm sorry, can you explain where exactly we can control SSL for each page?
I don't have any settings for this in control panel, there's only one to control ALL SSL on the site.
I'm forcing SSL on my "account" section, because I don't think it's a good idea for customers to enter their login/pass unsecured. But this causes a problem, as it makes the Contact page SSL if they're logged in.
How does one; "control" which page uses SSL and which does not lol." ?
I don't have any settings for this in control panel, there's only one to control ALL SSL on the site.
I'm forcing SSL on my "account" section, because I don't think it's a good idea for customers to enter their login/pass unsecured. But this causes a problem, as it makes the Contact page SSL if they're logged in.
How does one; "control" which page uses SSL and which does not lol." ?
You might want to review the bottom pair of links in http://forum.opencart.com/viewtopic.php ... 80#p439397 -- you already understand it well enough that the overview will perhaps help you to refocus. There is essentially "one page" generated as the next iteration of cyclically reshaped index.php in the OC root, and separately likewise of its counterpart in /admin/. Some aspects are not to be protected by SSL. Protecting admin can bring it to a halt. Images can be made (in)accessible by how they are handled. The links are good reads.
Thanks for the links, I'm aware of the Config file...
but in retrospect, what's the reasoning behind this comment?
"When going to a contact form you should NOT be on SSL"
Email is private communication crossing the internet,
between a lawyer and his clients, for example.
Considering Google is encrypting ALL SEARCHES these days (and Gmail always was HTTPs)...
I really don't understand the logic to leave that door open.
Seriously, someone please explain...
I was hellbent on fixing this issue, why is that a mistake?
P.S. And this comment: Protecting admin can bring it to a halt.
That's gotta be wrong my friend, since when does anybody NOT put SSL on their password protected areas???
but in retrospect, what's the reasoning behind this comment?
"When going to a contact form you should NOT be on SSL"
Email is private communication crossing the internet,
between a lawyer and his clients, for example.
Considering Google is encrypting ALL SEARCHES these days (and Gmail always was HTTPs)...
I really don't understand the logic to leave that door open.
Seriously, someone please explain...
I was hellbent on fixing this issue, why is that a mistake?
P.S. And this comment: Protecting admin can bring it to a halt.
That's gotta be wrong my friend, since when does anybody NOT put SSL on their password protected areas???
Well, one of us has said not to apply SSL to a contact form and one of us has said not to apply SSL to admin. Neither of us is alone in saying so, but we're admittedly both inexperienced. If you bother to ask the free Search button top right on the page for the combination SSL admin you will find an array of posts whose upshot was that SSL brought admin to a halt, and you'll also locate where one of the tutorials, Daniel, Qphoria, and others say not to apply SSL to admin or to the entire storefront. I would imagine that a similar outcome would be had by a free Search for comparable context of a contact form. One wonders what we would have said if we were experienced.
As for "where" to control SSL, in admin System / Settings / [Store] / Edit / Server there is a checkbox to turn it on and off at large, and in each config.php file there is the HTTPS section for setting http :// or https :// for whether it affects portions (typically server and image, but not admin, and not particular pages) of OC. Those aspects are covered in the tutorials already cited and linked.
As for "where" to control SSL, in admin System / Settings / [Store] / Edit / Server there is a checkbox to turn it on and off at large, and in each config.php file there is the HTTPS section for setting http :// or https :// for whether it affects portions (typically server and image, but not admin, and not particular pages) of OC. Those aspects are covered in the tutorials already cited and linked.
Thanks for the reply @butte... I don't think adding SSL to the entire store is a good idea...
that just slows down your front page (which matters to Google to these days).
The contact form issue could go either way, but I think it's common practice on most professional websites to secure any customer communication through their websites... if something WERE to happen (customer decides to email you their credit card number without previous warning), that distinct lack of security can make your company liable.
Regarding the admin... OpenCart doesn't store any information in the customer admin that's terribly sensitive (addresses, that's about it)... the problem arises with the unsecured LOGIN.
Many people use the same login for various accounts... so if a hacker noticed your unsecured admin, he could sit and collect customer data (email address and password). Then it's as easy as taking all the Gmail accounts and trying the stolen password on them.
Once a hacker has access to your Gmail account, he can search for all your account registration / welcome emails over the years... then try the email/password combo on those (god forbid the password is IN those emails)... for example, gaining access to your GoDaddy account and changing the registration information... essentially locking you out of your own website ownership.
You could easily lose your business in an afternoon, with an unsecured admin...
there's people out there that do this stuff for a living.
This is a very interesting read... happened just last week:
http://thenextweb.com/socialmedia/2014/ ... -username/
that just slows down your front page (which matters to Google to these days).
The contact form issue could go either way, but I think it's common practice on most professional websites to secure any customer communication through their websites... if something WERE to happen (customer decides to email you their credit card number without previous warning), that distinct lack of security can make your company liable.
Regarding the admin... OpenCart doesn't store any information in the customer admin that's terribly sensitive (addresses, that's about it)... the problem arises with the unsecured LOGIN.
Many people use the same login for various accounts... so if a hacker noticed your unsecured admin, he could sit and collect customer data (email address and password). Then it's as easy as taking all the Gmail accounts and trying the stolen password on them.
Once a hacker has access to your Gmail account, he can search for all your account registration / welcome emails over the years... then try the email/password combo on those (god forbid the password is IN those emails)... for example, gaining access to your GoDaddy account and changing the registration information... essentially locking you out of your own website ownership.
You could easily lose your business in an afternoon, with an unsecured admin...
there's people out there that do this stuff for a living.
This is a very interesting read... happened just last week:
http://thenextweb.com/socialmedia/2014/ ... -username/
It's an ongoing problem, of course, that nothing is completely invincible. The OC forum posts still suggest that as numbers go, log-in logging has been a minor or at least infrequent problem if and when known, in comparison to the major and increasingly frequent problem of traditionally invasive hacking via ftp or http.
Some of us disarm or disembowel password reminders. Some of us password protect admin log-ins and moreover restrict addresses allowed to reach both the server challenge and the log-in screen beyond that. Some of us assign usernames and passwords and moreover allow sharply limited attempts. Some of us utilize firewall or other software that effectively objects to code patterns that are known or even seem to be malicious for the sake of injecting, sniffing, snooping, or *ing. Some of us pay strict attention to logs for log-in screens, delays till next stops, and related details that will suggest when to prevent recurrence. Some of us exclude vast address swaths that are populated by hackers and spammers but that are moreover undenizened by anyone who would ever be a bona fide registrant, customer, or wanted visitor. Some of us strictly avoid visibly having such prizes as various kinds of information, attractively distinctive or original names, and such. Some of us set traps and sandbag trespassers. Some of us strictly avoid visiting various kinds of websites whether we would ever log in or not. Perhaps most of us who undertake such measures (among yet others) sleep well, knowing that untoward probabilities will remain above zero but low nonetheless.
It is also instructive to watch unaware live hackers in "real time" live performances. How they think is interesting; and often not very bright. Mere automated hacking is overall easy to preclude or obviate, even if inconvenient for non-hackers, but the live ones are worth watching when opportunity presents itself.
As is well known the only way to come close to securing a computer completely is to unplug it and shower and sleep with it. Short of that, many of us assess odds as well as mentalities, choose our battles, hopefully wisely, give the odds our best shots, and even maintain ready to run mirrors. It never stops, they're globally strewn; overall they don't often win.
Some of us disarm or disembowel password reminders. Some of us password protect admin log-ins and moreover restrict addresses allowed to reach both the server challenge and the log-in screen beyond that. Some of us assign usernames and passwords and moreover allow sharply limited attempts. Some of us utilize firewall or other software that effectively objects to code patterns that are known or even seem to be malicious for the sake of injecting, sniffing, snooping, or *ing. Some of us pay strict attention to logs for log-in screens, delays till next stops, and related details that will suggest when to prevent recurrence. Some of us exclude vast address swaths that are populated by hackers and spammers but that are moreover undenizened by anyone who would ever be a bona fide registrant, customer, or wanted visitor. Some of us strictly avoid visibly having such prizes as various kinds of information, attractively distinctive or original names, and such. Some of us set traps and sandbag trespassers. Some of us strictly avoid visiting various kinds of websites whether we would ever log in or not. Perhaps most of us who undertake such measures (among yet others) sleep well, knowing that untoward probabilities will remain above zero but low nonetheless.
It is also instructive to watch unaware live hackers in "real time" live performances. How they think is interesting; and often not very bright. Mere automated hacking is overall easy to preclude or obviate, even if inconvenient for non-hackers, but the live ones are worth watching when opportunity presents itself.
As is well known the only way to come close to securing a computer completely is to unplug it and shower and sleep with it. Short of that, many of us assess odds as well as mentalities, choose our battles, hopefully wisely, give the odds our best shots, and even maintain ready to run mirrors. It never stops, they're globally strewn; overall they don't often win.
Who is online
Users browsing this forum: No registered users and 111 guests