The reason for this change in the DataCacheSecurity constructor is to reduce the time that an unencrypted string remains in memory. The expectation is that a user will read an authentication token in an encrypted file, and then construct the SecureString from it.

While this is well and good, it does make for some challenges when developing against the APIs. Consequently, you may want to create a method that takes your authorization token string and returns a SecureString.

Note: Only use this method when you don’t need the to ensure that the authorization token stays out of memory. In many ways, the below method defeats the purpose of SecureString.

Here’s what the method can look like:

Code Snippet

static private SecureString createSecureString(string token)

{

SecureString secureString = new SecureString();

foreach (char c in token)

{

secureString.AppendChar(c);

}

secureString.MakeReadOnly();

return secureString;

}

Now, from your application, you can simply call this method and return the SecureString authorization token …

Code Snippet

SecureString authorizationToken = createSecureString("TOKEN");

… which you can then pass into the *DataCacheSecurity *constructor (as outlined in this post).

While this does incur some overhead, it is pretty minimal since you should only construct the DataCacheFactory once during the application life time.