Updating to Csla 7 - DataPortal.DataPortalInvoke #3787
-
|
I didn't see any questions about DataPortalInvoke, the static event that existing in prior to Csla 6 I guess. Is it just gone? Is there an alternate method to hook into for every data portal call? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
|
The new data portal is instanced, not static, and so there is no central way to do that sort of thing using events. At least not a safe way in terms of memory leaks. On the server side the interceptor concept provides a rich way to be part of the processing pipeline. On the client side, the best way to hook into all data portal calls is to create an use a custom proxy (subclass of whatever proxy you are otherwise using). |
Beta Was this translation helpful? Give feedback.
-
|
I suppose that creating a proxy subclass isn't terribly elegant. Perhaps we should consider a client-side interceptor model like we have on the server? Presumably this is primarily for logging? |
Beta Was this translation helpful? Give feedback.
-
|
@rockfordlhotka In our app when user logs in we build a session object that has all their permissions (this is way before claims). We return that object to the client with a secure RNG key. When requests come to the server, we use that key to avoid reloading the session, which is expensive. But we only store this session data in the web server memory (also not great, but I can't immediately address it). If the session isn't found on the web server, which happens due to recycling, then we silently re-login the user. Although a client side interceptor would be nice in general, I think our particular problem is very specific to us. I think I have come up with a workaround, but it will be some time until we have a code base that can be compiled & run again, so I don't know for sure how well it will work. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming you use http as your transport protocol. That sounds like you should use custom header to send the key back to the server. It's effectively acting like an access token. |
Beta Was this translation helpful? Give feedback.
-
|
@StefanOssendorf Yes, its an access token. The issue is not getting the token from client to server, its the fact that if the token isn't found on the server, the user is effectively logged out, so we handle that client side by logging them back in. That was previously happening in the DPI handler, but since that's gone I need to go another route. Ideally our server side session data would be out of process, but that's something we haven't been able to tackle. |
Beta Was this translation helpful? Give feedback.
-
|
It depends on the stage where you can/want to log the user back in. With ASP.Net core you have multiple ways:
|
Beta Was this translation helpful? Give feedback.
-
|
@StefanOssendorf Right, but as Rocky mentioned there is no client-side interceptor. The login needs to happen from the client side. But we do already have a subclass of HttpProxy, so I can change that to handle this for now. |
Beta Was this translation helpful? Give feedback.
The new data portal is instanced, not static, and so there is no central way to do that sort of thing using events. At least not a safe way in terms of memory leaks.
On the server side the interceptor concept provides a rich way to be part of the processing pipeline. On the client side, the best way to hook into all data portal calls is to create an use a custom proxy (subclass of whatever proxy you are otherwise using).