Question

I’m new with AppFabric Server caching but after playing around with it everything has been working like a dream.
I can add for example datatables to my cache and get that back to use just fine.

I got exited about this functionality and tried to test this with one 3rd party vendors dll that includes login session data (session id, date’s etc.)

I created WCF service with method where you consume this dll to login and I store that session to my cache.
This works just fine and I can verify this by looking at statistics of my cache with PowerShell.
Then I created another method that is supposed to pick up this cached session and use it to execute actions. This is where I’m running to the wall.

I can see that I have been able to get session from cache, but information within session object is null (session id, date’s…)

I’ve been serching help for this from everywhere but nobody seams to face this issue.
So my question is

1. Can AppFabric server cache ALL field values of given object (Public/Non-public not having any role)?
2. Is there any way to see actual existing content of cache where you would see keys and cached objects with values?

Thanks for all possible comments!

Regards
Mikko

Answer 1

In AppFabric you can only cache objects that are serialisable (or serializable for US readers 🙂 ). The fact that you have been able to store your session objects in the cache suggests that they are indeed serialisable. But to figure out what’s going on here we’ll need to probe a little deeper.

By default with binary serialisation, all fields/properties of an object are serialised, public and private (whereas XML serialisation only picks up the public values). We aren’t told which flavour of serialisation AppFabric uses, but binary serialisation tends to be more efficient so it’s a reasonable assumption that that’s what gets used under the covers. However, it’s possible to override the serialisation behaviour using the NonSerialized attribute, so that items marked NonSerialized don’t make it into the serialised version of the object. The MSDN page for Selective Serialisation specifically advises that security-sensitive information should be marked as nonserializable.

A session ID definitely comes under the heading of security-sensitive information as it’s key for session hijacking, so I should say that’s the problem you’re facing. You could confirm this by having a look inside the 3rd party DLL with ILDasm or Reflector to see if the fields inside the session class are indeed marked as not serialised.

Can you get round this? Well there is, of course, nothing to stop you creating your own Session class that you populate from the 3rd party’s object where you keep all the properties serialisable and caching that instead. Bear in mind, however, that you’re then essentially doing the very thing they’ve tried to stop you doing…