Python 2.7은 지원이 종료되었으며 2026년 1월 31일에 지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Python 2.7 애플리케이션을 배포할 수 없습니다. 기존 Python 2.7 애플리케이션은 지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다. 지원되는 최신 Python 버전으로 마이그레이션하는 것이 좋습니다.
유효한 Google 계정에 해당하지 않는 이메일 주소로 User 생성자를 호출하는 경우 객체는 생성되지만 실제 Google 계정에 상응하지 않게 됩니다.
객체가 저장된 이후에 누군가가 해당 이메일 주소로 Google 계정을 만드는 경우에도 마찬가지입니다. 생성 당시 Google 계정을 나타내지 않는 이메일 주소를 사용하는 User 값은 절대로 실제 사용자를 나타내는 User 값과 일치하지 않습니다.
개발용 웹 서버에서 실행할 때 모든 User 객체는 (시뮬레이션된) 데이터 저장소에 저장될 때 유효한 Google 계정을 나타내는 것으로 간주됩니다.
유효한 사용자의 User 객체는 사용자의 고유 ID 값을 제공할 수 있습니다. 이 값은 사용자가 이메일 주소를 변경해도 그대로 유지됩니다. user_id() 메서드는 이 ID인 str 값을 반환합니다.
User 객체는 앱에 사용되는 인증 방법에 관계없이 형태가 동일합니다.
Datastore에서 사용자 값 사용
사용자 ID는 안정적이어서 키 이름 또는 문자열 속성으로 사용할 수 있습니다.
따라서 사용자 값을 사용할 때 사용자 ID 및 이메일로 통신할 수 있도록 마지막으로 본 이메일 주소를 저장해야 합니다. 아래 예시는 현재 사용자와 사용자 ID를 비교하는 방법입니다.
UserProperty에는 사용자의 고유 ID와 함께 이메일 주소가 포함되어 있으므로 이를 저장하지 않는 것이 좋습니다. 사용자가 자신의 이메일 주소를 변경하고 이전에 저장한 User 값과 새 User 값을 비교하면 서로 일치하지 않게 됩니다. 대신 User사용자 ID 값을 사용자의 안정적인 고유 식별자로 사용해 보세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThe \u003ccode\u003eUser\u003c/code\u003e class represents a user and provides unique, comparable instances, where equal instances represent the same user.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eusers.get_current_user()\u003c/code\u003e function retrieves the \u003ccode\u003eUser\u003c/code\u003e instance for the currently authenticated user, regardless of the authentication method.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eUser\u003c/code\u003e instances can be created using an email address or a federated identity, but those created from invalid Google accounts will not match real user accounts.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003euser_id()\u003c/code\u003e method returns a stable, unique string identifier for a user that persists even if the user changes their email.\u003c/p\u003e\n"],["\u003cp\u003eIt is recommended to store the \u003ccode\u003euser_id\u003c/code\u003e for user identification in the datastore instead of a \u003ccode\u003eUserProperty\u003c/code\u003e because email addresses may change.\u003c/p\u003e\n"]]],[],null,["# User Objects\n\nAn instance of the\n[User](/appengine/docs/legacy/standard/python/refdocs/google.appengine.api.users#google.appengine.api.users.User)\nclass represents a user. User instances are unique and comparable. If two instances are equal,\nthen they represent the same user.\n| This page describes how to use the legacy bundled services and APIs. This API can only run in first-generation runtimes in the App Engine standard environment. If you are updating to the App Engine Python 3 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/python-differences) to learn about your migration options for legacy bundled services.\n\nThe application can access the User instance for the current user by calling the\n[users.get_current_user()](/appengine/docs/legacy/standard/python/refdocs/modules/google/appengine/api/users#get_current_user)\nfunction. \n\n user = users.get_current_user()\n\nYou can use the [users.get_current_user()](/appengine/docs/legacy/standard/python/refdocs/modules/google/appengine/api/users#get_current_user)\nfunction no matter which authentication option your app uses.\n\nA User instance can be also constructed from an email address: \n\n```python\nuser = users.User(\"Albert.Johnson@example.com\")\n```\n\nOr, if you have a `federated_identity`, you can use it to create a User instance: \n\n```python\nuser = users.User(federated_identity=\"http://example.com/id/ajohnson\")\n```\n\nIf the User constructor is called with an email address that does not correspond with a valid\nGoogle account, the object will be created but it will not correspond with a real Google account.\nThis will be the case even if someone creates a Google account with the given email address after\nthe object is stored. A User value with an email address that does not represent a Google account\nat the time it is created will never match a User value that represents a real user.\n\nWhen running under the development web server, all User objects are assumed to represent valid\nGoogle accounts when stored in the (simulated) datastore.\n\nThe User object for a valid user can provide a unique ID value for the user that stays the same\neven if the user changes her email address. The `user_id()` method returns this ID, a\n`str` value.\n\nThe User object has the same form no matter which method of authentication your app uses.\n\nUsing User Values With the Datastore\n------------------------------------\n\nThe user ID is stable; you can use it in a key name or as a string property.\nTherefore, when using user values, you want to store the user ID (and perhaps the last-seen\nmail address to communicate with the user by mail). The example below shows how to compare the\ncurrent user to a user ID: \n\n class ModelWithUser(ndb.Model):\n user_id = ndb.StringProperty()\n color = ndb.StringProperty()\n\n @classmethod\n def get_by_user(cls, user):\n return cls.query().filter(cls.user_id == user.user_id()).get()\n\nWe strongly recommend that you do not store a `UserProperty`, because it includes the email address\nalong with the user's unique ID. If a user changes their email address and you compare their old, stored\n`User` to the new `User` value, they won't match. Instead, consider using the\n`User` *user ID value* as the user's stable unique identifier."]]