MindTouch Developer Center > MindTouch Deki > FAQ > Configuration > How do I...Enable SSL at Login Time Only?

How do I...Enable SSL at Login Time Only?

NOTE:  These instructions were transferred over from this forum thread.
 

Setup Instructions

First, if you haven't done so already, setup SSL support according to the following instructions:
How do I...Provide HTTPS Access to Deki Wiki?

Also of use is this 'outdated' page, but it shows an Apache configuration where both the non-SSL and SSL are active at the same time:
User:PeteE/Etch SSL Configuration

Once you have SSL working, proceed with the following instructions. First, you'll need to add some rewrite rules (the highlighted text below) to the non-SSL site in your Apache configuration. Order is important, so add these rewrite rules before the Deki Wiki-provided rewrite rules:
 

<VirtualHost *:80>
...

RewriteEngine On # Enable rule to force all traffic to go to https.
#RewriteRule (.*) https://%{SERVER_NAME}$1 [L,R,NE] #Redirect login page to https RewriteCond %{QUERY_STRING} ^title\=Special\:Userlogin.* RewriteRule (.*) https://%{SERVER_NAME}$1 [L,R,NE] # Rewrite rules provided by Dekiwiki
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^/$ /index.php?title= [L,NE]

...
</VirtualHost>


 

Next, add a new rewrite rule to the SSL site that will redirect back to the non-SSL site after the login process:
 

<VirtualHost *:443>
...

RewriteEngine On # When we are going from the login page back to the home page, # redirect back to the non-SSL site.  Disable this rewrite rule when # you want all traffic to go to the SSL site. RewriteCond %{REQUEST_URI} ^/$ RewriteCond %{HTTP_REFERER} ^https.*title\=Special\:Userlogin\&returntotitle\=$ RewriteRule (.*) http://%{SERVER_NAME}$1 [L,R,NE] # Rewrite rules provided by Dekiwiki
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^/$ /index.php?title= [L,NE]

...
</VirtualHost>


Keep in mind that I haven't fully tested this, but I do know that this works properly for the following sequence:
 

  1. Go to home page of your non-SSL wiki site
  2. Login from the home page (you will then be redirected to the SSL site)
  3. Enter your credentials on the SSL-enabled page
  4. You will then be redirected back to the non-SSL home page


This works, but I wonder if there would ever be a situation where you would be sent to another page besides the home page after logging in. If there are situations where this could happen, then the rewrite rules will need to be modified. To explain further, the rewrite rules (for the SSL site) check to see if you are headed to the homepage. But only if you were leaving the login page and going to the homepage will it redirect back to the non-SSL site. If the login page ALWAYS redirects back to the home page, then the rewrite rules should not need to be modified. We will have problems otherwise.
 

Problems

One known problem is that of mixed content warnings from a browser on the SSL login page (you get these warnings when you have elements on the page from both HTTP and HTTPS...just look at page source or 'page info' in your browser to verify what I'm talking about when you run into these warnings). The following two items are ones that I have found that cause these warnings (one is fixable, one I think is a bug in Dream but I'm not sure):
 

  • Google Analytics ID - The google analytics support in Deki Wiki causes mixed content warnings on the SSL login page. To fix this, go to Control Panel --> Site Settings --> Google Analytic and erase the default ID that is provided.
     
  • Dekiwiki site logo - This is one that I think could be a bug in Dream. With the rewrite rules above, every element (pictures, graphics, etc) on the SSL login page is an HTTPS element except for the site logo for some reason. See notes on this behavior in the next section.

Dekiwiki site logo - SSL Mixed Content Warnings

In Firefox, to check whether the Deki Wiki logo on the SSL login page is HTTP or HTTPS, right click on the Deki Wiki's SSL login page --> View page info --> Media tab --> and look for an entry similar to the following:

http://mydekiwiki.com/@api/deki/site/logo.png

Ok, so why is the site logo not HTTPS? Well, I've noticed the following behavior:

1.  The site logo on the SSL login page will be an HTTP element, and it will also be an HTTP element for all other pages when you perform the following sequence (this is when you get the mixed-content warnings):
 

  • Restart dekihost on your server...'/etc/init.d/dekihost restart'
  • Make sure that the first page you go to on the wiki is a non-SSL page (e.g. http://mydekiwiki.com)
  • Click login to go to the SSL-enabled login page (you will get mixed content warnings with IE at least, maybe firefox too)
  • In IE or Firefox, look at page source and you will see that the site logo is an HTTP element.
  • All pages even the SSL-enabled page will show the site logo as an HTTP element


2.  The site logo on the SSL login page will be an HTTPS element, but it will also be an HTTPS element for all other pages when you perform the following sequence:
 

  • Restart dekihost on your server...'/etc/init.d/dekihost restart'
  • Make sure that the first page you go to on the wiki is an SSL page (e.g. https://mydekiwiki.com)
  • Click login to go to the SSL-enabled login page
  • In contrast to the first example, you will see that the site logo is an HTTPS element.
  • All pages, even non-SSL pages will show the site logo as an HTTPS element


The site logo will be either HTTPS or HTTP depending on the first page you go to after restarting 'dekihost' on the server. I'm not sure why the Apache rewrite rules would not work or apply to the site logo, but it I believe, based on the above behavior, that part of the problem could be with Dream. To me, it seems like it is remembering the base URL for the site logo depending on the first page that you go to, but isn't updating the base URL when switching back and forth from non-SSL to SSL.
 

Tag page
Viewing 1 of 1 comments: view all
I was able to get beyond the problem with the logo mentioned above by modifying my port 80 virtual host to look as follows. What basically is happening is that these first rewrites on virtualhost 80 are causing the logo to have an http url and when one redirects to the 443 host, nothing has changed that logo url and you get mixed content. Hope this helps.:

<VirtualHost *:80>
ServerName mydomain.com
#ServerAlias

ErrorLog /var/log/apache2/error-dekiwiki.log
CustomLog /var/log/apache2/access-dekiwiki.log common

DocumentRoot "/var/www/dekiwiki"

# RewriteEngine On
# RewriteCond %{REQUEST_URI} ^/$
# RewriteRule ^/$ /index.php?title= [L,NE]

# RewriteCond %{REQUEST_URI} ^/@gui/[^.]+$
# RewriteRule ^/@gui/(.*)$ /proxy.php?path=$1 [L,QSA,NE]

# RewriteCond %{REQUEST_URI} !^/(@api|editor|skins|config|@gui)/
# RewriteCond %{REQUEST_URI} !^/index\.php
# RewriteCond %{REQUEST_URI} !^/favicon\.ico$
# RewriteCond %{REQUEST_URI} !^/robots\.txt$
# RewriteCond %{QUERY_STRING} ^$ [OR] %{REQUEST_URI} ^/Special:Search
# RewriteRule ^/(.*)$ /index.php?title=$1 [L,QSA,NE]

# deki-api uses encoded slashes in query parameters so AllowEncodedSlashes must be On
AllowEncodedSlashes On

# FIXME:
# Some php flags we need. These are only needed until all
# the short php open tags are changed to long in the source code.
php_flag short_open_tag on
# Allow short open tags and turn off E_NOTICE messages
php_value error_reporting "E_ALL & ~E_NOTICE"
# Setting php memory parameters
# php_value memory_limit "128M"
# php_value post_max_size "64M"
# php_value upload_max_filesize "64M"

# mod_proxy rules
# ProxyPass /@api http://localhost:8081 retry=1
# ProxyPassReverse /@api http://localhost:8081
# SetEnv force-proxy-request-1.0 1
# SetEnv proxy-nokeepalive 1

Redirect / https://mydomain.com/index.php?title=Special:Userlogin&returntotitle=

# <Proxy *>
# AddDefaultCharset off
# Order deny,allow
# Deny from all
# Allow from all
# </Proxy>
</VirtualHost>

<Directory "/var/www/dekiwiki">
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs-2.2/mod/core.html#options
# for more information.
Options None
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
AllowOverride All
# Controls who can get stuff from this server.
Order allow,deny
Allow from all
</Directory>
Posted 00:33, 7 Aug 2008
Viewing 1 of 1 comments: view all
You must login to post a comment.