Database Reference
In-Depth Information
Implementing Security Best Practices
Now that you know a little about security regarding SQL Azure OData, you need to be familiar with a few
best practices surrounding SQL Azure OData Service:
Always create a new SQL Azure user instead of allowing anonymous access to SQL
Azure OData Service.
Never use your SQL Azure Administrator username to access SQL Azure OData
Service.
Don't allow the SQL Azure user that is used by SQL Azure OData Service to have
write access to SQL Azure OData Service through anonymous access.
The problem you run into by not creating a new user is that you then allow anyone to read from and
write to your database. You also have no way to control how much data or what type of data they write.
But with all of that said, because SQL Azure OData is currently in CTP, it's easier to test with
anonymous access than with a read-only SQL Azure user. But when out of CTP, you should build your
client to use anything other than anonymous access. The browser doesn't support simple web token
authentication natively, and this is required for SQL Azure OData Service via ACS. Thus, in production,
don't use anonymous access.
Viewing OData-Enabled SQL Azure Data
It's time to view the fruits of your labors (not that it was a lot of hard work). You first briefly view your
data in the browser, just as you did the Netflix data, to prove that you can indeed consume the data via
OData. You then use a third-party app to view the data in a more pleasant-looking format. Then, you
build your own little application to consume the data.
Open your browser, and type in the following URL. Be sure to enter the appropriate server name for
your SQL Azure database: https://odata.sqlazurelabs.com/OData.svc/v0.1/ servername /TechBio . By
now, what you see in Figure 7-8 should look familiar. These are the same REST-based results you saw
earlier in this chapter as well as in Chapter 6, except that in this example you're looking at the list of
tables, or entities, that the SQL Azure OData service is providing from the TechBio database. Listed are
the Users and Docs tables, as well as several other tables that pertain to SQL Azure Data Sync Service
(discussed in Chapter 11).
As in previous example, you can navigate into the different entities to look at specific data. For
example, in Figure 7-9 the URL is modified slightly to look at a specific user in the Users table.
The key is that in this example, your SQL Azure database is your OData producer, and your browser
is the OData consumer. Those two alone allow you to easily navigate through the data, applying different
filters
You should now have a good understanding of OData. But let's take a quick look at one of the OData
consumers listed earlier, to give you an idea of the possibilities you have to consume an OData feed.
Search WWH ::




Custom Search