Login Suddenly Results in 404 Page

[DrByte]

Have you considered the fact that if I fill in your login form while I'm on your home page, the data is passed unencrypted because your home page is not an SSL page?

Careful about that.

The POST is sent to the URL specified in the <form>'s action= parameter ... and if that action= parameter is an https URL then the POST is indeed sent encrypted. It doesn't matter whether the source page on which the form was displayed was in https or not. The encryption is determined by the action= URL.
It's a common misconception. But the padlock only assures that the content being *displayed* was delivered encrypted over SSL.

everything was working fine, tested the site fully,... went live, and now all of a sudden, no one can login

So what's different between before vs after?
What exactly did "went live" mean? What did you "do" to "go live"? Did you simply pour a few pints and say "okay we're live", or did you do something to the server, move files around, change hosts, upload something, what?

[lat9]

Thanks for setting me straight, DrByte; apologies for the misinformed post.

[lat9]

OK, it's not just a problem with the login-form-in-header ... I clicked on the Register button in your header, disabled javascript in my browser and clicked Submit on the create_account form ... and was also taken to the timeout page, so it's some general setting that's affecting your SSL pages rather than just one form.

I noticed in one of your previous posts that you've got your admin's Configuration->Sessions->Check SSL Session ID set to True (non-default). I have no idea what processing that setting enables/disables, but what happens if you change it back to False?

[lat9]

I've got a site that uses a shared SSL connection, so I thought I'd look to see what's different between the two installations. I turned off javascript in my browser, clicked the Register button in your header and then clicked the Submit button from your create_account page.

Your host is issuing a 302 redirect after the post; I think but do not know that this is the source of your problem. There are a bunch of people on webmasterworld.com that are very knowledgeable in this stuff (as are some of the people on this forum).

I'm using the "Live HTTP Headers" add-on for FireFox to view these messages.

https://server309.webhostingpad.com/~comm6179/index.php?main_page=create_account&zenid=<value 1>

POST /~comm6179/index.php?main_page=create_account&zenid=<value 1>HTTP/1.1
Host: server309.webhostingpad.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://server309.webhostingpad.com/~comm6179/index.php?main_page=login&zenid=<value 2>
Cookie: __utma=218166299.1727778918.1345318472.1345322284.1345463626.3; __utmc=218166299; __utmz=218166299.1345463626.3.3.utmcsr=yourwebsite.com|utmccn=(referral)|utmcmd=referral|utmcct=/
Content-Type: application/x-www-form-urlencoded
Content-Length: 271
securityToken=<value 3>&action=process&email_pref_html=email_format&firstname=&lastname=&street_address=&suburb=&city=&zone_id=&state=%C2%A0&postcode=&zone_country_id=223&telephone=&email_address=&password=&confirmation=&email_format=TEXT&x=42&y=14


HTTP/1.1 302 Moved Temporarily
Date: Mon, 20 Aug 2012 17:42:06 GMT
Server: Apache
X-Powered-By: PHP/5.3.14
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: zenid=<value 4>; path=/~comm6179; domain=yourwebsite.com; HttpOnly
Location: http://yourwebsite.com/index.php?main_page=time_out&zenid=<value 4>
Content-Length: 0
Connection: close
Content-Type: text/html

[robertwhitis]

I think I have resolved the issue.

First of all, thanks for the responses, both of you. I changed the init_sanitize file back to default since I believe I have resolved the issue.

Basically, I was unaware that my hosting company offered CSR for their shared SSL certs. I called them and discussed my issue and they informed me that I could simply fill out a form to get the CSR taken care of, so now I have my branded https URL instead of the shared SSL URL.

Once that process was complete, I setup the configure.php files to use the https URL for everything, set up a permanent 301 redirect from www to http:// since the CSR didn't cover both www and http:// requests.

Once I did that, it appears everything seems to be working fine.

Based on what DrByte brought to light concerning the action URL for the header login, I believe I am OK, as that action URL was left as it was by defualt (action=process), and given that the entire site is running over the https protocol, I believe there should be no issues with data being sent unencrypted, is this correct?

As far as what "went live" meant - the site was developed on the live server, so "went live" basically just meant testing of the site was complete, the only change that was made to anything after testing was conducted, was to the .htaccess file to begin allowing search engine spiders to index the website. We tested all of the account features, payment processing, etc., in all 4 major browsers and didn't experience these issues. After that, changes were made to the site, but nothing in an area that should affect these issues (adding Facebook and Flickr icons to the footer, for instance), however, it is possible that in uploading files in making those changes I could have made a mistake without realizing it. Three weeks later all of a sudden these issues cropped up, so I'm honestly not sure what triggered them, I hope they are resolved now.

Thanks again lat9 and DrByte!

[DrByte]

I setup the configure.php files to use the https URL for everything

You should probably NOT use https for EVERYTHING.In your /includes/configure.php file, you should still be using an http address in the HTTP_SERVER definition.

[robertwhitis]

You should probably NOT use https for EVERYTHING.In your /includes/configure.php file, you should still be using an http address in the HTTP_SERVER definition.

Okay, if I change the HTTP_SERVER definition to the normal http URL in the config files, do I also need to remove the 301 redirect?

I'm curious why it's not a good idea to use https sitewide?