Garden Management, Part 3 – Azure Blob Storage
This is the next step of the implementation of the sample application for Garden Management. In part one and two, we already solved the circles for
- SQL database and an Azure WebApp including TableController for database access
- MobileClient implementation with offline synchronization of the sql database
So, in this third part, it will be about using Azure’s blob storage to store and retrieve files. The tricky part is not to permit total storage access to the clients, for obvious reasons…
- Risk of deletion of data
- Extremely high traffic that could interrupt availability or increase hosting costs
- Big amounts of data that can fill up the storage and/or increase costs
So for this, Microsoft offers ‘shared access signatures’ which is like a token that allows you to access the storage directly, but with restrictions that were defined when generating the signature. These restrictions can also contain an expiration time or an IP range for authorized clients. For a more detailed descriptions of SAS go visit the Microsoft documentation about it.
So our backend (WebApp) will provide an endpoint to obtain a SAS for a specific part of the storage (Microsoft calls this the “SAS Provider Service”). And in the client implementation, we provide a function that gets a SAS from the service and creates a blob container instance. Let’s get started…
- Azure portal – create storage
- Storage account – Access keys – copy one of the connection strings
- App Service Data connections – Add connection string ‘MS_AzureStorageAccountConnectionString’
- Add the same connection string in the Web.config of your service project, so you can run the server locally (IIS or IIS Express) and still use the real storage
- You could also setup a local storage emulator and run the service against that
- Receives the Id of a garden object, only if it exists in the database, access to the blob storage is granted
- A directory for this garden and a SAS for it is created
- Implementation: GardenController.cs
- Call the token endpoint and to create an instance of a MobileServiceClient using the given URL
- Implementation: GardenOnlineClient.cs
- This implementation could be improved, to create a facade around the Blob container. Now, any implementation using this functionality also has a dependency to the WindowsAzure.Storage. The implementation could just give a list of file URLs from the blob storage, and offer functions to upload files.
- Create a test method ‘GetGardenBlobTest’ in GardenOnlineClientTest.cs
- Implementation: GardenOnlineClientTest.cs
- The test creates a garden, and then retrieves a blob container instance for this garden
- Sub directories, files and file contexts are written
- All directories, files and the file context are being read and checked (Assert)
So now, we solved the access to the blob storage using a Shared Access Signature, which allows direct communication to the blog (without moving all the read/write data through the service. And still, the access can be limited to what the client needs at this moment.
When generating the SAS in the service, the restrictions can also depend on the current user (role and rights that he has). But for this, the authentication and authorization has to be solved first… which will be subject in the fourth part of this series.
So long…
HAPPY PLANTING