Kishore's had an auth issue this week, but my theory on that bug
is that it's the custom error response used to force the redirect 
to the login page.

Your issue is with NTLM auth.  If you don't attempt to use system
credentials, all should work better.  There is an ntlm module,
but it isn't part of the core, and isn't integrated into mod_aspdotnet.


At 10:33 PM 3/2/2005, Walter Nicholls wrote:
>I'm becoming fairly sure that there is a problem with mod_aspdotnet not
>passing authentication information on to the ASP.NET framework.
>
>[This may be duplicate post to the list, I sent the first before my 
>subscription was fully confirmed]
>
>Bugzilla appears to be down, so I haven't managed to research anything
>there.  My apologies for this being a bit wordy, I'm going to prove
>there is is something wrong and pinpoint it in this email if I can.
>
>The end result is that on a web application for which authentication is
>REQUIRED, the User.Identity... properties are set correctly under IIS,
>but not under Apache/mod_aspdotnet.  Since I have an application which
>is relying on these values, I cannot use mod_aspdotnet.  This pretty
>much eliminates Apache too, since Mono isn't an option with the code in
>the shape it is now.
>
>OK so I am using Windows XP SP2, Apache 2.0.53, and
>mod_aspdotnet-2.0.0.msi dated 21-Nov-2004. All current as of today.
>
>Some things which are working
>1. It all works OK under IIS ( obviously if it didn't I'd be looking for
>bugs in my code)
>2. Authentication is definitely occuring.  In IIS I have anonymous
>access disabled; under Apache AuthType Basic / AuthUserFile / Require
>... set ok.  Going straight in with a browser brings up login dialog,
>with WGET or the client app and no sensible credentials gives 401 error.
>3. ASP.NET code which does not look at the User.Identity  is also
>working fine.  Well, I haven't gone past anything but very basic things,
>but I can bring an .ASPX page in the browser and server-side code is
>running; I  can browse web service methods and test directly from
>Firefox, including getting complex results.  "This is cool", I think
>
>However then the differences occur
>Under IIS:
>  User.Identity.IsAuthenticated = true, IIS
>User.Identity.AuthenticationType = NTLM, and User.Identity.Name = (me)
>
>Under Apache
>  User.Identity.IsAuthenticated = false, IIS
>User.Identity.AuthenticationType = (empty string), and
>User.Identity.Name = (empty string)
>
>Expected - IsAuthenticated=true, AuthenticationType = Basic, Name = (me)
>(note the only difference being IIS will be NTLM, Apache Basic, and the
>user name in question, that's a genuine configuration difference. I'm
>not trying mod_auth_ntlm, yet)
>
>Digging further, and using the following code
>       private void Page_Load(object sender, System.EventArgs e)
>       {
>           // Put user code to initialize the page here
>           System.Text.StringBuilder sb = new System.Text.StringBuilder();
>           sb.Append( @"<h2>Server variables</h2><table>" );
>           for( int ii = 0; ii < Request.ServerVariables.Count; ++ii )
>           {
>               sb.AppendFormat( @"<tr><td>{0}</td><td>{1}</td></tr>",
>                       Request.ServerVariables.GetKey(ii),
>Request.ServerVariables[ii] );
>           }
>           sb.Append( @"</table>" );
>           Label1.Text = sb.ToString();
>       }
>
>This gives the following result under IIS (edited, I'm not showing the
>whole dump!):
>AUTH_TYPE    NTLM
>AUTH_USER    LAPUTA\Walter
>AUTH_PASSWORD
>LOGON_USER    laputa\Walter
>REMOTE_USER    LAPUTA\Walter
>
>Also, just
>REMOTE_ADDR    127.0.0.1
>REMOTE_HOST    127.0.0.1
>REQUEST_METHOD    GET
>SERVER_NAME    localhost
>SERVER_PORT    80
>SERVER_PROTOCOL    HTTP/1.1
>SERVER_SOFTWARE    Microsoft-IIS/5.1
>
>However under Apache I get: (same edited list)
>AUTH_TYPE
>AUTH_USER
>AUTH_PASSWORD
>LOGON_USER
>REMOTE_USER
>
>All the other variables have values as expected  (SERVER_NAME =
>localhost, SERVER_PORT = 80 or 81, SERVER_SOFTWARE = Microsoft-IIS/5.1
>or Apache/2.0.53 (Win32)).  Everything seems hunky-dory EXCEPT that
>under mod_aspdotnet all the user variables are blank, despite the fact
>that I'm logged in. So is it Apache or mod_aspdotnet?
>
>If I write a one line batch file consisting solely of the one line SET
>then the variables printed out are:
>REMOTE_USER=Walter
>AUTH_TYPE=Basic
>
>Which is conforming perfectly to the CGI 1.1 specification! So it would
>appear to be mod_aspdotnet which is at fault.
>
>Now I get a bit unsure of my ground. I assume the ASP.NET framework is
>using the GetServerVariable() method of the WorkerRequest object, and I
>can't see why this code doesn't return the same headers as Apache is
>supplying to the CGI file:
>       virtual String* GetServerVariable(String *name)
>       {
>           int ent = env_var->IndexOf(name);
>           if (ent >= 0) {
>               return static_cast<String*>(env_value->get_Item(ent));
>           }
>
>Are the REMOTE_USER and AUTH_TYPE environment variables manufactured by
>the Apache CGI handler?  In which case explicit tests like this might be
>warranted
>
> if ( name->Equals(L"REMOTE_USER") ) { return
>..whereever_you_get_this_from(); }
>
>It would also be very sane to implement AUTH_USER as an alias to
>REMOTE_USER as well, as an "IIS emulation", even though this is not part
>of the CGI specification there will be .NET applications which expect it.
>
>I'm completely out of my depth here, I don't know the first thing about
>the Apache API and patching and compiling, even some rudimentary tests.
>I'm only guessing that setting the REMOTE_USER and  AUTH_TYPE (and
>probably AUTH_USER) will fix the User.Identity problem.
>
>TIA for any help.  Patching the code and issuing a new release would be
>good <gd&r>
>
>Walter Nicholls
>Cornerstone Software Ltd
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to