Re: Authenticate user and allow anonymous access
From: Joseph E Shook (JoeShook@DeploymentCentric.com)
From: "Joseph E Shook" <JoeShook@DeploymentCentric.com> Date: Wed, 19 Mar 2003 13:35:48 -0800
I don't mean to divert anyone to a different list but this is the kind of
hard question that I have often seen answered on the developmentor list
servs. There are some realy talented people out there with creative
"Nilssons" <firstname.lastname@example.org> wrote in message
> Joseph E Shook wrote in message:
> > No, you didn't miss anything. I figure there isn't any way to allow
> > anonymous and authenticated users in without using two virtual
> > so the only users that would ever have to enter credentials would be the
> > anonymous. But all anonymous users would use the same credentials so
> > are sill anonymous in that we don't know who they are. You are
> > correct in that my solution would require anonymous users to enter some
> > of credentials.
> > You know I was thinking that maybe a custom http handler or some code in
> > global.asax could be written to inform failed authentication attempts of
> > anonymous password. You know like when the server sends the browser a
> > error.
> > Kind of like the response code bellow:
> > Response.StatusCode = 401;
> > Response.StatusDescription = "Unauthorized";
> > Response.Write("<h2>Anonymous Username = Bob, and Password =
> > password</h2>");
> > Going down that path might be interesting. Because at least then an
> > anonymous user would learn the credentials. I am not sure this would
> > but I have had a lot of success with changing the browsers user
> > this way.
> Hi Joseph,
> Thanks for the insight on possible ways to approach this. I had
> actually found a solution, and I just wanted to post it here, it ended
> up being somewhat similar to what you are describing above.
> The solution you suggest won't work for the simple reason that once
> you send a 401.1 to the calling browser, the negotiation process will
> start between the browser and IIS, at this point ASP, ASP.NET or
> whatever is completely cut out, until the negotiation process is done,
> causing a login popup to show for unidentified users. So how to get
> around this?
> As it turns out, I was able to get a hold of an ISAPI filter, with
> source code in C++ that is called 'User.dll'. It is undocumented (at
> least the base that I have) with the exception of a brief
> implementation explanation. It works in the following way:
> - A user will call a page, on which you would like to identify the
> - If the presence of the http headers 'HTTP_AUTH_USER' and
> 'HTTP_REMOTE_USER' are not present (I will explain these shortly) do
> the following.
> - Set the response status to "307 Object Moved"
> - Add a new http header "Location" whish should look something like
> - End the response
> This will cause the browser and IIS to start the negotiation process,
> but while this process happens, it will be picked up by the User.dll
> ISAPI filter (provided you installed it in IIS), completely
> circumventing the Windows authentication and just passing on the
> results of the negotiation.
> Once the negotiation is done, the User.dll will pass on a page request
> to the page that was specified (ScriptBeingExecuted.aspx in this
> case), now with the added headers 'HTTP_AUTH_USER' and
> 'HTTP_REMOTE_USER'. HTTP_AUTH_USER will contain the Domain\Username if
> the user could be authenticated against the same domain that IIS is
> deployed in. HTTP_REMOTE_USER will contain the Domain\Username that
> the user used to log in on their machine.
> That's it.
> As you can imagine, I'm happy about the fact that this piece of code
> does what I need it to do, although I'm very unhappy about the fact
> that I can not identify where it came from, nor am I happy about the
> way it circumvents the Windows security standards. I could be made to
> feel more happy about the circumvention, if I knew the source of this
> thing, so my question to everyone would be: Has anyone seen this, or a
> variation of this anywhere else?
> Stefan Nilsson
> PS. I would be happy to send the code for User.dll to anyone who is
> interested, but please understand that I will not support it, since I
> am not the author...