Metro App - Binding error on field "id"

After Visual Studio 2012 was launched one of the first things that I tried was to write a Metro App in Java Script. I started to write an application that get an Azure Table content and display it in a grid. Of course to be able to display data from a source we need to define a data structure.
So, I started to define a list with some items that I binding to the UI.

var myItems = [
 { id: 1, name: "Tom", age: 20},
 { id: 2, name: "Jack", age: 23},
 { id: 3, name: "Maria", age: 19},
];

After I bounded the data to the UI I hit F5 and surprise. Visual Studio hit me with an error that doesn’t give you any kind of information about the cause of the error.

{
  "exception":null,
  "error":
  {
    "description":"Null item"
  },
  "promise":
  {
    "_value":
    {
      "description":"Null item"
    },
    "_isException":false,
    "_errorId":3
   },
   "id":3
}

This error is thrown by terminate application handler function. Because of this we cannot see any information about the exact line of the error. In the first moment I checked to see if the id field is null or if I bounded correctly, but everything seems to be okay.
The next thing that I tried was to rename the id field to something else. In my case I replaced with a field named “key”. When I hit F5 I was surprised that everything was up and running.
In conclusion, when you are using data that are binding to the UI, don’t use reserved names for the fields like “id”.

Read More

Trace information to Windows Azure Azure Tables

I saw that there are a lot of people that use tracing infrastructure that is offered by .NET framework to trace information in Windows Azure Tables. Basically, after we configure the configuration file, the only thing that we need to do is to call the Trace class and write data to it.

Trace.WriteLine(“Some  trace data”);
Trace.TraceWarning(“Some worning information”);
Trace.TraceError(“An error that appeared in the application.”);

We can do a log of thinks with this class. It is not something new.
In the configuration file of our application we need to add a new trace listener that is able to write all the trace information to Azure Tables.

<system.diagnostics>
    <trace>
      <listeners>
        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics”  name="DiagToAzureTables"></add>
      </listeners>
    </trace>
  </system.diagnostics>

Next step is to add the listener to the trace listener collection each time when your application start. At this step I prefer to set auto-flush to true. In this way all the content will be send automatically to the trace and the risk to lose data when the machine is instable and crash is very low.

System.Diagnostics.Trace.Listeners.Add(myListener);
System.Diagnostics.Trace.AutoFlush = true;

On the internet you will find a lot of implementation of trace listener. The one that I prefer to use is the most common one. One of the implementation can be found in the following location http://www.wou.edu/~rvitolo06/WATK/Labs/WindowsAzureDebugging/Source/Assets/CS/AzureDiagnostics/TableStorageTraceListener.cs
If we check the Azure Tables of our account we will see that a new table was created with the following structure:

• PartitionKey - D10 of event timestamp >> 30
• RowKey - D19 of event timestamp
• EventTickCount – event timestamp
• Level - event type
• EventId – event id,
• Pid - event process id
• Tid - event thead id
• Message - event message

After a time you will observe that the EventTickCount can have different values, that are not orders based on the timeline. This is happen because the event timestamp is based on Stopwatch.GetTimestamp() method. This method don’t guaranty to us that will get a higher value in time. The purpose of Stopwatch is to measure time interval and calling GetTimestamp method return the current value of the counter (this is not correlated with the current date of the system) -

is correlated to the time when the system/process have been started.

Remarks: Base on the hardware configuration we can have a frequency tick per second or per nanoseconds. We can determine what is the frequency using StopWatch.Frequency.
If we want to order events based on the event tick count, we need to be aware that this will be valid only for events that were generated by the same processor (Pid). For different processor on the same machine the EventTickCount can be different.
Never try to order all the event of a Trace table from Windows Azure based on the EventTickCount. You can use it in combination with Pid. Also, the TimeStamp column of Azure Table store the time when the message was written to Azure Table and not the moment when the event was generated.

Read More

Windows Azure Websites - Shared and Reserved mode

I think that we all of us already heard about Windows Azure Websites. This new feature of Windows Azure offers us the possibility to deploy websites very fast. Even for the first deploy, the deploy time can be very low.
What I would like to talk about today is the two different modes of Websites. The first one is Shared Website Mode. What does it means is that we don’t have a dedicated compute power. All the processor power is shared between our websites and other websites. From the performance perspective the performance will not be great. Is like hosting the websites to a classic hosting, that for 400$ per year host your application on IIS.
The other mode is the Reserved one. For this case we have dedicated resources that are allocated only to our application. We don’t share processor, memory or anything else. For this case we have 3 types of sizes (Small, Medium, Large) that we can set. Also we can specify the numbers of reserved instances from 1 to 3.
An interesting thing at Reserved mode is that even if we have dedicated resources we don’t have control to the machine. Our application is hosted on the IIS. This is why when we create a website on Windows Azure, the initializing time is very very low. For each reserved size, in this moment we have the following resources allocated: 1, 2, 4 cores and 1.75, 3.5, 7GB memory. The storage space is the same for all, 10GB.
Let’s wee when we could use Shared and Reserved mode. For the case when we create a demo application, or we have a blog or a site that is not very visited we can use Shared mode. When the traffic increases we should go with Reserved mode. A nice there will be a moment when we will not be able to use the website because our application need more resources and we will need to use a web role. The switch between them is not so simple if we didn’t use a web role until now. In the future I expect some tools that will make this migration automatically for users.

Read More

How to use local configuration in a Metro App

Today I want to talk about where we can store application configuration in a Metro App for Windows 8. Basically, we don't have app.config file and because of this we need to "re-learn" how to store the application configuration.

The entire configuration can be stored in the application storage under "LocalSettings". The default location where we can store and retrieve the configuration data is "Windows.Storage.ApplicationData.Current.LocalSettings". In the next example we add "MaxValue" to the LocalSettings and after that retrive it:

Windows.Storage.ApplicationData.Current.LocalSettings.Values["MaxValue"] = 100;
string maxValue = Windows.Storage.ApplicationData.Current.LocalSettings.Values["MaxValue"] = 100;

Another thing that we can do with the LocaSettings is to create containers that can be used to group different settings. We can create unlimited number of containers with different settings. We cannot have two different containers with the same name, but we can have in two different containers items with the same name.

LocalSettings.CreateContainer("MyContainer", ApplicationDataCreateDisposition.Always);
LocalSettings.Containers["MyContainer"].Values["MaxValue"] = 100;
LocalSettings.CreateContainer("FooContainer", ApplicationDataCreateDisposition.Always);
LocalSettings.Containers["FooContainer"].Values["MaxValue"] = 100;
var maxValueFromMyContainer = LocalSettings.Containers["MyContainer"].Values["MaxValue"];
var maxValueFromFooContainer = LocalSettings.Containers["FooContainer"].Values["MaxValue"];

In this example I created two containers and added a configuration item.

What we should know about these configurations is that they are persisting between sessions. We need the values of them only for the first time when the application is started. After this we will be able to retrieve this data from the settings. We don't need to load this value from a configuration file and set them.

Don't forget that this functionality exists.

Read More

Shared Access Signature and URL encoding on Windows Azure

Playing a little with Shared Access Signature was quite nice. In this moment this new functionality has a great potential. Playing a little with it I found an odd bug that I introduce from the code. From the start you need to know that this bug was generated by me and the cause of it was not Windows Azure.
Normally after we generate the access signature we are adding it to the URL that we want to access and we get a code similar to this:

var accessSignature = myTable.GetSharedAccessSignature(…);
string accessURL = tableAccessURL + … +  accessSignature;
Uri accessUri = new Uri(accessURL);
string myAccessLink = accessUri.ToString();

The only problem here is that the accessSignature can contains specials characters like ‘=’ or ‘+’. This kind of characters needs to be encoded in the URL. Because of this from time to time we will get an URL that is not valid. In my case last time I got an access signature that contained this kind of specials characters for 4 times in a row. Because of this we cannot accept this kind of solutions.
A better way to get the string of an Uri object is to use AbsoluteUri for example. Or any other method that know to encode the URL characters. Using this method we will not need to worry about encoding problems. The code should look like this:

var accessSignature = myTable.GetSharedAccessSignature(…);
string accessURL = tableAccessURL + … +  accessSignature;
Uri accessUri = new Uri(accessURL);
string myAccessLink = accessUri.AbsoluteUri();

Another solution for our problem is to use “EscapeUriString” method of the uri. This will do the same think for us.
In conclusion we should be carefully about how we convert any kind of Uri to a string and know very well what kind of characters can appear in it. If the URL that is generated doesn’t need to be read by a user I will also try to escape the uri string using any solutions that is available.

Read More

Accessing hardware configuration from a Metro App

When we create Metro Apps for Windows 8, we could imagine some scenario where we would like include some device resources information like CPU or memory usage.
The bad news is that we cannot get this data from the device. And yes, Windows 8 works as expected. We need to realize that a Metro App run on Windows 8 in a very isolated environment. The application don’t need to know one what environment run, how many memory is used by the system and so on. The lifetime of the Metro App is controlled by the operating system and all the resources that an application can need are offered by the system.
Remember? A Metro App should do only one think, but it should do this think best. In this moment I cannot imagine extreme Metro Apps, like some other desktop application that can do almost anything. If we realize that we work at a Metro App that do to many thinks, that a good idea is to split it in 3,4 or why not 10 applications. When we have a user that accesses our application, we don’t want to have a user that is lost in 97 functionalities. In the moment when he opens the Metro App we want to let him to do only one thinks, without any problems. I have nightmares with desktop applications that were so complicated that I could not remember how I can submit my time report or what I can send a message to admin.
Even if we cannot obtain real time information, we can query the operating system about what kind of processor have, what other devices are connected to our device or what printers are installed.
Let’s see what information can we access and how. The PerformanceCounter don’t exist anymore in Metro Apps. It can be found only in desktop applications. We still have functions named GetNativeSystemInfo that can be used only for applications that run on x64. But you will not be able to extract a lot of information from there. Don’t expect to be able to retrieve the processor load or memory level.
What I tried to use to get information about the device was DeviceInformation.FindAllAsync(…). This is the official way that can be used to get device information. The first parameters that need to be specified are the interface GUID. Based on this GUID specific information will be loaded. Some GUID values that can be used are:

• {0ECEF634-6EF0-472A-8085-5AD023ECBCCD} – Printer interface
• {6AC27878-A6FA-4155-BA85-F98F491D4F33} – External devices connected (portable devices)
• {E5323777-F976-4F5B-9B55-B94699C46E44} – Webcam interface

In general the second parameter will remain NULL, but it can be useful when we want to filter the result based on object property.

var printers = await DeviceInformation.FindAllAsync(
      “{0ECEF634-6EF0-472A-8085-5AD023ECBCCD}”,
      null);

In this C# example we got the list of printers installed on the device. The Java Script equivalent for this command is:

Windows.Devices.Enumeration.DeviceInformation.findAllAsync(
‘"System.Devices.InterfaceClassGuid:="{97FADB10-4E33-40AE-359C-8BEF029DBDD0}""’,
null)
.done(function(printers) {
                // iterate through items.
                }

For Java Script is mandatory to add the also the given text before the GUID (don’t’ forget about the “”). When now results are found the count of the returned collection is 0 and not NULL.
Now, let see a small hack with this function. Normally we can access only printers, webcam and external devices. But this method was port from Windows 7, where we can access other information also. If we know the correct GUID and are not limited by Windows 8 we can access other data also. For example if we set the GUID to “{0ECEF634-6EF0-472A-8085-5AD023ECBCCD}” we will get the list of processor on that computer. For example for my PC I got a list with the following content:

Intel(R) Core(TM) i7 CPU       2630QM @ 2.00GHz

I thinks that also other information can be accessed based on the GUID. Did you found other GUID that are working?

Read More

Post event – CodeCamp Cluj-Napoca, July 2012

Yesterday, July 21, we had a new CodeCamp meeting in Cluj-Napoca. For almost 7 hours we talk about the new Windows Azure and how we can use Windows Azure features in Metro Style Applications for Windows 8, software architecture and responsive web design. Even if it was a perfect summer day, around 45 persons came to this event.
Special thanks to our sponsors: ISDC and Pentalog and congratulation all.

At this event I talked about how we create smart Metro Style Application for Windows 8 using Windows Azure. You can find my presentations here:

How to use windows azure features on windows from Radu Vunvulea

I will add to this post link to the rest of the presentations next week:

• Windows Azure just got REALLY serious, Mihai Nadăș
• Azure WebSites – more than shared hosting, Mihai Tătăran
• How to use Windows Azure features on Windows 8, Radu Vunvulea
• Architecture in theory and practice, Cristian Odea, Sergiu Damian
• Responsive Web Design, Lorant Domokos

In the end I added some pictures from this event:

Read More

SQL - UNION and UNION ALL

I think that all of us used until now UNION in a SQLstatement. Using this operator we can combine the result of 2 queries.

For example we want to display the name of all our clients.In our database the clients are stored in separate databases based on theregion. To be able to display the name of all our clients we need to execute aquery on different table and combine the result:

SELECT Name FROM EuropeClients
UNION
SELECT Name FROM AsiaClients

Each time when we execute this call everything is fine. Inone day, the marketing team observes that there are clients that appear inEurope, but also in Asia, but when we execute this query we don’t have anyduplicated data.

This happen because UNION removes any duplicates rows.Because of this, if we want to count how many time a client name appears, itwill not be possible using just UNION.

SELECT Name, count(*) AS Count
FROM
(SELECT Name FROM EuropeClients
UNION
SELECT Name FROM AsiaClients)
GROUP BY Name

For this query, the Count column will be 1 everywhere. For thesecases we need to use an optional argument that UNION operator have. The ALLargument displays the duplicates rows also. Using this argument with UNION willpermit to get the result that we expected from our queue.

SELECT Name, count(*) AS Count
FROM
(SELECT Name FROM EuropeClients
UNION ALL
SELECT Name FROM AsiaClients)
GROUP BY Name

Maybe the example was not the best one. But I would like to emphasize that theUNION don’t return the duplicates rows, but UNION ALL do.
Also, before using anykind of SQL commands try to understand 100% what they do.

Read More

Some scenarios when we can use Shared Access Signature from Windows Azure

In this post we will talk about some possible scenario when Shared Access Policy can be used. We will discuss about a different scenario for blobs, tables and queues.

Blobs

We are a graphical designer that creates templates for web applications. We decide that we what to offer this content to any persons based on a subscription that is paid for each template package. A template package can contain 100 web applications template for example.

How we can share this content very easily with our clients. A simple solution is using blobs and Shared Access Signature. For each client we create an access token that allow to access the templates for which he paid. Over this structure we create a web-application that allow user to download the templates packages after he insert his access token that is send via email.

Table

Let’s imagine an application that store on Azure table information about stock reports for the each weeks. This information is generated based on a lot of computation power. Because of this the company decides to share sell this valuable content based on a weekly subscriptions. A client can have access only to information for the weeks that he paid.

A solution could be to write a service that retrieves all this content based for a given password. To be able to do this we would need to register our client, authenticate them each time and so on.

A more simple solution is to put this content in Azure table and use Shared Access Signature to give read only access to our clients. Based on the unique token, the client will be able to access and query this information in any way they want. From our perspective, we can define for each table what partitions keys and rows keys a client can access. Each week, all we need to do is to update the Shared Access Signature for clients that paid the subscription for the next week. This can be done automatically without any problems.

Queues

We can imagine that we the biggest ice producer from our region and we create ice for other companies that sell it to general public (we create in 5 locations). We create a system that process each command based on the arrival. Our partners submit a request on our web site and based on their location and loading we are able allocate them to a specific ice fabric. Each ice fabric could have allocated a queue where from it could process the commands.

In the summer, the ice request is so big that we cannot delivery it. Because of this we decide to work with small ice factory that can help us. A solution to share all the commands for ice, but without sharing client and price information is to use Shared Access Policy over queues.

Each of our partners could get a limited access to the commands and queue and produce ice for us for a specific time. When we don’t need any more their help we can restrict the access to the commands queues.

There are a lot of scenarios that we could imagine. Don’t expect that Shared Access Signature to be the only solutions for our problems. But there will be times, when this is the simples solution, when we don’t need to implement something more and use an out of the box mechanism.

Tutorials about Shared Access Signature:

1. Overview
2. How to use Shared Access Signature with tables from Windows Azure
3. How to use Shared Access Signature with blobs from Windows Azure
4. How to use Shared Access Signature with queues from Windows Azure
5. How to remove or edit a Shared Access Signature from Windows Azure 
6. Some scenarios when we can use Shared Access Signature from Windows Azure

Read More

Shared Access Signature on Windows Azure - Overview

Until now we saw how we can work with Shared Access Signature on blobs, tables and queues on Windows Azure. In this post we will try to see how this mechanism works in more details.
The Shared Access Signature can be used from any language. Until now I have example only from C#, where we used the current API to make calls to generate and set the access policy. This is not the only way to generate and configure them. All this features are exposed on Windows Azure as a RES API that can be used very easily.
There are different ways to make the REST API calls; we can send the configuration items in the query string or in the body of the request. The most important think that we need to know is that each access policy that is created need to have a unique id (string) and a list of permissions. Each type of resources supports different permissions types:

• Read – r
• Add – a
• Update – u
• Delete - d
• Process – p
• List - l

For each resource that is used we need to define the permissions in a specific order. For example if we want to define for a table the add and the read permissions, we cannot defined the add permissions first and after that the read permissions. In the following I will order the permissions for each resource:

• Table – raud
• Container (blob container) – rwdl
• Blob - rwd
• Queue – raup

When we want to create a Shared Access Policy using the REST API we need to specify the following data (parameters):

• REST URL
• REST URL parameters
• signedversion (sv)– represent the version of the Shared Access Policy. This need to use in the case you is using a Shared Access Policy version before 12/02/2012.
• signedresource (sr, only for blobs) – define what resources from a blob are accessible. The supported values are “b” and “c”. When we specify “b” we grand access to the blob content and metadata. “c” need to be specify when we work with container, by using it we grand access to list of blobs and all blobs from that container.
• tablename (tb, only for tables) – the name of the table that we want to share.
• access policy – the access policy right on the given resource. We will talk about this resource later on.
• signedidentifier (si) –unique identifier for each access policy that is defined. Using this id we can delete and update any access policy.
• signature (sig) – the signature that is used to authenticate the request.

The access policy parameter is not form from only one parameter. This is a collection of parameters that need to be set. Using these parameters we defined the access policy rights. The following parameters need (can) be set for access policy:

• signedstart (st) – the start time from when the access policy is valid
• signedexpiry (se) – the end time of the access policy
• signedpermissions (sp) – the permissions associated with the given resource
• startpk (spk), startrk (srk), endpk (epk), endrk (erk) – only for tables, the start and end row key and partition key

If you are working with, the simple solution is to use the API directly from code. This will generate automatically the REST API calls. But we don’t need to create the calls by hand.
An interesting think about Shared Access Policy is the number of access policies that we can define. Each queue, table, blob or container can have maximum 5 access policies. For each access policies we can define how many access token we want.
A very common scenario when Shared Access Signature is used is when a consumer what to access a specific resources and we don’t want to manually creating the access policy for him. For this case we can define a service on a web role or on a worker role that create the access policy automatically.  Using this flow, it is very easy to control automatically the users that have access to a given resource. If the user needs to renew his token, the only think that need to do is to send a new request to the web role that generate the access token and renew the old one.
When we are using Shared Access Policy we should try to respect the following recommendations:

• Don’t generate lifetime access token – Try not to have access token that expired in 10 year. The lifetime of an access token should be limited. If the token expired, than the user should request a new token (or you can have an automatically mechanism that renew the access policy).
• Send the access token by HTTPS – Any user that has the access token can access your resources. Because of this try to use a secure connection when you send the access token to the consumer. A simple and safe way is HTTPS.
• Clock skew – On different machines we can have different time. The maxim difference that is accepted between machines on Windows Azure is 300 seconds. If you set the start time of an access policy, try to have in mind this time period.
• Group access policy – For each resource we can define maximum 5 access policies. Because of this we should group our access policies based on some logic. When we revoke an access policies, all access token for that access policy are invalidated.

In this post we saw we discuss about some particularities that Shared Access Policy have and how can be access using the REST API. This is a powerful feature and need to be used carefully, because we don’t want any person to have access our private data from blobs, tables or queues.

Tutorials about Shared Access Signature:

1. Overview
2. How to use Shared Access Signature with tables from Windows Azure
3. How to use Shared Access Signature with blobs from Windows Azure
4. How to use Shared Access Signature with queues from Windows Azure
5. How to remove or edit a Shared Access Signature from Windows Azure 
6. Some scenarios when we can use Shared Access Signature from Windows Azure

Read More

A strange way to make an update to items from database

Last week I heard an interesting discussions between a tester and a developer.
The tester was upset that he discovered the following flow on an update action of an item from database:

• Client: request and get an item from server
• Client: change some data from the item
• Client: send an update command to the server
• Server: get the update command request
• Server: delete from database the given item
• Server: recreate the item as a new item with the updated data

What do you see wrong in this flow? (I hope that you spotted the problem already)
For each update, the server deletes the item from database and recreates the item. Each deleted item is marked only as deleted in database but is not physical removed, because we need a tracking mechanism. This is a very bad practice. We are talking about a small web-application that recreates each item when the user changes some fields on it.
Imagine the following scenario: The web application is an e-commerce solution and has around 10.000 items listed. Each week, we receive from each producer updates related to each product that we import from Excel files. Because of this in only 3 months, our database will have around 120.000 items, even if only 10.000 are active.
The developer said to the testers that was the most convenient way for him. But this solutions is farthest the best one.
So what we can do to solve these problems? First of all we should look what we should do when an item is updated. If we need some tracking capabilities, that we should create a separate table/tables that track the changes.
If you are a tester, you should never accept a response like “It was the most convenient”. The “tracking” should never be made in the same table. Also if this was the most easier way to update an item from the database that say no again.

Read More

How to remove or edit a Shared Access Signature from Windows Azure

Until now we saw how we can create a Shared Access Signature for blobs, table and queues. In real life scenario, this is not all the think that we do. After we create a Shared Access Signature we want to be able to edit or remove it.
In this blog post we will look over some common scenario that can appear when we work with Shared Access Signature.
The first scenario is when we want to remove the access to a resources using Shared Access Signature. After we created an access signature and we shared with the client, maybe we realize that we send the access signature to the wrong user for example. For this case we want to delete the access signature from the permissions list. For this cased is very important to have stored (or to be able to recreate) the name of permissions that we created. If you remember, when we create an access policy we set a unique name for each policy. Based on this name we can remove any access policy that we created.
Blobs, tables and queues have a method named “GetPermissions()”. For each given type, this method returns the permissions for the given type. Based on the name we can access each access policy and remove them.

CloudTable myTable = …
TablePermissions permissions = myTable.GetPermissions();
var accessPolicies = permissions.SharedAccessPolicies;
accessPolicies.Remove(“myAccessPolicyName”);
permissions.SetPermissions(permissions);

In this example, we extracted from our Azure table the TablePermissions for our table. From this object we need to extract the SharedAccessPolicies list. This object contains the list of all Shared Access Policies of our table. Based on the name of the access policy we removed our item from the list. At this step is very important to update the permissions list of our table (if we want to persistent the changes). Because of this we need to call the “SetPermissions” method and give us parameter the list of permissions.
The same method will be used for queues and blogs. Each of this items contains the GetPermissions() method.
Another scenario that is very often used is to change the Shared Access Policies for a given client. For example if we share some data from a table in a form of monthly subscription, we don’t want to send a new access token every month to the client. Because of this we want to be able to update the expiration data every month.
The implementation of this scenario is very similar to one before. We don’t want to remove the policy, the only think that we want is to get an instance to our policy and change the expiration time interval.
In this post we saw how we can remove or edit an access policy. In the next post will talk about how Shared Access Signature looks, how the flow looks like when a access policy is created and about some best practices that are need to be followed when we use them.
Tutorials about Shared Access Signature:

1. Overview
2. How to use Shared Access Signature with tables from Windows Azure
3. How to use Shared Access Signature with blobs from Windows Azure
4. How to use Shared Access Signature with queues from Windows Azure
5. How to remove or edit a Shared Access Signature from Windows Azure 
6. Some scenarios when we can use Shared Access Signature from Windows Azure

Read More

How to use Shared Access Signature with tables from Windows Azure

Until now we talk about how to use Shared Access Signature on blobs and queues from Windows Azure. Today we will see how we can use Shared Access Signature with tables from Windows Azure.
Using this feature we can give a limited access to a consumer to Windows Azure tables. In the next part we will look over what are the restrictions that can be made using Shared Access Signature:

• The first limitation that we can add is the time range. Based on the time a user can have a limited access to a table. For example a user can have access to a table only from 1st of July until the end of the week.
• We can limit what actions can be done using a Shared Access Signature. The following actions can be specified: add, update, delete and query.
• We can give access to a table or to only a part of a table. This limitation can be done using the partition key and row key. For example we can limit a consumer to have access only to partions keys from pkStart to pkEnd and from row rwStart to rwEnd.
• The last feature is one of the most powerful features that we have on Azure Tables from Shared Access Signature. We can limit access to only to a part of items from a table. For example we can give access only to items from table that have the partition key equal with some value. In this way the user will not be able to see the rest of the content.

We saw until now, how we can use it in theory. Let see now in practice how the code should look likes.

SharedAccessTablePolicy tablePolicy = new SharedAccessTablePolicy()
{
    Permissions = SharedAccessTablePermissions.Query
            | SharedAccessTablePermissions.Add,
    SharedAccessExpiryTime = DateTime.UtcNow + TimeSpan.FromHours(1)
};

At this step we created the policy. We can specify the permissions right and how long the consumer will have access to our table. The partition key and row key limitation can be done only at the last step when we generate the access token.

TablePermissions tablePermissions = new TablePermissions();
tablePermissions.SharedAccessPolicies.Add(
    "Client1",
    tablePolicy);
myTable.SetPermissions(tablePermissions);

In the above code we create the permissions with the given policy and added to our table. At this step is important to know that we can add more than one access policies. Each access policy have a unique name (in my case is “Client1”). Using this name we can change or remove the permissions on a table.

tableToken = myTable.GetSharedAccessSignature(
    new SharedAccessTablePolicy(),
    "Client1",
    10,
    0,
    19,
    100);

This was last step. At this step we generated the table token. We had to specify the name of the policy that we want to use for that token. In this example I specify that the consumer will have access only from the partition key 10 to 19 and from row keys 0 to 100. If I don’t want to limit the access of the user to the table (to have full access to the table) we need to specify null to these values.

tableToken = myTable.GetSharedAccessSignature(
    new SharedAccessTablePolicy(),
    "Client1",
    null,
    null,
    null,
    null);

The use of this access token is very easy and is 1 to 1 to how we have done for the queues.
Until now we saw how to work with Shared Access Signature with blobs, quest and table. The next post will see how we can change or remove an access signature that was already provided to a client.
Tutorials about Shared Access Signature:

1. Overview
2. How to use Shared Access Signature with tables from Windows Azure
3. How to use Shared Access Signature with blobs from Windows Azure
4. How to use Shared Access Signature with queues from Windows Azure
5. How to remove or edit a Shared Access Signature from Windows Azure 
6. Some scenarios when we can use Shared Access Signature from Windows Azure

Read More