O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
What Are Shared Access Signatures?A Shared Access Signature is a URL that grants access rights to containers, blobs, queues, and tables. By specifying a Shared Access Signature, you can grant users who have the URL access to a specific resource for a specified period of time. You can also specify what operations can be performed on a resource that’s accessed via a Shared Access Signature. In the case of Blobs operations include:-- Reading and writing page or block blob content, block lists, properties, and metadata-- Deleting, leasing, and creating a snapshot of a blob-- Listing the blobs within a containerWhy not just use the storage account name and key directly?There are a few standout reasons:-- Security – When building device applications you should not store your storage account name and key within the device app. The reason is that it makes your storage account susceptible to being misused. If someone were to reverse engineer your application take your storage account key then they would essentially have access to 100TB of cloud based storage until such a time that you realized and reset the key. The safer approach is to use a SAS as it provides a time boxed token with defined permissions to a defined resource. With policies the token can also be invalidated/revoked-- Scale Out (and associated costs)- A common approach I see is uploading an image directly through their web tier e.g a Web API or Mobile Service unfortunate consequence of this at scale is that you are unnecessarily loading your web tier. Consider that each of your instances on your web tier has a limited network I/O. Uploading images directly through this will result in maxing out that I/O and the need to scale out (add more instances) much sooner then alternative approaches. Now consider a scenario where your application requests only a SAS from your web tier you have now moved MBs or image load off your web tier and instead replaced it with a small ~ 100 – 200 byte SAS. This essentially means a single instance now will provide much more throughput and your upload I/O now directly hits the Blob storage service
Let Perficient’s Healthcare team be your rapid response to jumpstarting your 4010 to 5010 migration! We appreciate your time today and now we will take questions. While you are creating your questions in the chat window, I want to get you thinking about these questions as well.
Developing Mobile Solutions with Azure and Windows Phone VSLive! Redmond 2013
Developing Mobile Solutions
with Azure & Windows Phone
Who am I?
MVP, Visual C#
Director at Perficient
Co-host of Deep Fried Bytes Podcast
@cwoodruff / firstname.lastname@example.org / Skype: cwoodruff
• Overview of SQL Azure Mobile Services
• Understand Benefits of SQL Azure Mobile Services
• Introduction to Azure Mobile Services
• Demo Azure Mobile Services
• Understand Mobile Services Push Notifications
• Demo Mobile Services Push Notifications
• Why does Windows Azure Mobile Services benefit your projects?
• Wrap Up
Storage with Mobile
1. Request a Shared Access Signature
(SAS) from your service
2. SAS returned from your service
3. Upload blob (image/video/binary
data) directly to Blob Storage using
4. Storage service returns response