Database Reference
In-Depth Information
http://localhost:8080/
. You will be greeted with a very empty
dashboard until you actually record some data.
The authentication and authorization scheme described here is the simplest
approach supported by the App Engine framework. Most of the time it
should be sufficient. However, as was pointed out in the previous section,
it suffers from the drawback that it requires all BigQuery bound requests
to pass through App Engine. It turns out that the OAuth protocol allows
you to avoid this pass-through without compromising the security of your
data. Remember, from Chapter 5 “Talking to BigQuery API,” that an OAuth
credential consists of two pieces: a short-lived access token passed in API
requests to service providers such as BigQuery, and a refresh token passed
to authentication providers such as the Google login service to obtain fresh
access tokens. Instead of requests passing through the application, just let
the application return the access token to clients and have them directly
communicate with BigQuery.
To do this safely, a service account with limited access should be
provisioned, and the OAuth credential should be constructed only with the
scopes required by the client operation. For example, for logs written by the
clients, the account needs to have write access to the dataset containing the
log tables and only the streaming scope is required.
https://www.googleapis.com/auth/bigquery.insertdata
Like the scopes introduced previously, this is not really a URL. It is just
the string used to identify the scope when authenticating. It is important
to create a separate account solely for this purpose and limit its access to
just the datasets that will receive the records. This will avoid inadvertently
leaking additional privileges to clients that have the access token.
Because the access token is only valid for a short time, its capabilities will be
fairly limited. Although such an approach is definitely valuable in scenarios
in which the traffic volume is substantial, significant drawbacks exist. The
most obvious one is that you can no longer rely on server-side validation. If
there are rogue or broken clients, they might corrupt tables by writing bad
data, so pay attention to these scenarios when considering this approach.
