How is forms auth cookie set w/o throwing exception?
Stefan, you write on pages 265 and 266 (in Chapter 6):
When ASP.NET detects that a response has been modified, prior to handing
the request back to IIS6, it checks to see if the request was either a
POST request or a request for a classic ASP page. If it's either, ASP.NET
will thrown an exception rather than hand control back to IIS6.
What are some of the things you can safe do in ASP.NET?
Forms authentication APIs that create tickets as well as encrypting and
decrypting string representations of the tickets. However you cannot call
methods like SetAuthCookie or RedirectFromLoginPage.
Given what you say above, how is the ASP.NET 2.0 forms authentication
mechanism able to store the forms authorization cookie in the response without
causing an exception to be thrown? And after the user logs in, presumably
the forms auth mechanism would invoke RedirectFromLoginPage to redirect the
user back to the default.asp page ... so that would also cause an exception
to be thrown wouldn't it? I must be missing something here. And the need
to invoke SetAuthCookie and redirect to an asp page would not just occur
on the initial login, it would of course also occur wheneve the auth cookie
One additional question: if an http request is for an aspx page, wouldn't the
page be processed twice by the ISAPI extension for ASP.NET -- once because
of the wildcard mapping and once because of the regular mapping for the
.aspx suffix? Why doesn't this lead to duplicate processing?
Thanks for any clarification,
Last edited by mike66; April 9th, 2009 at 08:27 AM.