I have developed a standard Google App Engine backend Application for my Android client. Now, there is search functionality in the App and during one request, I plan to return 20 results but I search for more in advanced(like 100) so that for the next hit, I will just search in these records and return. So, I need a mechanism to save these 80 records so that the same user might get them quickly.
I searched for it and found out that we can enable sessions in appengine-web.xml but all the session access has been done in doPost() and doGet() while my code is entirely Google's cloud endpoints.(like Spring)
Another thing is that I would like to persist the data both inside the Datastore and some cache(like Memcache).
My end goal is storing this data across search sessions. Is there any mechanism that will allow me to do this?
The usual approach here is to provide a code value in the response which the user can send in the next request to "continue" viewing the same results. This is called a "cursor".
For example, you might store the 80 records under some random key in your cache, and then send that random key to the user as part of the response. Then, when the user makes a new request including the key, you just the records and return them.
Cookie-based sessions don't usually work well with APIs; they introduce unnecessary statefulness.
Related
Every time someone hits an API route I want to store that information in database, connected with req. IP.
Afther I would like to find some association rules based on similar searches.
Should I store some information in cookies or to use local dartabase?
Example on some hotels site:
I want to store info that i got a lot of request for cheap hotels in some specific area.
Thnaks.
Definitely in a database. Cookies wouldn't make sense because
You cannot rely on cookies for persistent data. They can expire, be cleared, etc.
Cookies can hold a very limited amount of data (4093 bytes usually)
Cookies are stored locally on your client's browser, you want information across all of your clients.
Tracking user behavior data is very common web feature. You may want to use a web analytics service such as Google Analytics rather then implement your own.
I'd like to give to each of my customers access to their own bucket under my GCS enabled app.
I also need to make sure that a user's bucket is safe from other users' actions.
Last but not least, the customer will be a client application, so the whole process needs to be done transparently without asking the user to login.
If I apply an ACL on each bucket, granting access only to the user I want, can I create an API key only for that bucket and hand that API key to the client app to perform GCS API calls?
Unfortunately you only have two good options here:
Have a service which authenticates the individial app according to whatever scheme you like (some installation license, a random GUID assigned at creation time, whatever) and vends GCS signed URLs, which the end user could then use for a single operation, like uploading an object or listing a bucket's content. The downside here is that all requests must involve your service. All resources would belong entirely to your application.
Abandon the "without asking the user to login" requirement and require a single Google login at install time.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.
I am writing an travel itinerary app engine application which will interact with the calendars of my users. In order to manage access to my user's calendar I intend to use OAuth 2.0. I looked online for various code examples and the closest to what I am trying to acheive is (http://code.google.com/p/google-api-java-client/source/browse/calendar-appengine-sample/src/main/java/com/google/api/services/samples/calendar/appengine/server/?repo=samples). I have the following questions
1) I find that the server needs access to the application's client id and client secrets. Most of the sample code I have seen so far loads this from a local file. Does AppEngine give some API which will enable me to retrieve the client id and client secret without me having to worry about storing it ?
2) If I have to store the client secret in a secure fashion what are my options ?
3) What is the best way to store a user's access token and refresh token ?
It almost never changes, so hardcode it. It's only really loaded from a file in the sample programs so that you can get the samples running without touching the code.
See 1.
You can use the Google provided Credential class which uses a dedicated kind. Or, given that they are simply strings, you can store them as part of the User kind which your app almost certainly has to track your registered users.
As a tip, separate writing your oauth code from writing your calendar code. I would start by writing an app that only authorises, stores the refresh token, and refreshes the access token. You can test your access token using curl. Once you have that all working, then add your Calendar functionality as phase 2.
I am looking for a way for two Google Apps applications to talk to each other and share data between each other. I have the following scenario:
Application A logs user in using Google Apps login
Application B logs user in using Google Apps login
then these applications need to communicate directly to each other (server-to-server) using some APIs
The question is: how do these applications verify that the other one is logged in with the same user to Google? I would imagine something like:
- Application A gets some 'token' from Google and sends it to Application B
- Application B verifies that this token is valid for the same Google account as it is logged in with
Is there a way to accomplish that via Google Federated Login? I am talking about Hybrid protocol here.
Here's a simple way to do it:
You keep everything keyed to the user's Google userid on both applications.
You share the data using HTTP requests that contain the userid.
To prevent leaking of the userids (forbidden by the account API) and to verify the messages really come from the other application, you encrypt the requests with a symmetric cipher such as AES or Blowfish or whatever you like. Both applications have the same key embedded.
You could public key cryptography. With just two applications, it's not worth it in my opinion. If you start having more apps, public key makes sense.
The fine print: encryption does not guarantee integrity or origin without additional measures. You need to take precautions against playback, for example by incorporating a time-stamp or sequence number. You need to take precautions against tampering, e.g. with a checksum. Make sure to use CBC and good initialization vectors. Keep the key secret.
user.user_id() is always the same across all the apps for the same user. So you can simply compare values returned by user.user_id(). Is this what you are looking for?
Note: Every user has the same user ID
for all App Engine applications. If
your app uses the user ID in public
data, such as by including it in a URL
parameter, you should use a hash
algorithm with a "salt" value added to
obscure the ID. Exposing raw IDs could
allow someone to associate a user's
activity in one app with that in
another, or get the user's email
address by coercing the user to sign
in to another app.
From docs