FormsAuthentication.RedirectFromLoginPage alternative?

[Ben Fidge]

Is FormsAuthentication.RedirectFromLoginPage the only way to populate the
HttpContext.Current.User.Identity.Name property?

A base class for each page contains the follwoing property:

public int CustomerID {
get {
try {
if (HttpContext.Current.User.Identity.Name != "")
return Convert.ToInt32(HttpContext.Current.User.Identity.Name);
else
return 0;
}
catch {
return 0;
}
}
set {
FormsAuthentication.RedirectFromLoginPage(value.ToString(), false);
}
}

Is there are more direct way of storing the ID of the logged in user,
without invoking the "redirect from login page" functionality? I have my own
logic for redirecting on successfull login.

I don't use a dedicated login page, instead I have a user control on the
right of every non-secure page, which houses login/password controls. This
control is then dynamically replaced with another control, after a user has
logged in and wants to visit secure pages (checkout, account details etc).

Bascially, I want to use Forms Auhtentication without a dedicated login
page, and without having to redirect when I set my CustomerID property to
the ID of a given customer.

I know this is fairly non-standard, but my client is very insistent on
having it his way.

Kind regards

Ben

 

[Karl Seguin]

You can use FormsAuthentication.SetAuthCookie(value.ToString(), false);

You probably need to realize that the cookie won't be set until you do
redirect/end the stream...like any good cookie...

Would that do the trick?

Karl

 

[Ben Fidge]

Cheers Karl,

I discovered that method earlier. It also occured to me about the round-trip
(server->client->server). I was using Server.Transfer to make use of
Context.Items[] to pass serialized objects between pages. When I converted
my app to use Response.Redirect it now works fine. The only caveat is that
in order to pass objects between pages (I *hate* querystrings) I've got to
use Session[] now.

Thanks for the info anyway!

Ben