Problems With Custom RoleProvider and Forms Authentication

  • Thread starter Thread starter Tomasz
  • Start date Start date
T

Tomasz

Hello Developers!

I have an interesting problem using my custom MembershipProvider,
RoleProvider and Forms Authentication.

Both MembershipProvider and RoleProvider require session state, where some
very important context data are stored during the Session_Start event. My
MembershipProvider and RoleProvider depend on this information.

It seems that authentication process works with no problems.
However, during the later authorization phase session state is not
available!

I found that during the login process, after a user presses the "Login"
button, events occur in the following order:

1. Application_AuthenticateRequest event fires
2. Application_AcquireRequestState event fires
3. MembershipProvider.ValidateUser() gets called
4. Application_AuthenticateRequest event fires
5. RoleProvider.GetRolesForUser() gets called

For any reason, AcquireRequestState does not fire after AuthenticateRequest
event, but before RoleProvider.GetRolesForUser() method gets called.

Is there any, even tricky, way session state can be forced to restore before
authorization?

Thank you for any hints.

Tomasz
 
Hi Tomasz,

From your description, you're developing your custom Membership and role
provider which will rely on some state information(stored in sessionstate),
however, you found the certain Application processing event doesn't get
fired in the expected sequence and the SessionData is not correctly
accessed, correct?

According to the behavior, it is the expected one due to the ASP.NET
request's server-side processing pipeline. You can refer to the following
MSDN reference about the application processing sequence(the order of those
events in server-side pipeline):


#ASP.NET Application Life Cycle Overview
http://msdn2.microsoft.com/en-us/library/ms178473.aspx

Application_AcquireRequest event does occur after
Application_AuthenticationRequest and Application_AuthorizeRequest events.
Actually, session state will be loaded only after the httphandler(used to
process the request) has been determined.

Also, one important thing is that ASP.NET Forms Authentication's user
ticket is not designed to match a session state token. For example, a user
open two browsers on client may have two different session while it can
hold the login state of a single user (against server-side forms
authentication). Would you provide some further information or code logic
on how your custom membership/role provider will rely on those stateful
data? We can try looking for some other approach to hold such state data.

Please feel free to let me know if there is anything I missed or if you
have any other concerns here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



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

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.

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



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

How are you doing on this issue, have you got any progress or does the
information in my last reply helps you a little? If there is anything else
we can help, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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

In addition to SessionState I keep some of my session context data in
FormsAuthenticationTicket.UserData, so it is available during authorization.
It is not a perfect solution, but it works.

Sincerely,

Tomasz
 
Thanks for your followup Tomasz,

Yes, the FormsAuthenticationTicket.UserData is a reasonable storage for
caching some small and simple data which need to keep between multiple
requests of an authenticated user context. Also, since this data will be
available right after the server-side get the Ticket from client cookie, it
is safe to use it at the ealier stage of server-side processing
pipeline(compare to other storage such as session or profile service).

Anyway, if you meet any new problem or have anything else we can help,
please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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

The only problem with this approach I noticed so far is that
CreateUserWizard control clears FormsAuthenticationTicket.UserData after
when user gets created.
How, why, what for? - I have neither clue not time to further investigate.

Sincerely,

Tomasz
 
Thanks for your reply Tomasz,

For the behavior that CreateUserWizard clear the current
FormsAuthenticaitonTicket, here is the answer:

CreateUserWizard control has a property named "LoginCreatedUser", this is
set to "true" by default. Thus, whenver you succesfully create a new user,
the CreateuserWizard will use the following code to login:

FormsAuthentication.SetAuthCookie(this.UserNameInternal, false);

Thus, the original forms Authenteication context(Ticket) is
replaced(UserData is lost).

#CreateUserWizard.LoginCreatedUser Property
http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.createuse
rwizard.logincreateduser.aspx

You can set this property to "false" so as to make it not automatically
login the new created user.

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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