IAuthorizeDataPortal - How to distinguish incoming remote calls from server-side calls over local data portal?

IAuthorizeDataPortal - How to distinguish incoming remote calls from server-side calls over local data portal?

Old forum URL: forums.lhotka.net/forums/t/8885.aspx


rsbaker0 posted on Wednesday, May 05, 2010

So, I'm having an odd problem as I start to implement IAuthorizeDataPortal.

When using a Web Service (or WCF service),  the service implementation itself uses the *local* data portal to access the BOL/Data layers layer for any "internal" DataPortal_xxx calls that it might make to satisfy an external request. 

I don't want to apply any (well, at least not the same) authorization to internal calls, only to the incoming calls from remote clients.

I don't see an obvious way in the data portal authorization implementation to distinguish one from the other. Since the IAuthorizeDataPortal provider type name is in the server side .config file, the same provider will be used to authorize both the incoming calls from remote clients, as well as the internal calls made by the service itself. The AuthorizeRequest class doesn't seem to have enough information to tell the difference between the types of calls, and the ApplicationContext ExecutionLocation and LogicalExecutionLocation are no help either (Both are alway "Server" on the server).

I see a simple change that could be made that would solve my dilemma -- I could extend the AuthorizeRequest class to also include a reference to the DataPortalContext so it is also available. However, I'd rather not do this if there is a way to tell the two types of access apart without making custom changes to CSLA.

RockfordLhotka replied on Thursday, May 06, 2010

An even simpler solution is for your IAuthorizeDataPortal implementation to put a value in Csla.ApplicationContext.LocalContext, and then look for that value on subsequent calls.

rsbaker0 replied on Thursday, May 06, 2010

RockfordLhotka

An even simpler solution is for your IAuthorizeDataPortal implementation to put a value in Csla.ApplicationContext.LocalContext, and then look for that value on subsequent calls.

If I follow you, you're suggesting that since any "originating" call for a remote data portal must (by definition) be remote, that if I authorize it, then I bypass any subsequent authorization for the duration of that call chain (e.g. any local portal calls made servicing the remote request) by putting a value in the LocalContext?

Very clever... :)

 

RockfordLhotka replied on Thursday, May 06, 2010

That's what I'm thinking - it should work quite well since LocalContext doesn't survive between server calls, but is consistent during the life of a given server call.

Copyright (c) Marimer LLC