I was working with a client eCommerce site the other day, and a really concerning problem popped up. On the very last step of checkout, when you press the very final button to submit the order, the browser would pop up a security warning telling the user that the page was secure, but the data being sent was not.
Not exactly something someone wants to see when buying stuff online.
A little digging revealed the browser wasn’t being paranoid, it was doing it’s job. The page it self was legitimately secured, but the action url of the form was submitting to a non-secure url.
I am fairly familiar with this particular cart, but after way too much digging I was unable to find code in which to change this url. A submitted a support request, but they were very unhelpful and blamed my custom modifications to the cart (no way). So… I needed a better way to force that darn url to be secure.
Force it with JavaScript
It’s not the perfect solution of course, this really should be done at the core cart level, but sometimes you just need a damn solution so you can get on with your life. Here is how I did it with jQuery JavaScript:
$(function(){
var $form = $("form#specificForm");
var newAction = $form.attr("action");
newAction = newAction.replace(/http/,"https");
$form.attr("action", newAction);
});
Plain English:
- Cache the selector since we’ll be using it more than once
- Set a variable equal to the action url
- Replace the “http” part of the string with “https”
- Change the attribute on the form
Does the trick…
And then you apply the script using greasemonkey?
No it’s included just as any other JavaScript might be added to page, so it affects everyone.
One quick note about it. Not sure if jQuery $() does a document ready check, but this must run AFTER the form has rendered. So don’t include this at the top of your page without using $(document).ready(..function..).
Nice post, Chris!
I think it does. As far as I know the $(function() part is shorthand for the document ready stuff.
Yes the javascript wrapped within $(function() { … }); is ran after the page has fully loaded.
Andrew
No, it does not run when the page has fully loaded, it runs when the DOM is ready for manipulation (which, in some situations may coincide with the onload event). Images / iframes / scripts / stylesheets don’t have to be loaded for this to run.
Nice little workaround, but what is the solution for people with Javascript disabled?
There isn’t one, that’s why it’s not perfect. The perfect solution is getting the dang cart to put the correct URL in there!
True. What cart is doing this, because the support sounds kind of bland.
If its a php cart maybe you can wrap the action (or maby the whole ) in a function that does a server side search/replace.
This way you don’t have to force your users to have javascript enabled.
(or maby the whole < form > tag )
This could be archived by editing the cart software itself but I’m assuming that Chris didn’t want to search through the reams of code it takes to create a decent feature rich shopping cart. This is by not means a perfect solution but is a quick workaround that was worth the mention here.
Andrew
you should change it to:
newAction = newAction.replace(/http:/,”https:”);
so that existing secure forms won’t break into httpss:
:)
Cool thanks for the improvement Nathan. Fortunately with this form it is targeting a specific form by ID so it won’t be a problem, but I updated anyway.
Remember if anyone copies and pastes this, change those curly quotes back to straight ones in the code.