Jeff,
You will need the path. I only mentioned removing it as an experiment.
The thing to keep in mind about cookies is that it's up to the server to ask
the client to save them, but it's then up to the client to decide whether or
not to send them back to the server, and under what circumstances. Here are
some hints:
1) You should almost always include a domain. This tells the client
what set of web sites to send the cookie back to. For instance, if you have
a site called
www.company.com and you set the domain to "company.com", then
the cookie will be sent to pages under
www.company.com or press.company.com,
but not to joeblow.com. The one time to use a blank domain is when you're
working on localhost or something like that, when there is no domain to
include. BTW, during your tests, always refer to your web site the same way.
Don't try
http://localhost/mysite once and then try
http://mymachine/mysite
or
http://mymachine.company.com/mysite.
2) You should always set the path, but you should only set it to "/".
The path was originally meant to restrict what subset of your web site the
cookie should be sent to. For instance, you should be able to set the path
to "/press" and have the cookie sent to
http://www.company.com/press but not
to
http://www.company.com/sales. The problem is that the path is
case-sensitive. So if you specify "/press" and your user types in "/Press",
the cookie will not be sent. This is why the path should always be set to
"/".
3) If you do not set an expiration date, the cookie is a "session
cookie". It will only last during the current browser session. Most users
browsers will be set to accept session cookies from sites they visit, but
some will not accept "permanent" cookies (I don't recall the opposite of
"session" in this context!). Session cookies do not show up in Temporary
Internet Files. When I have to be sure about whether and how a cookie is
being set, I use a tool like ProxyTrace from
http://pocketsoap.com to watch
what headers are actually sent.
Are you using the cookie name "AdminAuth" in any other part of your web
application, or in some other web application? As an experiment, try
changing the name of the cookie in web.config.
I'd also suggest you add some extra tracing code in your Page_Load. Write a
"TraceCookies" subroutine to display the details of the cookies in the
Request.Cookies collection. Be sure to display the name, domain, path and
expiration. Using Page.Trace.Write to do this will add it to the same place
you're seeing the cookies collection now. Don't worry about the
Request.Headers collection for now.
I also suggest you limit your experimentation to a single set of pages and
that you follow the same sequence each time. Start, try page requiring
authentication, get sent to the login page, log in, and get bounced back to
the login page. Once you get this simple case to work, you can complicate
things by seeing what happens with different pages, but for now, I'd keep it
simple.
--
John Saunders
Internet Engineer
(e-mail address removed)
Jeff Johnson said:
Well, if I remove the path, I just get bounced back to the login page again
after being forwarded. The cookies collection and headers (shown with Trace
enabled) show no auth cookie being set or transferred.
But...I just tried using SetAuthCookie instead of ReDirectFromLoginPage with
omitting the path and the cookie is showing up in the cookies collection but
not in the headers collection... and when I manually navigate to another
page I get bounced back as well. I don't know much about the relationship
between the cookies collection as shown in the trace and the headers). I
assume that if something is in the cookies collection but not returned from
the browser on the next page it disappers from the cookies collection as
well?
When I omit the path, I'm also getting two entries showing in the cookies
collection, one of them blank:
Cookies Collection
ASP.NET_SessionId nbduxfa22dzcmr55qzv5byqp42
AdminAuth
AdminAuth 10E1C44CA2D4F5139EDACF20704831B84BC372B0...
If I add the path back in "/" then I get one entry for the auth cookie in
both the cookies collection and header cookies ... but no signout (as
described previously).
And more ideas?
TIA
site.
I've what
Response.Redirect(ConfigurationSettings.AppSettings["SiteAdminAddress"],true