Forum Moderators: phranque
I am a complete newbie at this and have scoured the internet looking for answers. Let me describe my situation. I am currently trying to configure a new membership management program I purchased that is completely based on PHP. The program also doubles as a shopping cart so I need the checkout pages to be secure using my newly installed SSL certificate. So far I have gathered the following (and please correct me if I'm wrong):
.htaccess files handle the directory it is in and any sub-directories within as well.
Out of all the code I have seen thus far....most of it describes re-directing index.html pages and my program are all .php pages. Does this matter?
On another site (that also linked to this forum)http://www.askapache.com/htaccess/http-https-rewriterule-redirect.html I found the following code:
RewriteCond %{HTTPS} =on
RewriteRule ^(.+)$ - [env=askapache:https]
RewriteCond %{HTTPS}!=on
RewriteRule ^(.+)$ - [env=askapache:http]
with
RewriteCond %{SERVER_PORT}s ^(443(s)¦[0-9]+s)$
RewriteRule ^(.+)$ - [env=askapache:http%2]
and
On this forum, I found this:
# redirect urls with index.html to folder
RewriteCond %{SERVER_PORT}s ^(443(s)¦[0-9]+s)$
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^/]+/)*index\.html\ HTTP/
RewriteRule ^(([^/]+/)*)index\.html$ http%2://%{HTTP_HOST}/$1 [R=301,L]
#
To be honest...this totally confused me. For some reason I cannot wrap my head around this. So, basically, I have concluded that I need to find the directory with the 'check out' pages in it and then edit the .htaccess file within that directory to make sure they show up as secure. The next problem I ran into is the code in the existing .htaccess file is this:
<Limit GET POST>
deny from all
</Limit>
I assume this would need to be deleted and the new code inserted....however, I remember reading about this being changed in the httpd.conf file. So, I'm lost at this pont and need to be put on the right track again. Thank you in advance for any help.
Based on that "Deny from All" directive you found in the .htaccess file, it appears that the directory with the check-out pages is not intended to be directly-accessible from the Web. Instead it's possible that that directory contains scripts which are to be 'included' by other scripts which *are* directly-accessible from the Web.
Also, based on what you've said (and not said), it looks like you need to spend several weeks researching the installation of this new package before jumping into deployment. If you are going to be handling people's credit cards but have basic questions about the installation and operation of your software, the potential for disaster due to security problems caused by installation errors cannot be ignored. And unless you are properly incorporated, a simple mistake could easily cost you your home, your car, and everything else you own... Proceed with utmost caution here, and don't rush into things.
I'd suggest going to the software provider's Web site, and spending a week or two in their FAQ, Help pages, and forum becoming an expert on this package -- to the point where *you* can answer questions about it here.
If you're in too big of a hurry for that, then hire a professional with experience in your specific cart application and server environment. Do check his/her references, too; Again, credit cards + security problems == personal liability risk... Alternately, use a third-party cart service provider (where they host and secure your cart and provide payment processing for you).
These are general recommendations only; I cannot offer further specific recommendations in this space.
Jim
When linking back out of your cart to non-cart pages (for example, your home page), again use the full url, but specify the http protocol, as in <a href="http://www.example.com">Visit our home page!</a>
Always keep in mind the two "zones" on your site -- the secure zone and the insecure zone, and don't mix any resources between the two (you can set up alias URLs or directories to allow sharing images and JS includes, though).
You can avoid a lot of trouble --and the need for a lot of .htaccess fix-up code-- simply by linking correctly from the start.
For example, the somewhat-complex code you found above has the purpose of redirecting requests for example.com/index.html back to example.com/; It removes the "index.html" part, preserving the originalhttp/https protocol and domain name. That code would not normally be needed unless an error had been made, and links had been published to example.com/index.html, instead of the preferred example.com/ URL.
Jim
Is there any easy way to make a single page SSL?
You mentioned creating dirs or ZOnes.. If I do that, all of my mapping to image sub directories will be messes up.. Im sure these are stupid questions.. but Im kind of lost here.
Craig
You likely don't need any redirects. In addition to being a very-loosely used (and abused) term, far too many Webmasters do unnecessary redirects. A redirect is a response to the client that asks (not tells) the client to re-request what it just asked for, but using a different URL. Therefore, it is not something that you want to do as part of the normal operation of your site.
If you want a page to be SSL, then link to it using the https: protocol in your <a href> tag.
I did not mean to imply that you needed to create zones or directories. What I intended to convey is that you should "think in terms of 'zones'." If you're a coder, you might prefer the phrase, "Think in terms of URL-sets." You will have some https/SSL URLs, and some http/non-SSL URLs. Simply make sure that this script that you purchased uses the correct protocol in links to these two sets of pages. If it doesn't, then complain to the vendor!
Basically, all links pointing to the shopping cart pages which handle credit cards and personal info should use https links, and all links pointing out of those areas to non-sensitive pages should use http links. Most scripts get this right. Others use a database that allows you to set the protocol for your pages or for groups of pages (the cart provider gets to define the groups, but the function is intended to address the problem we're discussing here).
At this point, I don't yet see any evidence that you need to do anything in .htaccess at all.
Jim
