Because of security restrictions, the type Csla.Server.DataPortalContext cannot be accessed

jspurlin posted on Wednesday, September 13, 2006

Oh lordy. You are going to have to put me away in the neophytes section of the forum.

So far, the problems have been typographical: using the same casing for Csla, for example.

In this case, this is all there is to the stack trace:

[SecurityException: Request failed.]

So I have been looking for typos. I did update the dll's to the most recent version. I went project by project to update the references to the right version of Csla. I will do this once more to make 'absolutely sure' a version conflict isn't to blame.

Anyway, any advice on this would be appreciated.

ajj3085 replied on Wednesday, September 13, 2006

Did you check the innerexception property?

guyroch replied on Wednesday, September 13, 2006

Is your Csla assembly signed with a .snk file?

Programs that run on the CLR use something called code access security (CAS). CAS is different from traditional security systems in that it assigns trust to code rather than users. To do this, the security system gathers a set of evidence about every assembly it loads. This evidence is then compared against the security policy, and a permission grant is generated.

One of the pieces of evidence that the security system gathers is the security zone that the code is running from. When you run the code from your local machine, this will be the MyComputer zone, but when you run it off of a server, or even a network share mapped to a drive on your machine, it will be the LocalIntranet zone.

By default any code that is run from the MyComputer zone will get a permission set of FullTrust (unrestricted permission to do anything it pleases). However, by default, there is a more restrictive permission set given to LocalIntranet assemblies.

The way to make an application that works from the MyComputer zone work from the LocalIntranet zone is to give the assemblies in your application a strong name, and modify the security policy to trust this strong name. Hence the need for a key.

In CSLA, all of the data portals such as DataPortal and ServicesDataPortal runs in LocalIntranet zone.  And because in CSLA 2.x they are all included in the same Csla.dll assembly, this Csla.dll assembly needs to be signed with a .snk files.  However, Rocky did provide a key in Csla 2.x whereas he did not in Csla 1.x - you had to create one yourself.

I doubt that you removed this .snk file wihtout noticing it, but just thought I'd bring it forward just the same.

Hope this helps

RockfordLhotka replied on Wednesday, September 13, 2006

You didn't somehow remove the bits in the server config file that configure Remoting as shown in the book and sample projecttracker app? There are a couple lines in the config file that loosen serialization security over remoting so you can serialize complex, custom types.

      <channels>
        <channel ref="http">
          <serverProviders>
            <provider ref="wsdl"/>
            <formatter ref="soap" typeFilterLevel="Full"/>
            <formatter ref="binary" typeFilterLevel="Full"/>
          </serverProviders>
        </channel>
      </channels>

If these are missing you'll get some odd security exceptions.

Also, you are running the server-side code under FullTrust and not some sort of partial trust policy right? CSLA requires FullTrust to work.