Warning: The OpenID feature mentioned on this page has been deprecated and is going to be removed. See the OpenID 2.0 Turndown document for details and timetable.
An instance of the User class represents a user. User instances are unique and comparable. If two instances are equal, then they represent the same user.
The application can access the User instance for the current user by calling the users.get_current_user() function.
You can use the users.get_current_user() function no matter which authentication option your app uses.
A User instance can be also constructed from an email address:
user = users.User("Albert.Johnson@example.com")
Or, if you have a
federated_identity, you can use it to create a User instance:
user = users.User(federated_identity="http://example.com/id/ajohnson")
If the User constructor is called with an email address that does not correspond with a valid Google account, the object will be created but it will not correspond with a real Google account. This will be the case even if someone creates a Google account with the given email address after the object is stored. A User value with an email address that does not represent a Google account at the time it is created will never match a User value that represents a real user.
When running under the development web server, all User objects are assumed to represent valid Google accounts when stored in the (simulated) datastore.
The User object for a valid user can provide a unique ID value for the user that stays the same even if the user changes her email address. The
user_id() method returns this ID, a
The User object has the same form no matter which method of authentication your app uses. If you switch authentication options from Google Accounts to OpenID, existing User objects in the datastore are still valid. (Note that the support for OpenID is experimental.)
Using User Values With the Datastore
The user ID is stable; you can use it in a key name or as a string property. Therefore, when using user values, you want to store the user ID (and perhaps the last-seen mail address to communicate with the user by mail). The example below shows how to compare the current user to a user ID:
We strongly recommend that you do not store a
UserProperty, because it includes the email address
along with the user's unique ID. If a user changes their email address and you compare their old, stored
User to the new
User value, they won't match. Instead, consider using the
User user ID value as the user's stable unique identifier.