By Frameshift on

Hi Folks,

I have a site that I'm building where I'm running Drupal under Lighttpd (Lighty 1.4.19), php 5.2.6, and MySQL 5.0.45.

The site will eventually be deployed on a dedicated server at a hosting company.

I had intended to use mod_access rules in the lighttpd config to block access to /admin to all IPs except localhost (127/8). Utilizing SSH and port forwarding from a remote workstation, I could administer the site without exposing /admin to the world. The problem I've discovered is that it appears that
the 'virtual' paths such as /admin, /node, etc, are not visible to the mod_access rules.

Here are the rules used:

$HTTP["remoteip"] !~ "127" {
$HTTP["url"] =~ "^/admin/" {
url.access-deny = ("")
}
}

When the above is used, all access is allowed... if I change the path to just '/' I get a 403 forbidden, which is what I would expect.
Even when commenting out the 'remoteip' stuff and leaving strictly the 'url' rule, '/' works fine, but /admin doesn't. I tried /node, etc., and still no joy.

I haven't tried this on Apache, but I'm wondering if the same holds true. As an alternative, the thought is to use strictly SSL for /admin with certs which is much more of a pain to set up. However, my suspicion is that the same problem may exist for SSL since the paths aren't real.

To those that know much more than me on this subject... any input is welcome.

Regards,
Steve

⋅ Categories: Drupal 6.x

Comments

Garrett Albright’s picture

Garrett Albright commented

Recall that admin isn't a "real" path; it's being rewritten to ?q=admin. Do you have your access restriction part before or after the rewriting part in the config file? I haven't tested it, but I bet it has to be before.

Frameshift’s picture

Frameshift commented

Hi Garrett,

Nope, I'm not rewriting rules in the config file at all. I actually have it configured as a multi-site install with clean URLs and no rewrite rules...

A very interesting fellow with a monster genius streak in him over at hostingfu.com came up with a more elegant solution... He has a code snippet that gets dropped at the bottom of settings.php, and voila... clean urls and no rewrite rules. No need for mod_magnet, lua all that crap. He thought it was easier to modify drupal than to jump thru hoops with lighty.
Kudos to you my friend! :D

Here is the link... but we're digressing...
http://hostingfu.com/article/running-drupal-with-clean-url-on-nginx-or-l...

I recommend reading the whole article and comments after. So far its been flawless, except for a php error about an undefined variable that appears in the error.log but I can live with that for the moment.

I understand its a virtual/rewrite... my thought is on when does this actually apply the rule, on the incoming request, or the outgoing response? The end user is requesting the actual clean url. Or... perhaps change the rule to ?q=admin and test that... ponder..ponder... I'll have to check that one to see if it does the trick.

You have a point about the actual vs. the clean url appearance... perhaps the rewrite is higher level? Thoughts? Comments? Insights? (insert here) :)

Thanks.
S.

Garrett Albright’s picture

Garrett Albright commented

I personally am leery of tricks that involve error handling like that -- is the server still sending out a 404 error?

Unfortunately, it's been a while since I've had the opportunity to set up a live Drupal installation on a Lighttpd server. You might have better luck asking around at Lighty's forums or IRC channels.

Frameshift’s picture

Frameshift commented

Yep, the server sends out a 404 when you hit something that isn't there. So far every item I've touched works fine within the application.

I'm not a php coder, but I have some scripting knowledge, and at first glance, there are a few variables that are defined near the top of the snippet, and then a 'query' variable is stated later which wasn't previously defined and this is where the 'undefined variable' error shows up but still functions without a problem. Simply declaring it might correct it. But of course, their are those with far more in-depth noggin juice on the subject than I who can clarify that one.

Stressing with 'ab' yielded no problems thus far, other than lots of 'Undefined variable' messages.

I'll test the '?q=admin' as the path statement in the access rules and see if I get a reaction out of it today.

Stay tuned. :)
S.

Frameshift’s picture

Frameshift commented

Ok...

I tested the rule with '?q=admin' and still no joy. It appears that these requests are not seen at all by the mod_access module. I suspect this will be the same for attempting to use SSL as well.

Regards,
S.

Garrett Albright’s picture

Garrett Albright commented

I know this is just tangental to the solution you're looking for, but having the server send out a 404 header with every page request is a major problem, don't you think? You'll never be indexed by search engines, and Internet Explorer users are only going to see the generic IE-only 404 page (I think).

Anyway… Just for kicks, maybe try adjusting your regex in Lighty's config to block whenever just "admin" is found in the path; no slashes or carets. Maybe the regex simply isn't matching correctly. That will also block people trying to reach the admin pages without using Clean URLs -- keep in mind that query string-style URLs still work just fine when Clean URLs are enabled. (They have to.)

Frameshift’s picture

Frameshift commented

Thanks Garrett,

You asked if a 404 is going out with every request... the answer is no. All pages display correctly with proper HTML response codes (usually 200 haven't seen anything otherwise).

I read some blurb somewhere that the match is supposed to be postfix and not regex... either way, if I'm trying to match on just the string alone, it fails. i.e.

url.access-deny = "admin"

or

url.access-deny="/admin"

etc...

Its the little details that get me... GRRR! lol

S.