By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,706 Members | 2,030 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,706 IT Pros & Developers. It's quick & easy.

asp:Login and registering user with Membership

P: 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.

Thx

Marc
Mar 22 '07 #1
Share this Question
Share on Google+
3 Replies


P: 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
setting)
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
think?

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

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

Mar 23 '07 #2

P: n/a
Perfect Steven - Thank you.

I'd forgotten that I used the Server.Transfer as an "optimization" (as
recommended in many asp.net 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.

Marc

Mar 23 '07 #3

P: 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
http://msdn2.microsoft.com/en-us/lib...rols.login.log
gedin(VS.80).aspx

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

http://connect.microsoft.com/feedbac...spx?SiteID=210

Thanks for your feedback!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Mar 26 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.