CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Csla.ApplicationContext.User Always empty at MvcApplication_AuthenticateRequest

rated by 0 users
Answered (Verified) This post has 1 verified answer | 5 Replies | 2 Followers

Top 500 Contributor
25 Posts
jpmir posted on Thu, Jun 28 2012 8:25 PM

Hi,

I'm doing some research on MVC and started by following instructions from Using CSLA 4: ASP.Net MVC E-Book...

Right after login process, AuthenticateRequest event is raised on Global.asax which is fine, but the thing is that at this point, the Csla.ApplicationContext.User object is always Empty, even when login ends up right.

Any idea ?

 

Thanks in advance!

Jean Paul 

 

 

Answered (Verified) Verified Answer

Top 10 Contributor
9,282 Posts
Verified by jpmir

It won't always be null. It can be a principal that points to a FormsIdentity if your web site is configured to use forms authentication.

If you configure your web site to use forms authentication then ASP.NET will automatically create a super-small FormsIdentity object for your app. It will also automatically recreate this identity object on each page request by pulling the user id out of the ASP.NET authentication cookie.

Of course this FormsIdentity is basically useless to you because it won't have your roles or other custom data. But it will have the username, so you can use that to recreate your own identity object.

And this will only exist at all if you are using forms authentication, otherwise ASP.NET won't instantiate the object at all.

Well... That's not entirely true either, because you can also configure ASP.NET to do impersonation, in which case it would be a WindowsIdentity.

Rocky

All Replies

Top 10 Contributor
9,282 Posts

You have to set Csla.ApplicationContext.User to a value in global.asax, it is not automatic.

As you know, web servers don't maintain anything in memory from page request to page request (unless you use Session). So at the start of each page request, it is entirely up to you to restore values like ApplicationContext.User to a meaningful value.

Rocky

Top 500 Contributor
25 Posts
jpmir replied on Mon, Jul 2 2012 2:58 PM

Thanks Rocky,

I finally got there somehow... But I'm still confused about this specific section of the Ebook. (Revision: 0.2 (Draft))

Chapter 3 Page 86:

 

The Global.asax.cs file contains the following code:

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
    if (Csla.ApplicationContext.User != null &&
       Csla.ApplicationContext.User.Identity.IsAuthenticated &&
       Csla.ApplicationContext.User.Identity is FormsIdentity)
       {
           ProjectTracker.Library.Security.PTPrincipal.Load(Csla.ApplicationContext.User.Identity.Name);
       }
}

If Csla.ApplicationContext.USer will always be null, What's the point of this piece of code?

I did this (In Visual Basic):

 

Private Sub MvcApplication_AuthenticateRequest(sender As Object, e As System.EventArgs) Handles Me.AuthenticateRequest
        Dim authCookie As HttpCookie = Request.Cookies(FormsAuthentication.FormsCookieName)
         If authCookie IsNot Nothing Then
             Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(authCookie.Value)
              If ticket IsNot Nothing AndAlso ticket.Name <> String.Empty Then
                 MultiCob.Infrastructure.Security.MultiCobPrincipal.Load(ticket.Name)
             End If
         End If
  End Sub

 

 

 

 

Top 10 Contributor
9,282 Posts
Verified by jpmir

It won't always be null. It can be a principal that points to a FormsIdentity if your web site is configured to use forms authentication.

If you configure your web site to use forms authentication then ASP.NET will automatically create a super-small FormsIdentity object for your app. It will also automatically recreate this identity object on each page request by pulling the user id out of the ASP.NET authentication cookie.

Of course this FormsIdentity is basically useless to you because it won't have your roles or other custom data. But it will have the username, so you can use that to recreate your own identity object.

And this will only exist at all if you are using forms authentication, otherwise ASP.NET won't instantiate the object at all.

Well... That's not entirely true either, because you can also configure ASP.NET to do impersonation, in which case it would be a WindowsIdentity.

Rocky

Top 500 Contributor
25 Posts
jpmir replied on Mon, Jul 2 2012 3:14 PM

OK, but basically there's no loss in my approach... I mean, I'm doing "by hand" what the best configuration scenario might offer me in this case.

Do you agree?

Thanks for your time and cooperation!

Top 10 Contributor
9,282 Posts

Yes, right.

Rocky

Page 1 of 1 (6 items) | RSS

Copyright (c) 2006-2010 Marimer LLC. All rights reserved.
Email admin@lhotka.net for support.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems