Creation of Azure storage from connection string failed for shared key credentials

[AloisMaierhofer]

the creation of a Azure file or blob storage instance failes if doing so via StorageFactory.Blobs.FromConnectionString

Reason:
The factory uses FluentStorage.ConnectionString.StorageConnectionString internally to parse the connection string. For each property value the method UrlDecode is called by the Parse method. This makes a lot of sense to be able to pass special characters in passwords.

The Azure account key is Base64 encoded, though. If it contains + characters, those get replaced by spaces, other characters might also get replaced falsely. Therefore the Azure account key must not be tampered with.

One workaround would be to store the account key urlencoded in the connection string in the application configuration - not very user friendly, its base64 already...

The StorageConnectionString on the other hand side has no knowledge if the secret key is urlencoded or base64 encoded... not sure how to solve this.

Maybe it would make sense to mention the url-encoding for passwords in the documentation.

[sfmskywalker]

I ran into this just now. Thanks for the tip to store the account key as URL encoded, that worked!

[robinrodricks]

Which API needs to change? Can you describe the change required?

[sfmskywalker]

Hi @robinrodricks, absolutely. Let's take a look at the following screenshot for context:

Notice line 131, where every part of the connection string is always URL-decoded. This becomes problematic when using a key like the following (which is a base64-encoded Azure Storage Account key):

aGi**********************************************************************f0e+CZ2aH+A*******xg==

During URL-decoding, the + characters are replaced with spaces. Later on, this value is passed to the Azure Blob Storage module, which tries to base64-decode it:

As @AloisMaierhofer pointed out, we can work around this by URL-encoding the key, which will then be decoded correctly by the StorageConnectionString class.

However, I’m unsure whether the StorageConnectionString should be responsible for URL-decoding at all. My first question would be: Should this responsibility lie with StorageConnectionString, or should it be up to the application's configuration to handle this?

[sfmskywalker]

It would appear that this issue is essentially a duplicate of #42.

[robinrodricks]

@sfmskywalker What if the StorageFactory.Blobs.FromConnectionString API (which according to my understanding is the broken one) automatically detects if the string is encoded or not, and accordingly encodes it so that the decoding later on in the pipeline works as expected?

[sfmskywalker]

@robinrodricks I think that's the ideal solution: it's user friendly and it's simple 👍🏻
I can propose a PR shortly if you like.