This posting is intended to explore the continuation in 6.x of an install problem under IIS and a solution identified and solved by grahamgilchrist for 5.x in the following thread:
Curious Drupal/PHP session problem causing 'Access Denied'
http://drupal.org/node/192151
One of the reasons we chose Drupal was because it was able to work with our pre-existing IIS server. After installation, we ran into periodic difficulties logging in: either we would get access denied or the login would get lost and a user would be bumped out to anonymous after appearing to log in successfully. After trying many different solutions found in this Forum, we were finally able to get an install of Drupal 6.2 working correctly under IIS 5, PHP 5.2.6, MySQL 5.0.45.
Today we updated to version 6.4 and only one fix was required after following instructions in update.txt. Until applying this fix, a user would get access denied when trying to log in. The fix we required was grahamgilchrist's solution of adding a line to ../includes/session.inc that forces the $key variable to be set correctly when writing the session variable:
function sess_write($key, $value) {
global $user;
$key = $_COOKIE[session_name()];I have the impression that the specific problem this solves is caused by an IIS 5 (maybe also 4 or 6?) bug where session cookies are not passed correctly to the browser or do not retain proper domain information or something.
My questions are:
1. Does this fix introduce a new potential security risk?
2. Can this fix be somehow incorporated (perhaps commented out?) so that IIS users can find it when they run into this problem during installation?
Phil.
Comments
Me too
Thanks for opening this thread for Drupal 6. I can confirm that I have run a couple of drupal 6 sites on IIS 5 (The one which comes with windows server 2000) and the problem still persists from drupal 5. I had hoped it would be resolved in D6 but alas no.
The above mentioned fix still works but I am curious to know why, and if there are any security risks involved. Seeing as all it does is read the browser cookie at what 'seems' (to me - only a passing familiarity with drupal core) at the appropriate moment, I think it's ok, but I can't be sure.
I aagree it is an issue related to IIS and the domain/cookie settings as drupla worked fine on an identical test server running the same versions of everything, only with an IP address rather than a domain name.
1. I'm not a security expert
1. I'm not a security expert but I can't see any obvious problems with this workaround. http://api.drupal.org/api/function/conf_init/6 defines the session name at the bottom ... it is SESS plus an md5 hash based on the domain and/or directory path of the installation I think. This code gets run pretty early on in the page request.
You are just defining $key to be what it should be anyway. Something similar is done in http://api.drupal.org/api/function/sess_read/6 to check quickly for anonymous users. I wonder what value of $key is getting passed to your sess_write()..? Seems odd that it's getting passed correctly to sess_read() though.
2. I suspect part of the problem is that few if any of the developers test on IIS. I suggest you open a bug against Drupal project http://drupal.org/node/add/project-issue/drupal/bug and see if you can get any traction!
Did you require your fix before upgrading to 6.4?
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Thanks for the feedback,
Thanks for the feedback, gpk.
I had considered moving this into the bug tracking system, but the problem is that I don't currently have a clean development environment available that matches the IIS 5 production environment where the problems exist. So I have no way to properly duplicate the bug and test alternate possible fixes against base, reproducible IIS installs by myself.
My post could have been more clear on that. Yes, we required the fix to session.inc in both 6.2 and 6.4 under IIS 5. For our intial install in 6.2 we did a bunch of other things as well, including changing PHP versions and modifiying various php.ini values, but unfortunately we do not have a clear record of all of the changes we tried, and not all config edits were reverted back to their initial states. So our 6.2 install included the fix identified above, but it may also have included a couple other stray edits that are also mentioned in these Forums as fixes for various things under IIS.
However, in the update to 6.4, we replaced all the drupal core files, so whatever changes we may have made to those were overwritten. And so now I'm thinking that as long as someone manages to get their PHP and IIS settings configured correctly, then they should be able to get 6.x working under IIS, EXCEPT if they are affected by this one bug. And I'm theorizing that unlike the other problems with IIS (that might be fixed by changing various PHP or IIS settings) this one bug is fixable only by modifying the sessions.inc (or some other essential drupal file).
One final note, is that like grahamgilchrist, we are running our Drupal in a subdomain/virtual directory that is of the format: drupal.domain.tld. And looking through the thread on 5.x leads me to think that the IIS bug may be limited to Drupal installs that follow that install pattern.
Phil.
OK, TBH I don't know if it's
OK, TBH I don't know if it's a PHP/IIS/Drupal bug or what - I'm not familiar with the internal workings of sessions in PHP, except that I'm aware that historically it's all been pretty problematic! However it might well be something that Drupal needs to work round if use of IIS is to be supported - in which case this *is* important and you should indeed open a bug report. At least that flags the potential problem up, and although your fix is quite simple and looks OK to me the core developers would then have visibility of it and be able to comment etc.
[update] If you go to http://drupal.org/project/issues/search/drupal and search for "IIS session" and select the entire contents of the listbox "Status" I think you'll see a few of the results could be related to your issue.
Best,
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
> One final note, is that
> One final note, is that like grahamgilchrist, we are running our Drupal in a subdomain/virtual directory
> that is of the format: drupal.domain.tld. And looking through the thread on 5.x leads me to think that
> the IIS bug may be limited to Drupal installs that follow that install pattern.
That was my initial thought as well, but I have since set up two drupal 6 sites on an identical server configuration which are on full top level domains (e.g. www.mysite.com) and the problem persists, leading me to now believe it is a PHP/IIS session issue affecting certain combinations of the two (since not all people running drupal on IIS have this problem).
Not quite fixed yet!!!!
BTW...
The fix worked with IE... but yesterday I installed the new Google Chrome and now I can’t login anymore!!!! I have to use IE to log into my Drupal application! I'm back to square one... Just as before, when I try to login with my username and password I am prompted to login again... no error messages...
I've just noticed that I can't login with Firefox (FF) also!!! If I take a look at the session table, no admin or anonymous user is created with FF or Chrome!!!
Anyone else observed this problem or has a fix for it?
Cheers
Ryk
Ryk, are you sure that the
Ryk, are you sure that the problem you are having is the same as the one identified in my original post? Can you give details of which version of IIS, Drupal, PHP, and MySQL you are running? The solution provided has been working great for us with no issues under FF (I';ve tested on both Mac and Windows environments using FF 2.x and also Mac FF 3.x). I haven't spent any time with Chrome, yet, though.
Oh, I see you've double-posted. I would recommend keeping your post in this thread as this one is tagged for 6.x, whereas the other thread on this topic is tagged for 5.x and you appear to be running 6.4. Maybe solving the problem for Postgresql is not the same as for MySQL. I think you're the first one who has indicated that you are using Postgresql. Firefox should definitely work with the fix applied. Have you made sure that you emptied your local FF cache, restarted IIS, and flushed any other caches you could?
Phil.