looks to me as if many of the links and none of the images in the templates or the QC module have https in their URL.
Well it is not in QC module because it does not work properly when it is deactivated. Next to see if it is in the TC area or not by uninstalling all the modules.
I deactivated all TC modules (and the freecap, maintenance, etc) and your system does not function properly (using your purpiclous template or the default). You will notice if you log in and then hit 'place an ad' again or 'modifty an ad' without proceeding it asks you to log in again (i.e. you get thrown out). Make sure the https all works properly on the default template first (i.e. a default system with no bells and whistles). Then add the modules back in. I am not saying there may not be problems further down the line (probably not) but at this point you have a problem with your base system / hosting setup. Talk to your hosting provider using Mike's comments first. You should also raise a ticket with 68C after asking your hosting provider for assistance as to why the SSL is not behaving normally. I will move this thread into the technical support part of the forum as it it is not specific to TC and its not a quick checkout issue either from what I can see.
Yes, exactly. If the address bar in a browser has "https" set as the protocol but there are "unsecure" elements on the page, the "lock" in the status bar in the browser will show a warning (an exclamation, crossed-out, etc.).
Also, just to clarify..... An anchor tags "href" value can be "http" but the elements included within a page that has "https" in the address bar of the browser must be secure.
The SERVER IS NOT USING PORT 443, even though the URL says, https. That is why the base href is set to http: and NOT https. That is why FF redirects to http: instead, because it is built into is rendering engine to go back to standard http: if it is not connecting with port 443. This is also why the base href is also rendering to the standard http: as well. So all relative links are set as standard links/source. ONLY the links that are either hard coded (e.g. https://...) or use the Smarty URL {$smarty.const.URL} which renders as http://yourdomain.com are standard links. If you go ahead and try to login with a bogus username and password, you should get a warning (if your preferences/properties are set in your browser to warn you) that you are about to send a form to a non-secure server. I believe the handshake (between server and the client computer) for the SSL protocol is what is failing. It is the completion of a successful handshake between them that then completes the TSL protocol (e.g. proper port, certificate, hash, key, layer, etc.), if this fails one of two things should happen. Either a FATAL ERROR or fallback to non-secure protocol on port 80. In this case it appears to do the fallback to a non-secure protocol.
Right, that is absolutely correct. It is only items, if you ARE in secure mode, that the client is requesting from a source that is NOT a secure request.
So what would happen if all of the files for 68C were copied into the web servers specific secure directory instead of trying to fool it by simply changing the http to https?
Dunno if the host offers that feature. In the past even when a secure directory was available, I just went through a page's source to make sure that each element had an absolute path including the https. However, that SHOULDN'T be necessary if the base tag's value is set properly. If the secure URL value has been set properly in Main Settings, I'm wondering if the base tags value has been hardcoded in the template file?
I don't know about rackspace, but in most hosting services that I've seen that have a separate directory for "secure" it was actually just a symlink for the directory. I'm not really sure how that works or why it is even done like that. In this case, with the template now on a 68 Supplied template, the links that are not secure are relative url links which are based off of the base href which is not set to secure, because the server isn't using the secure port as I mentioned earlier. The clickable links that are set to https: are that way because they are using the smarty URLS which renders to what is set in the admin as we know, which is now https:
In his root space there is no httpdocs or secure directory. Just public_html . I think the advice should be for him to move to Hostgator. It will take longer to cajole his current hosting provider into finding out what is wrong than to change.
Blair - its the default template and no modules whatsoever. It throws you out from FF after logging in and then trying to place an ad.
No matter what modules, images, templates, etc are used.... as long as the markup received by the browser has everything set up correctly, then there should be no warnings with the SSL cert. EDIT: However, by tracing the problem backwards (viewing the page source and correcting problems from there), corrections may need to be made in modules or templates
Right and in looking at the page source, it clearly indicates that the issue is the fact that even though the URL (in the browser) is set to https, the SERVER is not using the secure port, 443. All of the URLs in the page source are set the way they are supposed to be, either hard coded or following the relative path based on the base href.
So the problem appears to be solved. In the layout.tpl file there's a conditional to push to port 443 if the page isn't, so in the else we force https there, and that did the trick. It's a hack, I know, but let me know if there's any downside to the rest of the code if we keep this. Thanks for all your help.
Right and when you log on and then try to place a listing does it still throw you out? If it doesn't then try and install the image uploader and quick checkout module.
I'll bet the problem is caused by images on the page not being located on a secure server. Maybe icons?
