Azure Static Web Apps 구성

아티클
02/28/2024

다음 설정을 제어하는 staticwebapp.config.json 파일에서 Azure Static Web Apps에 대한 구성을 정의할 수 있습니다.

라우팅
인증
Authorization
대체(fallback) 규칙
HTTP 응답 재정의
글로벌 HTTP 헤더 정의
사용자 지정 MIME 형식
네트워킹

참고 항목

이전에 라우팅을 구성하는 데 사용된 routes.json은 더 이상 사용되지 않습니다. 이 문서에 설명된 대로 staticwebapp.config.json을 사용하여 정적 웹앱에 대한 라우팅 및 기타 설정을 구성합니다.

이 문서에서는 독립 실행형 제품이며 Azure Storage의 정적 웹 사이트 호스팅 기능과 별개인 Azure Static Web Apps를 구성하는 방법을 설명합니다.

파일 위치

staticwebapp.config.json의 권장 위치는 워크플로 파일에서 app_location으로 설정된 폴더입니다. 그러나 폴더 집합 내의 모든 하위 폴더에 파일을 로 app_location배치할 수 있습니다. 또한 빌드 단계가 있는 경우 빌드 단계가 파일을 output_location 루트에 출력하는지 확인해야 합니다.

자세한 내용은 예제 구성 파일을 참조하세요.

Important

staticwebapp.config.json이 있는 경우 더 이상 사용되지 않는 routes.json 파일은 무시됩니다.

경로

정적 웹앱에서 하나 이상의 경로에 대한 규칙을 정의할 수 있습니다. 경로 규칙을 사용하면 특정 역할의 사용자에 대한 액세스를 제한하거나 리디렉션 또는 다시 쓰기와 같은 작업을 수행할 수 있습니다. 경로는 라우팅 규칙의 배열로 정의됩니다. 사용 예제는 예제 구성 파일을 참조하세요.

하나의 경로만 포함하는 경우에도 규칙이 routes 배열에 정의됩니다.
규칙은 routes 배열에 표시되는 순서대로 평가됩니다.
첫 번째 일치 항목에서 규칙 평가를 중지합니다. 일치는 methods 배열의 route 속성과 값(지정된 경우)이 요청과 일치할 때 발생합니다. 각 요청은 최대 하나의 규칙과 일치할 수 있습니다.

라우팅은 인증(사용자 식별) 및 권한 부여(사용자에게 기능 할당) 개념과 중복되는 부분이 상당히 많습니다. 이 문서와 함께 인증 및 권한 부여 가이드를 참조하세요.

경로 정의

각 규칙은 하나 이상의 선택적 규칙 속성과 함께 경로 패턴으로 구성됩니다. 경로 규칙은 routes 배열에 정의되어 있습니다. 사용 예제는 예제 구성 파일을 참조하세요.

Important

route 및 methods(지정된 경우) 속성만 사용하여 규칙이 요청과 일치하는지 여부를 확인합니다.

규칙 속성	Required	기본값	Comment
`route`	예	해당 없음	호출자가 요청한 경로 패턴입니다. 와일드카드는 경로 경로(route path)의 끝에서 지원됩니다. 예를 들어 경로 admin/은 /admin*으로 시작하는 경로 아래에 있는 모든 경로와 일치합니다.
`methods`	아니요	모든 메서드	경로와 일치하는 요청 메서드의 배열을 정의합니다. 사용할 수 있는 메서드는 `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` 및 `PATCH`입니다.
`rewrite`	아니요	해당 없음	요청에서 반환된 파일 또는 경로를 정의합니다. `redirect` 규칙과 함께 사용할 수 없습니다. 다시 쓰기 규칙은 브라우저의 위치를 변경하지 않습니다. 값은 앱의 루트에 대한 상대 경로여야 합니다.
`redirect`	아니요	해당 없음	요청의 파일 또는 경로 리디렉션 대상을 정의합니다. `rewrite` 규칙과 함께 사용할 수 없습니다. 리디렉션 규칙은 브라우저의 위치를 변경합니다. 기본 응답 코드는 `302`(임시 리디렉션)지만 `301`(영구 리디렉션)로 재정의할 수 있습니다.
`statusCode`	아니요	리디렉션의 경우 `301` 또는 `302`입니다.	응답의 HTTP 상태 코드입니다.
`headers`	아니요	해당 없음	응답에 추가된 HTTP 헤더 세트입니다. 경로 관련 헤더가 응답의 글로벌 헤더와 동일한 경우 경로 관련 헤더가 `globalHeaders`를 재정의합니다. 헤더를 제거하려면 값을 빈 문자열로 설정합니다.
`allowedRoles`	아니요	익명	경로에 액세스하는 데 필요한 역할 이름의 배열을 정의합니다. 유효한 문자에는 `a-z`, `A-Z`, `0-9` 및 `_`가 포함됩니다. 기본 제공 역할, `anonymous`는 모든 사용자에게 적용됩니다. 기본 제공 역할 `authenticated`는 로그인한 사용자에게 적용됩니다. 사용자는 하나 이상의 역할에 속해야 합니다. 역할은 OR 기준으로 일치합니다. 사용자가 나열된 역할 중 하나에 있는 경우 액세스 권한이 부여됩니다. 개별 사용자는 초대를 통해 역할에 연결됩니다.

각 속성은 요청/응답 파이프라인에서 특정 목적을 갖고 있습니다.

목적	속성
경로 일치	`route`, `methods`
규칙이 일치하고 권한이 부여된 후 처리	`rewrite`(요청 수정) `redirect`, `headers`, `statusCode`(응답 수정)
경로가 일치한 후 권한 부여	`allowedRoles`

경로 패턴 지정

route 속성은 정확한 경로 또는 와일드카드 패턴일 수 있습니다.

정확한 경로

정확한 경로를 정의하려면 파일의 전체 경로를 route 속성에 배치합니다.

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

이 규칙은 파일 /profile/index.html에 대한 요청과 일치합니다. index.html은 기본 파일이므로 규칙은 폴더(/profile 또는 /profile/)에 대한 요청과도 일치합니다.

Important

route 속성에서 폴더 경로(/profile 또는 /profile/)를 사용하는 경우 /profile/index.html 파일에 대한 요청과 일치하지 않습니다. 파일에 관한 경로를 보호할 때는 항상 파일의 전체 경로(예: /profile/index.html)를 사용합니다.

와일드카드 패턴

Wild카드 규칙은 경로 패턴의 모든 요청과 일치하며 경로의 끝에서만 지원됩니다. 사용 예제는 예제 구성 파일을 참조하세요.

예를 들어 일정 애플리케이션의 경로를 구현하려면 일정 경로에 속하는 모든 URL이 단일 파일을 처리하도록 재작성하면 됩니다.

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

그런 다음, calendar.html 파일은 클라이언트 쪽 라우팅을 사용하여 /calendar/january/1, /calendar/2020 및 /calendar/overview와 같은 URL 변형에 대해 다른 보기를 제공할 수 있습니다.

참고 항목

/calendar/*의 경로 패턴은 /calendar/ 경로 아래의 모든 요청과 일치합니다. 그러나 경로 /calendar 또는 /calendar.html에 대한 요청과는 일치하지 않습니다. /calendar*를 사용하여 /calendar로 시작하는 모든 요청과 일치시킬 수 있습니다.

와일드 카드 일치 항목을 파일 확장명으로 필터링할 수 있습니다. 예를 들어 지정된 경로의 HTML 파일만 매칭하는 규칙을 추가하려는 경우 다음과 같은 규칙을 만들면 됩니다.

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

여러 파일 확장명을 필터링하려면 다음 예제와 같이 중괄호 안에 옵션을 포함합니다.

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

와일드 카드 경로의 일반적인 사용 사례는 다음과 같습니다.

전체 경로 패턴에 대한 특정 파일 제공
인증 및 권한 부여 규칙 적용
특수 캐싱 규칙 구현

역할을 사용하여 경로 보호

규칙의 allowedRoles 배열에 하나 이상의 역할 이름을 추가하여 경로를 보호합니다. 사용 예제는 예제 구성 파일을 참조하세요.

Important

라우팅 규칙은 Static Web Apps에서 제공되는 경로에 대한 HTTP 요청만 보호할 수 있습니다. 많은 프런트 엔드 프레임워크에서 Static Web Apps에 대한 요청을 실행하지 않고 브라우저에서 경로를 수정하는 클라이언트 쪽 라우팅을 사용합니다. 라우팅 규칙이 클라이언트 쪽 경로를 보호하지 않습니다. 클라이언트는 중요한 데이터를 검색하기 위해 HTTP API를 호출해야 합니다. 데이터를 반환하기 전에 API가 사용자 ID의 유효성을 검사하는지 확인합니다.

기본적으로 모든 사용자는 기본 제공 anonymous 역할에 속하며 로그인된 모든 사용자는 authenticated 역할의 멤버입니다. 필요에 따라 사용자는 초대를 통해 사용자 지정 역할에 연결됩니다.

예를 들어 인증된 사용자로만 경로를 제한하려면 기본 제공 authenticated 역할을 allowedRoles 배열에 추가합니다.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

allowedRoles 배열에서 필요에 따라 새 역할을 만들 수 있습니다. 경로를 관리자로만 제한하려면 allowedRoles 배열에서 administrator라는 고유의 역할을 정의하면 됩니다.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

역할 이름을 완전히 제어할 수 있습니다. 역할이 준수해야 하는 목록은 없습니다.
개별 사용자는 초대를 통해 역할에 연결됩니다.

Important

콘텐츠를 보호하는 경우 가능하다면 정확한 파일을 지정합니다. 보호할 파일이 많은 경우 공유 접두사 뒤에 와일드카드를 사용합니다. 예: /profile*은 /profile을 포함하여 /profile로 시작하는 가능한 모든 경로를 보호합니다.

전체 애플리케이션에 대한 액세스 제한

애플리케이션의 모든 경로에 대해 인증을 요구하는 경우가 많습니다. 경로를 잠그려면 모든 경로와 일치하는 규칙을 추가하고 배열에 authenticatedallowedRoles 기본 제공 역할을 포함합니다.

다음 예 구성은 익명 액세스를 차단하고 인증되지 않은 모든 사용자를 Microsoft Entra 로그인 페이지로 리디렉션합니다.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

참고 항목

기본값으로 미리 구성된 모든 ID 공급자가 사용하도록 설정됩니다. 인증 공급자를 차단하려면 인증 및 권한 부여를 참조하세요.

대체 경로

단일 페이지 애플리케이션은 종종 클라이언트 쪽 라우팅을 사용합니다. 이러한 클라이언트 쪽 라우팅 규칙은 서버에 다시 요청하지 않고 브라우저의 창 위치를 업데이트합니다. 페이지를 새로 고치거나 클라이언트 쪽 라우팅 규칙에 의해 생성된 URL로 직접 이동하는 경우 적절한 HTML 페이지를 제공하려면 서버 쪽 대체 경로가 필요합니다. 대체 페이지는 종종 클라이언트 쪽 앱에 대한 index.html 지정됩니다.

navigationFallback 섹션을 추가하여 대체 규칙을 정의할 수 있습니다. 다음 예에서는 배포된 파일과 일치하지 않는 모든 정적 파일 요청에 대해 /index.html을 반환합니다.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

필터를 정의하여 대체 파일을 반환하는 요청을 제어할 수 있습니다. 다음 예제에서는 /images 폴더의 특정 경로와 /css 폴더의 모든 파일에 대한 요청이 대체 파일 반환에서 제외됩니다.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

예를 들어 다음 디렉터리 구조를 사용하면 위의 탐색 대체 규칙이 다음 표에 자세히 설명된 결과를 생성합니다.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
└── index.html

다음에 대한 요청...	반환 항목	상태
/about/	/index.html 파일입니다.	`200`
/images/logo.png	이미지 파일입니다.	`200`
/images/icon.svg	/index.html 파일 - svg 파일 확장명은 필터에 `/images/*.{png,jpg,gif}` 나열되지 않으므로	`200`
/images/unknown.png	파일을 찾을 수 없습니다.	`404`
/css/unknown.css	파일을 찾을 수 없습니다.	`404`
/css/global.css	스타일시트 파일입니다.	`200`
/images 또는 /css 폴더 외부에 있는 그 외의 모든 파일	/index.html 파일입니다.	`200`

Important

사용되지 않는 routes.json 파일에서 마이그레이션하는 경우 레거시 대체 경로("route": "/*")를 라우팅 규칙에 포함하지 마세요.

글로벌 헤더

globalHeaders 섹션에서는 경로 헤더 규칙에 의해 재정의되지 않는 한 각 응답에 적용되는 HTTP 헤더 세트를 제공합니다. 그렇지 않으면 경로의 헤더와 글로벌 헤더의 합집합이 반환됩니다.

사용 예제는 예제 구성 파일을 참조하세요.

헤더를 제거하려면 값을 빈 문자열("")로 설정합니다.

다음은 글로벌 헤더의 일반적인 사용 사례입니다.

사용자 지정 캐싱 규칙
보안 정책
인코딩 설정
CORS(원본 간 리소스 공유) 구성

다음 예제는 사용자 지정 CORS 구성을 구현합니다.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

참고 항목

전역 헤더는 API 응답에 영향을 미치지 않습니다. API 응답의 헤더는 유지되고 클라이언트로 반환됩니다.

응답 재정의

responseOverrides 섹션에서는 서버가 오류 코드를 반환할 때 사용자 지정 응답을 정의할 수 있는 기회를 제공합니다. 사용 예제는 예제 구성 파일을 참조하세요.

다음 HTTP 코드를 재정의할 수 있습니다.

상태 코드	의미	가능한 원인
400	Bad request	잘못된 초대 링크
401	Unauthorized	인증되지 않은 상태에서 제한된 페이지를 요청
403	금지	사용자가 로그인했지만 페이지를 보는 데 필요한 역할이 없습니다. 사용자가 로그인했지만 런타임이 ID 클레임에서 사용자 세부 정보를 가져올 수 없습니다. 사용자 지정 역할로 사이트에 로그인한 사용자가 너무 많기 때문에 런타임에서 사용자를 로그인할 수 없습니다.
404	없습니다.	파일 없음

다음 예제 구성에서는 오류 코드를 재정의하는 방법을 보여줍니다.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

플랫폼

platform 섹션은 플랫폼별 설정(예: API 언어 런타임 버전)을 제어합니다.

API 언어 런타임 버전 선택

API 언어 런타임 버전을 구성하려면 platform 섹션의 apiRuntime 속성을 지원되는 다음 값 중 하나로 설정합니다.

언어 런타임 버전	운영 체제	Azure Functions 버전	`apiRuntime` 값	지원 종료 날짜
.NET Core 3.1	Windows	3.x	`dotnet:3.1`	2022년 12월 3일 토요일
.NET 6.0 In Process	Windows	4.x	`dotnet:6.0`	-
.NET 6.0 격리	Windows	4.x	`dotnet-isolated:6.0`	-
.NET 7.0 격리	Windows	4.x	`dotnet-isolated:7.0`	-
.NET 8.0 격리됨	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	2022년 12월 3일 토요일
Node.js 14.x	Linux	4.x	`node:14`	-
Node.js 16.x	Linux	4.x	`node:16`	-
Node.js 18.x (공개 미리 보기)	Linux	4.x	`node:18`	-
Python 3.8	Linux	4.x	`python:3.8`	-
Python 3.9	Linux	4.x	`python:3.9`	-
Python 3.10	Linux	4.x	`python:3.10`	-

.NET

.NET 앱에서 런타임 버전을 변경하려면 csproj 파일의 TargetFramework 값을 변경합니다. 선택적이지만 staticwebapp.config.json 파일에서 apiRuntime 값을 설정하는 경우 값이 csproj 파일에서 정의한 값과 일치하는지 확인합니다.

다음 예제에서는 csproj 파일에서 NET 8.0에 대한 TargetFramework 요소를 API 언어 런타임 버전으로 업데이트하는 방법을 보여 줍니다.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.JS

다음 예제 구성은 apiRuntime 속성을 사용하여 staticwebapp.config.json 파일에서 Node.js 16을 API 언어 런타임 버전으로 선택하는 방법을 보여 줍니다.

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

다음 예제 구성은 apiRuntime 속성을 사용하여 staticwebapp.config.json 파일에서 Python 3.8을 API 언어 런타임 버전으로 선택하는 방법을 보여 줍니다.

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

네트워킹

networking 섹션은 정적 웹앱의 네트워크 구성을 제어합니다. 앱에 대한 액세스를 제한하려면 allowedIpRanges에서 허용되는 IP 주소 블록 목록을 지정합니다. 허용되는 IP 주소 블록 수에 대한 자세한 내용은 Azure Static Web Apps의 할당량을 참조하세요.

참고 항목

네트워킹 구성은 Azure Static Web Apps 표준 플랜에서만 사용할 수 있습니다.

각 IPv4 주소 블록을 CIDR(Classless Interdomain Routing) 표기법으로 정의합니다. CIDR 표기법에 관한 자세한 내용은 Classless Inter-domain Routing을 참조하세요. 각 IPv4 주소 블록은 퍼블릭 또는 프라이빗 주소 공간을 나타낼 수 있습니다. 단일 IP 주소에 대한 액세스만 허용하려는 경우 /32 CIDR 블록을 사용할 수 있습니다.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

하나 이상의 IP 주소 블록을 지정한 경우 allowedIpRanges의 값과 일치하지 않는 IP 주소에서 시작된 요청은 액세스가 거부됩니다.

IP 주소 블록 외에도 allowedIpRanges 배열에 서비스 태그를 지정하여 트래픽을 특정 Azure 서비스로 제한할 수도 있습니다.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

인증

기본 인증 공급자는 구성 파일의 설정이 필요하지 않습니다.
사용자 지정 인증 공급자는 설정 파일의 auth 섹션을 사용합니다.

인증된 사용자로 경로를 제한하는 방법에 대한 자세한 내용은 역할을 사용하여 경로 보호를 참조하세요.

인증된 경로에 대한 캐시 사용 안 함

Azure Front Door와 수동 통합을 설정하는 경우 보안 경로에 대한 캐싱을 사용하지 않도록 설정할 수 있습니다. 엔터프라이즈급 에지를 사용하도록 설정하면 보안 경로에 대해 캐싱이 이미 비활성화되어 있습니다.

보안 경로에 대해 Azure Front Door 캐싱을 사용하지 않도록 설정하려면 경로 헤더 정의에 "Cache-Control": "no-store"를 추가합니다.

예시:

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

전달 게이트웨이

이 섹션에서는 forwardingGateway CDN(Content Delivery Network) 또는 Azure Front Door와 같은 전달 게이트웨이에서 정적 웹앱에 액세스하는 방법을 구성합니다.

참고 항목

전달 게이트웨이 구성은 Azure Static Web Apps 표준 플랜에서만 사용할 수 있습니다.

허용되는 전달된 호스트

allowedForwardedHosts 목록은 X-Forwarded-Host 헤더에 허용할 호스트 이름을 지정합니다. 일치하는 도메인이 목록에 있는 경우 Static Web Apps는 리디렉션 URL을 생성할 때(예: 성공적으로 로그인한 이후) X-Forwarded-Host 값을 사용합니다.

Static Web Apps가 전달 게이트웨이 뒤에서 올바르게 작동하려면 게이트웨이의 요청에는 X-Forwarded-Host 헤더에 올바른 호스트 이름이 포함되어야 하며 동일한 호스트 이름이 allowedForwardedHosts에 나열되어야 합니다.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

X-Forwarded-Host 헤더가 목록의 값과 일치하지 않아도 요청은 성공하지만 헤더가 응답에 사용되지 않습니다.

필수 헤더

필수 헤더는 각 요청과 함께 사이트로 보내야 하는 HTTP 헤더입니다. 필수 헤더의 용도 중 하나는 각 요청에 필요한 모든 헤더가 있지 않을 경우에 사이트에 대한 액세스를 거부하는 것입니다.

예를 들어 다음 구성에서는 특정 Azure Front Door 인스턴스에서 사이트에 대한 액세스를 제한하는 Azure Front Door에 대한 고유 식별자를 추가하는 방법을 보여 줍니다. 자세한 내용은 Azure Front Door 구성 자습서를 참조하세요.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

키/값 쌍은 임의의 문자열 집합일 수 있습니다.
키는 대/소문자를 구분하지 않습니다.
값은 대/소문자를 구분합니다.

후행 슬래시

후행 슬래시는 URL의 끝에 있는 /입니다. 일반적으로 후행 슬래시 URL은 웹 서버의 디렉터리를 참조하는 반면, 비레일링 슬래시는 파일을 나타냅니다.

검색 엔진은 파일이든 디렉터리이든 관계없이 두 URL을 개별적으로 처리합니다. 두 URL 모두에서 동일한 콘텐츠가 렌더링되면 웹 사이트에서 중복 콘텐츠를 제공하여 SEO(검색 엔진 최적화)에 부정적인 영향을 미칠 수 있습니다. 명시적으로 구성된 경우 Static Web Apps는 웹 사이트의 성능 및 SEO를 개선하는 데 도움이 되는 URL 정규화 및 리디렉션 규칙 집합을 적용합니다.

사용 가능한 각 구성에 대해 다음 정규화 및 리디렉션 규칙이 적용됩니다.

Always

trailingSlash를 always로 설정하면 후행 슬래시를 포함하지 않는 모든 요청이 후행 슬래시 URL로 리디렉션됩니다. 예를 들어, /contact는 /contact/로 리디렉션됩니다.

"trailingSlash": "always"

다음에 대한 요청...	반환 항목	상태	및 경로...
/about	/about/index.html 파일	`301`	/about/
/about/	/about/index.html 파일	`200`	/about/
/about/index.html	/about/index.html 파일	`301`	/about/
/contact	/contact.html 파일	`301`	/contact/
/contact/	/contact.html 파일	`200`	/contact/
/contact.html	/contact.html 파일	`301`	/contact/

안 함

로 설정 trailingSlashnever하면 후행 슬래시로 끝나는 모든 요청이 비레일링 슬래시 URL로 리디렉션됩니다. 예를 들어, /contact/는 /contact로 리디렉션됩니다.

"trailingSlash": "never"

다음에 대한 요청...	반환 항목	상태	및 경로...
/about	/about/index.html 파일	`200`	/about
/about/	/about/index.html 파일	`301`	/about
/about/index.html	/about/index.html 파일	`301`	/about
/contact	/contact.html 파일	`200`	/contact
/contact/	/contact.html 파일	`301`	/contact
/contact.html	/contact.html 파일	`301`	/contact

자동

trailingSlash를 auto로 설정하면 폴더에 대한 모든 요청이 뒤에 슬래시가 있는 URL로 리디렉션됩니다. 파일에 대한 모든 요청은 비레일링 슬래시 URL로 리디렉션됩니다.

"trailingSlash": "auto"

다음에 대한 요청...	반환 항목	상태	및 경로...
/about	/about/index.html 파일	`301`	/about/
/about/	/about/index.html 파일	`200`	/about/
/about/index.html	/about/index.html 파일	`301`	/about/
/contact	/contact.html 파일	`200`	/contact
/contact/	/contact.html 파일	`301`	/contact
/contact.html	/contact.html 파일	`301`	/contact

최적의 웹 사이트 성능을 위해 , never또는 auto 모드 중 always하나를 사용하여 후행 슬래시 전략을 구성합니다.

기본값으로 trailingSlash 구성을 생략하면 Static Web Apps는 다음 규칙을 적용합니다.

다음에 대한 요청...	반환 항목	상태	및 경로...
/about	/about/index.html 파일	`200`	/about
/about/	/about/index.html 파일	`200`	/about/
/about/index.html	/about/index.html 파일	`200`	/about/index.html
/contact	/contact.html 파일	`200`	/contact
/contact/	/contact.html 파일	`301`	/contact
/contact.html	/contact.html 파일	`200`	/contact.html

구성 파일 예

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/twitter",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

위의 구성에 따라 다음 시나리오를 검토합니다.

다음에 대한 요청...	결과
/profile	인증된 사용자에게는 /profile/index.html 파일이 제공됩니다. 인증되지 않은 사용자는 `401` 응답 재정의 규칙에 의해 /login으로 리디렉션됩니다.
/admin, /admin/ 또는 /admin/index.html	관리자 역할의 인증된 사용자에게는 /admin/index.html 파일이 제공됩니다. 인증되었지만 관리자 역할에 없는 사용자에게는 `403` 오류¹가 표시됩니다. 인증되지 않은 사용자는 /login으로 리디렉션됩니다.
/images/logo.png	최대 사용 기간이 182일(15,770,000초)을 약간 초과하는 사용자 지정 캐시 규칙을 이미지에 적용합니다.
/api/admin	registeredusers 역할이 있는 인증된 사용자의 `GET` 요청은 API로 전송됩니다. 인증되었지만 registeredusers 역할에 없는 사용자와 인증되지 않은 사용자에게는 `401` 오류가 표시됩니다. 관리자 역할의 인증된 사용자가 수행하는 `POST`, `PUT`, `PATCH` 및 `DELETE` 요청은 API로 전송됩니다. 인증되었지만 관리자 역할에 없는 사용자와 인증되지 않은 사용자에게는 `401` 오류가 표시됩니다.
/customers/contoso	관리자 또는 customers_contoso 역할에 속하는 인증된 사용자에게는 /customers/contoso/index.html 파일이 제공됩니다. 인증되었지만 관리자 또는 customers_contoso 역할에 없는 사용자에게는 `403` 오류¹가 표시됩니다. 인증되지 않은 사용자는 /login으로 리디렉션됩니다.
/login	인증되지 않은 사용자는 GitHub를 사용하여 인증해야 합니다.
/.auth/login/twitter	경로 규칙에 `404` 따라 Twitter 권한 부여를 사용하지 않도록 설정하므로 오류가 반환됩니다. 이 오류는 상태 코드로 /index.html 서비스로 `200` 돌아갑니다.
/logout	사용자는 모든 인증 공급자에서 로그아웃됩니다.
/calendar/2021/01	브라우저에는 /calendar.html 파일이 제공됩니다.
/specials	브라우저가 영구적으로 /deals 파일로 리디렉션됩니다.
/data.json	`text/json` MIME 형식의 파일이 제공됩니다.
/about 또는 클라이언트 쪽 라우팅 패턴과 일치하는 모든 폴더	/index.html 파일이 `200` 상태 코드와 함께 제공됩니다.
/images/folder에 존재하지 않는 파일	`404` 오류가 표시됩니다.

¹응답 재정의 규칙을 사용하여 사용자 지정 오류 페이지를 제공할 수 있습니다.

제한 사항

staticwebapp.config.json 파일에는 다음과 같은 제한이 있습니다.

최대 파일 크기는 20KB입니다.
고유 역할은 최대 50개

일반적인 제한 사항은 할당량 문서를 참조하세요.

다음 단계

인증 및 권한 부여 설정

Azure Static Web Apps 구성

파일 위치

경로

경로 정의

경로 패턴 지정

정확한 경로

와일드카드 패턴

역할을 사용하여 경로 보호

전체 애플리케이션에 대한 액세스 제한

대체 경로

글로벌 헤더

응답 재정의

플랫폼

API 언어 런타임 버전 선택

.NET

Node.JS

Python

네트워킹

인증

인증된 경로에 대한 캐시 사용 안 함

전달 게이트웨이

허용되는 전달된 호스트

필수 헤더

후행 슬래시

Always

안 함

자동

구성 파일 예

제한 사항

다음 단계

관련된 문서

추가 리소스