08.03.11 
0 comments
So I am not sure if I am alone here, but I have encountered this issue several times whenever I have set up a server hosting multiple sites running Apache. Some sites have SSL’s installed, others do not. Given the increasing shortage of IPv4 addresses, I usually use the default IP address for the server for the first site using an SSL, then get additional IP’s for each additional sites needing SSL’s on an as-needed basis..
The Problem
The problem appears whenever a request is made for a secured page (e.g. https://www.example.com/test) for a site which does not have an SSL installed. Most browsers these days will display a daunting security warning that will deter most users, but on the off chance the user DOES proceed (or if they are using an older browser, or have poor security settings, etc) then they will probably see a DIFFERENT website than the one they requested. This can create confusion and might seem unprofessional to some.
The Solution
Dedicated SSL’s are generally configued in the apache configuration mapping the IP and port 443 to a particular SSL location. So lets say we have www.example.com running on IP 111.111.111.111. Our configuration would look something like this:
<VirtualHost 111.111.111.111:443>
ServerName www.example.com
DocumentRoot "/usr/home/example.com/htdocs"
SSLEngine On
SSLCertificateFile /usr/home/example.com/ssl/www.example.com.crt
SSLCertificateKeyFile /usr/home/example.com/ssl/www.example.com.key
SSLCertificateChainFile /usr/home/example.com/ssl/NetworkSolutions_CA.crt
<VirtualHost>
The solution is quite simple. We will just add the following lines inside this VirtualHost directive:
RewriteEngine On
RewriteCond %{SERVER_NAME} !^www.example.com$
RewriteRule ^(.*)$ http://%{SERVER_NAME}$1 [R=permanent,L]
So our final directive will look like this:
<VirtualHost 111.111.111.111:443>
# If server name does not match name on cert, redirect to non-https url for that server name
RewriteEngine On
RewriteCond %{SERVER_NAME} !^www.example.com$
RewriteRule ^(.*)$ http://%{SERVER_NAME}$1 [R=permanent,L]
ServerName www.example.com
DocumentRoot "/usr/home/example.com/htdocs"
SSLEngine On
SSLCertificateFile /usr/home/example.com/ssl/www.example.com.crt
SSLCertificateKeyFile /usr/home/example.com/ssl/www.example.com.key
SSLCertificateChainFile /usr/home/example.com/ssl/NetworkSolutions_CA.crt
<VirtualHost>
Please Note…
This solution will not actually remove the security warning. This will still be displayed in the browser because, well, there really ISN’T a security cert for the site being requested. So some warning of some sort may be unavoidable. But at least they will never see a seemingly random site in place of the one their request. Hope this helps someone!
05.08.10 0 comments
I have been thinking a lot lately about the various "WYSIWYG" editors on the market today, and how they can be a CMS developer's best friend, or worst nightmare. It all depends upon the expectations you set with a client from the beginning. A quick definition. WYSIWYG stands for "What you see is what you get." It bascially refers to a text editor which has a detailed toolbar containing icons for inserting images, tables, horizontal breaks, etc., as well as text formatting such as bold, italic, or underlined. The interface is often compared to that of Microsoft Word, at least the older versions. The idea is that any untrained user should be able to create their own Web page using this kind of editor, and the way it looks in the editor is exactly how it will look when published to the site. The only problem is that this is never true. There are two major reasons for this.
Most modern Web sites make extensive use of CSS to style layouts, positioning, padding, margin and the appearance of text on the page. Depending upon the myriad of variables involved, the CSS may override the styles defined by the user, or vice versa. In either case this can result in the user not "getting" what he/she "sees."
WYSIWYG editors, no matter how sophisticated, are only able to provide an "approximate" interpretation of user actions in the editor, and translate them into XHTML (code.) The task these editors are undertaking is incredibly complex, and no reasonable person, once the complexity is understood, can expect 100% accuracy. Editors must interpret not only single actions but series of actions- mouse clicks, highlighting, button clicks (and which order the buttons are clicked in.) This can result in problems, not only not getting what you see, but not getting what you expect.
The following, however, are some helpful tips drawn from long experience with clients and WYSIWYG editors. Hopefully this will save some developers and clients unnecessary headache.
Choose the Best WYSIWYG Editor You Can Find
Shop around - there are a lot of them. And be sure to test drive all of the available features. My personal recommendation is CKEditor. This is the most recent incarnation of "FCKEditor" which for years was the standard of WYSIWYG (also known as rich text editors.) This time around, however, they have cleverly found a way to monetize their product, by making the file uploader (used for images, etc.) an optional paid plugin - CKFinder. However you can get a no-strings-attached developer license for about $500, and in my experience, its well worth it. If you have to provide your client with a WYSIWYG editor, I feel this is your best bet.
Level with your client (and put it in the contract)
No matter how good your WYSIWYG editor, the problems I mentioned at the beginning of the post will still exist. Let your client know this. Assure your client that basic content changes and additions will be possible through the CMS, but when you start getting to more sophisticated - or even slightly sophisticated design problems such as the spacing of tables or images - let them know they might be better off paying you your hourly rate to add the pages for them. In the long run it will save both you and the client a lot of frustration.
Consider an alternative, such as a WYSIWYM (What You See is What you Mean) Editor or Textile
I personally feel that Wikipedia is one of the cleanest sites on the Web, and yet it has been able to maintain this polished look despite being literally the most heavily "user-edited" site on the Web. How did they do it? Well they use a proprietary editor with its own language, which is heavily validated before submission is accepted. It is similar to textile, which suggests using astericks to indicate bullet lists, or tags like "h2." to indicate headings. These types of editors are not incredibly difficult to learn, and result in code which much more closely represents the users actual intention than WYSIWYG "free for alls."
WYSIWYM editors are a little different, providing some of the same features of WYSIWYG editors, including toolbars and button, and yet provide ongoing feedback regarding the actual code that is being generated. As they say, what you see may not be what you get, but it is what you mean - which is, after all, what really matters. WYMEditor is a good one - and they have an online demo here.
Much more could be written on the subject, but hopefully this overview has been helpful. The main point is to discuss this with the client up front, so that what they ultimately get is what you both expect!
