Group items tagged

Once you've enabled OpenID authentication for your app, a few things change: URLs generated by create_login_url without a federated_identity parameter specified will redirect to the OpenID login page for Google Accounts. URLs that are protected by "login: required" in app.yaml or web.xml will result in a redirect to the path "/_ah/login_required", with a "continue" parameter of the page originally fetched. This allows you to provide your own openid login page. URLs generated by create_login_url with a federated_identity provider will redirect to the specified provider.

many users, when asked for their "openid URL" will simply look at you in puzzlement. What we need is a solution that avoids the need for most users to enter their URL themselves, while still allowing savvy users to do just that. Fortunately, there are a number of such solutions. One of them is clickpass. After signing in there and setting up an entry for your site, they'll provide you with code for a button that you can embed in your login page, and which allows users to choose from a number of well-known identity providers, including Hotmail, Yahoo!, Google, and Facebook, as well as entering their own URL.

Yes, you will need to use the federated login (OpenID) stuff. The long-and-short of it is that you pass the federated_identity parameter to users.create_login_url.  You'll need to setup a page for users to tell you what goes in federated_identity somehow, perhaps by clicking a google logo or entering an apps domain. For Google accounts:   users.create_login_url(federated_identity='google.com/accounts/o8/id')   or   users.create_login_url(federated_identity='gmail.com') For an Apps account:   users.create_login_url(federated_identity='google.com/accounts/o8/site-xrds?hd=yourappsdomain.com') There is a little info here:   http://code.google.com/appengine/docs/python/users/overview.html And Wesley has a nice article about it here:   http://code.google.com/appengine/articles/openid.html Some info on Google Apps domains and OpenID:   http://groups.google.com/group/google-federated-login-api/web/openid-...

This tutorial concerns using Google Accounts to maintain the existence of your users in a Google App Engine application. Google App Engine provides the class UserServiceFactory to facilitate that. UserServiceFactory is then used to generate UserService object, which in turn provides the following features createLoginURL createLogoutURL getCurrentUser isUserAdmin isUserLoggedIn You would use UserService object to generate the login URL for the browser. The browser would be directed/redirected to this URL. On reaching this URL, the Google log-in prompt would be displayed by Google's server.

Authentication with App Engine, regardless of where you're doing it, is a three-stage process: Obtain an authentication token. This can be done with ClientLogin for installed apps, for example, or with AuthSub for a webapp. When logging in directly to an application, this is the part of the login process where your user sees a Google signin screen. Take that authentication token, and use it to obtain an authentication cookie. Use that authentication cookie in all subsequent requests.

The remote_api module consists of two parts: A 'handler', which you install on the server to handle remote datastore requests, and a 'stub', which you set up on the client to translate datastore requests into calls to the remote handler. remote_api works at the lowest level of the datastore, so once you've set up the stub, you don't have to worry about the fact that you're operating on a remote datastore: With a few caveats, it works exactly the same as if you were accessing the datastore directly.

Note that the handler specifies "login: admin". This is extremely important, since we don't want to give just anyone unfettered access to our datastore!

Since you're accessing the datastore over HTTP, there's a bit more overhead and latency than when you access it locally. In order to speed things up and decrease load, try to limit the number of round-trips you do by batching gets and puts, and fetching batches of entities from queries. This is good advice not just for remote_api, but for using the datastore in general, since a batch operation is only considered to be a single Datastore operation