Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > asp:Login and registering user with Membership

Thread Tools

asp:Login and registering user with Membership

Posts: n/a
I have a Server.Transfer in my asp:Login LoggedIn event handler. I am forcing
transfer to a specific page since I do not want to use the ReturnURL that is
in Request.Params (i.e., the user addressed some particular page and was
redirected to the login form and would be returned there.).

The control's DestinationUrl is only used if the login page was the original
target of the request.

In the event handler, HttpContext.Current.User.Identity.Name is empty. So,
when I go to the target of the Server.Transfer, Membership.GetUser() returns
null. Apparently, user information is not set into the sesssion until after
the request completes.

Unfortunately, I want to use Role information to configure the apps real
home page. I am using Membership and Roles throughout the app and would like
to be consistent here. Currently, no page gets any info about the user except
through Membership, and I'd like to not be passing the name around.

My guess is that Membership is carefully designed not to let you plug a name
into it.

Maybe the LoggedIn event should be renamed to the AlmostLoggedIn event.


Reply With Quote
Steven Cheng[MSFT]
Posts: n/a
Hi Marc,

Regarding on the Login control(LoggedIn event) and membership service
behavior you mentioned, I think it is the expected one due to how the
FormsAuthentication issue authenticate ticket and retrieve it back at
sequential requests.

When the user click "login" button of the ASP.NET application login
page(secured through forms authentication), the following occurs:

1. Login control look for the membership provider and use it to verify the
username/password credentials

2. If validate success, it will generate authentication ticket and store it
into response's cookie collection

3. use response.Redirect to forward the user to the original requested
page(or the default page which can be configured in Formsauthentication

For your case, you use "Server.Transfer" to forward the user. Then, because
server.transfer does not return to client-side, so the
authentication-ticket(cookie) hasn't been able to store in client cookie,
and request also doesn't go through the Forms AuthenticationMOdule which
will populate the Context.User.Identity(from authentication ticket).
That's why you can not get the Context.User.Identity if you use
"Server.Transfer" after LoggedIn.

One way to overcome this problem is use Response.Redirect instead of
Server.Transfer. This make the a client-side redirection which can ensure
the authentication ticket(cookie) be persisted and updated, and the new
redirected request will got through the FormsAutheitcation Module that
help correctlyl populate the Context.User.Identity property. How do you

Hope this helps.


Steven Cheng

Microsoft MSDN Online Support Lead


Get notification to my posts through email? Please refer to

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at


This posting is provided "AS IS" with no warranties, and confers no rights.

Reply With Quote
Posts: n/a
Perfect Steven - Thank you.

I'd forgotten that I used the Server.Transfer as an "optimization" (as
recommended in many books) in order to avoid what appeared to be a
useless round trip. Apparently, it isn't useless after all.

Would have been nice if the docs on the LoggedIn event identified the issue.


Reply With Quote
Steven Cheng[MSFT]
Posts: n/a
Thanks for your reply Marc,

Yes, I agree that Server.Transfer will avoid client-side roundtrip and in
most cases(if it won't affect your application logic), you're recommended
to use Server.Transfer instead of Response.Redirect. The Login control here
should be a particular case .

Also, for the document, there does have some incompleteness in the current
MSDN product document, however, the MSDN web document now support adding
user community comments. You can add your comment on this in the following
document page(in the bottom):

#Login.LoggedIn Event

In addition, if you have any more specific feedback or requests, you're
welcome to post in our product feedback center:

Thanks for your feedback!


Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
registering user controls in web.config, causes error if used in same directory... Tim_Mac ASP .Net 6 08-04-2010 02:10 PM
Membership permissions after publishing an ASP.NET Membership site. Tino Donderwinkel ASP .Net 2 06-18-2008 08:16 AM
Re: registering/re-registering ASP.NET 1.1.4322 with IIS Juan T. Llibre ASP .Net 2 12-16-2006 12:29 AM
Registering user control programmatically Sharon ASP .Net 1 04-18-2006 10:44 AM
Registering new user should I use formview/detailsview or my own custom fields? Steve ASP .Net 0 09-19-2005 02:44 PM