0

I have an ASP.NET MVC 4 application that is using CSLA.NET for a portion of our business logic. The permissions to read/write are handled through AD by a domain account, the same account as the Application Pool Identity and .NET Impersonation user. When testing on my local machine, the validation runs perfectly. Once the application is deployed to one of our test environments (dev or qa) I receive exceptions that seem to point to permissions. I've verified that the username being used by the assembly is indeed the correct user, but have been unable to set the values of any of the fields due to not having the appropriate permissions.

Anyone experienced anything like this before?

EDIT:

Link to discussion on lhotka.net forums

DeeDub
  • 1,654
  • 1
  • 12
  • 18

1 Answers1

1

Web servers are stateless, so they don't generally remember anything between page or service requests. This includes the user's identity and roles.

If you are using ASP.NET forms security (or similar) the username will be automatically recreated on the server by using the .NET authn cookie token, but that's only the username.

You are responsible for recreating the complete principal/identity object on the server for each postback/request.

The easiest way to do this is in the global.asax file, often in the authenticate request event. There are samples in the CSLA download showing how to do this, and I discuss it in the 'Using CSLA 4' ebook series.

Also any good ASP.NET book will discuss restoring the principal, because this isn't really a CSLA issue as much as a web development issue.

Rockford Lhotka
  • 842
  • 6
  • 9