[[["容易理解","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-05 (世界標準時間)。"],[],[],null,["# Using hostname and path conditions\n\n| **Important:** Limiting access based on URL hostname and path can only be done with the gcloud CLI.\n\nThis page describes hostname and path [Identity and Access Management (IAM)\nconditions](/iam/docs/conditions-overview).\n\nYou can secure Identity-Aware Proxy (IAP) resources using the\nhostname and path of a request URL.\nFor example, the `request.path.startsWith` IAM condition can be\nused to only grant access to employees in the **Privileged Access** group if\nthe URL path starts with `/admin`.\n\nFor more information about using hostname and path conditions, see\n[request attributes](/iam/docs/conditions-overview#request_attributes).\n\n### String normalization\n\nA URL has a hostname and path. For example, the URL\n`https://sheets.google.com/create?query=param`\nhas a hostname of `sheets.google.com` and a path of `/create`.\n\nBackends can interpret hostnames and paths in different ways.\nTo remove ambiguity, IAP normalizes hostname and path\nstrings when checking policies.\n\nIAP performs two policy\nchecks when a request has a non-normalized path. If the non-normalized\npath passes the policy check, IAP normalizes the path and a\nsecond policy check is performed. Access is granted if both the non-normalized\nand normalized paths pass the policy check.\n\nFor example, if a request has the path `/internal;some_param/admin`,\nIAP first performs a policy\ncheck on the non-normalized path (`/internal`). If that check passes,\nIAP performs a second policy check on the normalized path\n(`/internal/admin`).\n\n#### Hostnames\n\nHostname normalization involves the following:\n\n- Removing trailing dots\n- Lowercasing characters\n- Converting to ASCII\n\nHostnames that include non-ASCII characters are further normalized using\nPunycode. You need to use Punycode to normalize your hostname string for a match\nto be made.\n\nTo normalize your hostname string with Punycode, use a converter\nlike [Punycoder](https://www.punycoder.com/).\n\nThe following are examples of normalized hostnames:\n\n- `FOO.com` is normalized to `foo.com`\n- `café.fr` is normalized to `xn--caf-dma.fr`\n\n#### Paths\n\nPath normalization involves the following:\n\n- Removing path params\n- Resolving relative paths to their absolute equivalent\n\nA path param includes all\ncharacters from a `;` to either the next `/` or the end of the path.\n\nRequests that contain path sections starting with `..;` are considered\ninvalid. For example, `/..;bar/` and `/bar/..;/` return the `HTTP 400: Bad\nRequest` error.\n\nThe following are examples of normalized paths:\n\n- `/internal;some_param/admin` is normalized to `/internal/admin`\n- `/a/../b` is normalized to `/b`\n- `/bar;param1/baz;baz;param2` is normalized to `/bar/baz`\n\n### Subdomain endings\n\nA policy set with `request.host.endsWith(\"google.com\")` matches to both\n`sub_domain.google.com` and `testgoogle.com`. If your goal is to limit your\npolicy to only subdomains that end with `google.com`, set your policy to\n`request.host.endsWith(\".google.com\")`."]]
