Loghound.com

With the exception of .MAC Lockdown works on almost every web host. The problem is there are a few hosts that have problems, before you buy lockdown please download a version and try it. The only limitation of Lockdown without a registration code is you can't save your work to a Rapidweaver file.

To try it first download, install it and create a simple web page with only a lockdown page.

Publish the page but don't save it (Rapidweaver will ask to save it, just say no) and then visit it. If it says that Lockdown worked and you get the username/password prompt then you are good to go!

If it asks you to try the alternate instructions then try those and verify it works (again, don't try to save your Rapidweaver file).

If you are having problems getting lockdown to work my first suggestion is always "create a small test page".

By this I mean create brand new site in a brand new RapidWeaver file that has a simple lockdown page, it it put the following contents

<?php

print "The current directory is: " . getcwd();

phpinfo();

?>

and publish it somewhere 'off to the side' on your server (off to the side means create a blank private URL on your web server that you can post this to as an experiment)

If you publish one of these test sites and you still see the same problem then we may need to diagnose a server issue. In this case I'll ask you to send me two things

1. the 'small' RapidWeaver test file (it should be quite small, < 100kB) that you created above.
2. A copy of the web page from the sever (this should also be quite small, < 100kB or so)
   • This is a critical item. What I want you to do is to ftp login to your sever using your ftp client of choice (I use transmit) and drag the folder that you just published to your desktop. Then right click and select 'Create an Archive'.

Send both of the files (the Rapidweaver file and the zipped up site) to me to help diagnose the problem.

With these two files I can see exactly how you published your information and what eventually got on the sever

All loghound.com plugins work on RapidWeaver version 3.2 and 3.5.

If you are having a problem running a plugin under 3.5 here are a few troubleshooting tips.

1) Verify that you have the latest version of plugins. You can get the newest version via the "Change Log" for each plugin
2) Make sure you COMPLETELY remove the old plugin first by moving it to the trash (via the finder) You can follow the instructions for 'installation' for each of the plugins
3) Make sure RapidWeaver is called "RapidWeaver", there can be problems if it's called something like "RapidWeaver 3.5"
4) If you still have problems bring up Console.app and then run RapidWeaver to see what kind's of messages are put out.

If you get the following on a Lockdown page



Parse error: syntax error, unexpected T_STRING in xxx on line 1


Where 'xxx' refers to a path on your system then you probably have 'Use XML Declaration' enabled in the page inspector (Apple-I)



Simple turn it off to make this error go away

How to Configure Lockdown with Personal Web Sharing

AKA How to get it to work with your Mac's built in web server

Mac OSX comes built in with the worlds best web server (Apache) but by default it does allow a user to enable passwords on a per-directory basis. This feature is called 'AllowOverride' and by default it's turned off so Lockdown doesn't work.

Fortunately the solution to fix it to allow Lockdown is quite easy but does require you are comfortable with editing config files.

You need to use a tool that can open 'private' files, in this example I use TextWrangler because It's free and I love it. If you are a Unix Hacker you can jump to the very bottom of this page to see how to modify this from the command line which is less steps and arguably easier but requires you know vi.



Open the file:

/private/etc/httpd/users/[username].conf

Where [username] is your 'short' username. In my case it's 'johnmcl'. Because this is a so-called private file you have to either open it from a terminal window using a command line tool such as 'vi' or use a special feature of TextWrangeler called 'Open file by Name'



In my case I typed in

/private/etc/httpd/users/johnmcl.conf



The file looks like this


<Directory "/Users/johnmcl/Sites/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>




Now I want to change the 'None' to 'All' and TextWranger warns me.




Clicking yes, I modify the file to AllowOverride


<Directory "/Users/johnmcl/Sites/">
Options Indexes MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>



And save the file... TextWrangler needs to verify I can modify this password







No problem.. I type in my password and save... The only thing left to do is to restart the web server to have the new settings take effect.

Go to System Preferences -> Sharing





Highlite "Personal Web Sharing" and click 'stop', give it a second to stop



And then click 'Start' to restart it... That's it! Lockdown should not be enabled!

Command Line

If you prefer you can also do this from the command line. Assuming you are logged in as the user who you want to enable LockDown at the command prompt type

sudo vi /private/etc/httpd/users/$USER.conf

Give it the password, and modify the 'AllowOverride' to 'All' from None, save it, restart Apache and you are finished!

If you want to use Lockdown from your mac you also need to enable php -- This is fairly painless and just requires editing httpd.conf file.

There are many good tutorials on the web (just google for it)

If you are using GoDaddy.com it does support lockdown if you have the right account type and a little patience :-)

1. 
   
2. Go Daddy offers both Windows & Linux hosting... The windows hosting doesn't work with Lockdown.... For 99% of people Linux hosting is a better bet anyway.  If you are on windows and don't really need it I would contact godaddy and see if they can switch you.
3. 

   
   

4. GoDaddy has a (slightly) strange behavior.  It takes a few hours for Lockdown to work.  I've had a bunch of people with problems on GoDaddy and eventually I went ahead and signed up to see what the deal was (so i know for a fact this is true). Turns out when you first lockdown a page no password is asked for but go back to it a few hours later and Viola! Lockdown page...
5. 
   
   I think it's due to how they manage their filesystems but if you do a lockdown page... Visit it to get the 'you should be locked down' message and then wait a few hours. 
   
   

Bottom Line: Verify you have a Linux account, if you don't send godaddy a request to switch you. If you do have a linux account just wait a few hours.

Starting with Version 1.5 of Lockdown you can now 'Expire' Passwords. This is useful if, say, you want to grant access to someone for a few days and don't want the system to automatically disable access.

To use it simply type in the expiration date next to the password. you can also use things like "Next week" or "In 3 days" (of course you can also simply type a date in)


once a user 'expires' the field grays out to tell you they are no longer have access. At this point you can ignore them, delete them or re-enable the account by putting a new expire date. The default of ignoring them has the same effect of removing them. They no longer have access to the site.


Please not that this feature is different than account time outs you may have seen on sites like Amazon.com (which automatically log you out after a preset amount of time with no activity).

Limitations in Removing users

the default behavior is 'Never Expire' but you can optionally  give a date after which the account would nominally not work.

Unfortunately there are so many different ways web hosts configure their servers that it will work different ways for different people.

For everyone everytime you 'publish' out of RW if the 'expiration date'  has been exceeded that user will no longer be authorized (it'll still show in the list but be grayed out) and their account will be removed from the  web site.

For some (many) people I will be able to remove them *without* republishing (on the fly)  sometime after the expiration date.. It'll depend on someone (anyone) visiting the lockdown page which will trigger the removal of expired users.

For some folks (anyone who has to use the 'alternate configuration method') I am not able to turn off account access on the fly, I will be able to stop them from seeing the content on the actual lockdown page but that person could still be able to jump to a nested page (until you republished the site at which point they would be locked out)

The key message is that it will work fine if you are willing to live with the 'expiration' date as a 'do not shut them off sooner than this date but it's-ok-if-they-have-access-beyond-that-for-a-bit' where the 'a bit' is defined by how often you republish your RW site, how active people visit it and how often the lockdown page is visited.

If you use page redirection you may find that you are being asked for the same password twice. Below is an excerpt from a nice summary of the problem (the original text can be found here

When entering a password-protected web site for the first time, you will occasionally notice that you are asked for your password twice. This may happen immediately after you entered the password the first time, or it may happen when you click on the first link after authenticating the first time.

This happens for a very simple, but nonetheless confusing, reason, again having to do with the way that the browser caches the login information.

Login information is stored on the browser based on the authentication realm, specified by the AuthName directive, and by the server name. In this way, the browser can distinguish between the Private authentication realm on one site and on another. So, if you go to a site using one name for the server, and internal links on the server refer to that server by a different name, the browser has no way to know that they are in fact the same server.

For example, if you were to visit the URL http://example.com/private/, which required authentication, your browser would remember the supplied username and password, associated with the hostname example.com. If, by virtue of an internal redirect, or fully-qualified HTML links in pages, you are then sent to the URL http://www.example.com/private/, even though this is really exactly the same URL, the browser does not know this for sure, and is forced to request the authentication information again, since example.com and www.example.com are not exactly the same hostname. Your browser has no particular way to know that these are the same web site.

If you go to a lockdown page and get HTML like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <meta name="robots" content="all" /> <meta name="generator" content="RapidWeaver" /> <meta name="generatorversion" content="3.5.1 (Build 264)" /> <title>lockdown</title> <link rel="stylesheet" type="text/css" media="screen" href="../rw_common/themes/aqualicious/styles.css" /> <link rel="stylesheet" type="text/css" media="print" href="../rw_common/themes/aqualicious/print.css" /> <link rel="stylesheet" type="text/css" media="handheld" href="../rw_common/themes/aqualicious/handheld.css" /> <link rel="stylesheet" type="text/css" media="screen" href=....

Then odds are your web host does not support PHP. While most hosts do some do not on their lowest cost plans.

Unfortunately lockdown requires PHP, you might contact your web host support team to find out if they can enable PHP for you.

You will find that a lockdown page will only ask for a password once. This is because the browser 'remembers' the password and automatically gives it to the lockdown page.

You can test this by completely exiting the browser (or running a different browser such as opera or firefox) -- you'll see it ask for the password again.

Releases of Lockdown prior to 1.65U had a problem with Authorization redirects (also known as 401 redirects)

You see 401 redirects require that the redirect page be an absolute path on the server (such as '/pages/error.html) while the other error pages allow full URL's (such as http://www.google.com)

See here for a write up of this but the short answer is I now specifically disallow external URL's and format the internal (e.g. within RW) urls as absolute paths.

There is one odd side effect that I don't completely understand. If you go to a document with a password and hit 'cancel' it keeps on asking you. If you hit cancel enough times it eventually directs you to the error page *minus* the CSS, javascript, themes, etc.

If anyone understands why let me know. I've been scratching my head over it and don't have a good answer yet.

In the meantime if you have this problem the easy solution is to use a HTML page without a theme (you can turn the theme off for HTML pages) and have a simple document saying with a URL link back to the main web page.

For page redirects to work you need to make make sure a few things are correct.

1. Check to insure that your base URL is set (see Here and Here for good details).
2. If you are redirecting to a page not on your RW3 file (such as an offsite page) make sure it's properly formatted with a http:// in front