Menu
▾
▴
#1 losing post request data using mod_auth_sspi
I updated mod_auth_sspi from 1.0.3 to 1.0.4 on a
Windows Apache 2.0.58Server.
After running the update I run in a strange problem.
I build an simple test web formular which sends some
data over a post request.
In most cases the post data is not submitted correctly.
It seems that the post request works only successfully
if I wait for the keep alive timout.
I use mod_auth_sspi with the following parameters:
AuthName "login for cp-admin"
SSPIDomain ww001
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIOfferBasic Off
Switching back to 1.0.3 of mod_auth_sspi works
properply as workaround
Logged In: YES
user_id=72472
I can confirm this bug running on a Windows 2003 Server, in
combination with Apache. Downgrading to 1.0.3 result for
every request two 401 errors in the access log...
Please review the code... :-)
Logged In: NO
I do have the same problem. I have a working version in my
xampp (win32) 1.5.4 package, but that version doesn't
understand the to-lower Parameter which I need.
Logged In: YES
user_id=1395463
I'm experiencing the same problem:
* mod_auth_sspi 1.0.4
* Apache 2.2.3 on Windows
Downgrading to 1.0.3 fixes this. The empty POST only occurs
with Internet Explorer clients - both Firefox (2.0) and
Opera (9.0.1) do NOT trigger this bug.
Logged In: NO
I don't know why, but setting
SSPIPerRequestAuth on
in the apache configuration solved the problem at my site.
Logged In: NO
The first comment suggesting "SSPIPerRequestAuth on" fixed my Post issues.
Now if I could just figure out what that does. It sounds as if it could add overhead.
Logged In: NO
Ok I think i understand what is happening
a) when a client makes a get request it may be challened to do a NTLM negotiation - there after the sspi module remembers the user credentials for teh duration of that connection. If the connection is closed the the negotitaion happens again - however this is at the expence of a domain controler lookup - so if its aheavy server you might upset your ID department
b) ms seem to have a 'feature' where if a post is made on an already authenticated connection then they restart the authentication. it seems that the sspi module doesnt catch this ( its an unsolicted type 1 ntlm request from the client ). That would be kind of fine EXCEPT that ie decides to set content length to be zero - it goes through to the cgi script ( or in my case mod_python ) and the cgi handler goes bang - because post requests ought to have content.
i can see why ms do this - conceptually posted data needs to be secuer so why not re-authenticate - just in case, but ideally i think then that mod_auth_sspi should catch the type 1 ntlm authentication request and not let the request get to the cgi script. If the authentcation goes through type 1, type2 and type 3 phases and the conenciton is successfully reauthenticated then ie will resent the correct post with the content and every one will be happy(?)
hope that makes sence, its not really a bug in teh module - its just that it has to do a bit extra because ms were cerative in their ie implementation.
until its 'fixed' there three work arounds that i know of
i) force the user to wait for the conneciton to drop - that can be done by loweing the keep alive and by disabling submit buttons by timers.
ii) use the SSPIPerRequestAuth flag to force the reauthentication for each request - but that as mentioned will hammer the domain controller
iii) move the post handler into a seperate directory which has the SSPIPerRequestAuth flag and leave the normal get handlers in a less paranoid directory.
Hope that makes sence
dolbyn@dircon.co.uk
Logged In: YES
user_id=1395463
Originator: NO
@dolbyn - Thanks for the detailed explanation! That does help things out.
Going back to the 1.0.3 version does seem to fix the problem - does somebody familiar with the code know what might have changed so that the problem crops up now?
Or perhaps I should just roll my sleeves up and try submitting a patch, but this isn't my area of expertise of coding and it might take a while.
Logged In: YES
user_id=669020
Originator: NO
Fix would be very welcome. There are many issues in open source projects what are no so easy to track to mod_auth_sspi
Trac: http://trac.edgewall.org/ticket/4560
Drupal: http://drupal.org/node/82530
Could be more: http://www.google.com/search?q=mod_auth_sspi+post
Forum backlinks:
http://www.gknw.de/phpbb/viewtopic.php?t=226
http://www.gknw.de/phpbb/viewtopic.php?t=181
Logged In: NO
Have the EXACT same problem on Win2003, Apache 2.0.55, php 5.0.5
Was doing cache clearing in browser/server but no consistency. Downgrade to 1.0.3 fixed issue.
Logged In: NO
Argh, we just spent a couple of days tracking this down to mod_auth_sspi 1.0.4 as well. Our config is like the above, but using it with mod_jk to hook up to Apache Tomcat 5.0 or 5.5. That's what we get for not checking here first!
Logged In: NO
We too have run into the same problem.
It took us a while to realize that this was a defect in mod_auth_sspi v1.0.4.
At first we thought it was a some sort of config issue between mod_jk and mod_auth_sspi.
But after looking at the HTTP headers, we found the post request data is lost!
Luckily in our lab we had a similiar environment running mod_auth_sspi v1.0.1 and it was working fine.
We grabbed the mod_auth_sspi.so from this working env. into our "broken" environment and it works.
Logged In: YES
user_id=1612434
Originator: NO
We too were baffled at this problem. We had figured out to turn the keepalive to 1. It took much searching to find this page with the solutions.
Looking at the code it seems that turning SSPIPerRequestAuth on is similar to the way version 1.0.3 works. SSPIPerRequestAuth was added in version 1.0.4. 1.0.3 clears the authentication data every time, similar to having SSPIPerRequestAuth on in 1.0.4. In my opinion 1.0.4 should have had this on by default. But I guess the authors didn't know it would cause such a problem. There are post all over the web about it.
I guess the permenent solution would be to check to see if the broswer is IE and see if this is a POST then re-authenticate. But I'm not sure Apache passes that information to the auth modules.
Version 1.0.4 seems mostly like a code cleanup. With a few other config file options added.
Logged In: YES
user_id=669020
Originator: NO
Additional reauthentication before POST by default would be enough.
Logged In: YES
user_id=1395463
Originator: NO
It probably doesn't help people find this information when this post is about "loosing" instead of "losing" post request data using mod_auth_sspi.
So, I'll put it here for the search engines:
mod_auth_sspi loses post data from IE6
Has anyone confirmed this for IE7 as well?
Logged In: YES
user_id=1612434
Originator: NO
Yes this affects IE7 as well.
Logged In: YES
user_id=1532985
Originator: YES
corrected spelling of headline :)
Logged In: YES
user_id=671379
Originator: NO
intermittently losing post data using mod_auth_sspi 1.04, Apache 2.2.4
Logged In: YES
user_id=859514
Originator: NO
Same problem in my environment. Windows 2003 Server (5.2 build 3790),
Apache 2.2.4, mod_auth_sspi 1.0.4, PHP 5.2.3.
Tested with IE6+IE7.
A code fix would really be great...
Logged In: NO
I have the problem using XAMPP 1.6.3 (Apache 2.2.4/mod_auth_sspi 1.0.1).
Problem does not seem to occur using XAMPP 1.5.3 (sspi 1.0.1/ Apache 2.x?)
Logged In: YES
user_id=352816
Originator: NO
I switched back to 1.0.3 and it seems to have solved the post problems, but it also seems to bring up other problems: people need to reauthenticate and firefox and IE6 and 7 keep popping up for authorisation.
I am willing to take a look at the source code to see if I can find the cause and solve the problem. But I can not find the source code. Can anybody help me locate the source code for version 1.0.3. and version 1.0.4.
Logged In: YES
user_id=669020
Originator: NO
The sources are included in distributions
https://sourceforge.net/project/showfiles.php?group_id=162518
There is also a discussion forum which may help
http://www.gknw.de/phpbb/viewforum.php?f=9
Logged In: YES
user_id=352816
Originator: NO
My apologies for being completely blond.