Language:
Format:

개발자 포털 생성

Red Hat 3scale 2-saas

좋은 개발자 포털은 API를 계속 채택해야 합니다. 시간 내에 을 만듭니다.

Red Hat Customer Content Services

초록

이 가이드에서는 Red Hat 3scale 2saas의 개발자 포털을 설명합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 향후 여러 릴리스에 대해 단계적으로 구현될 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서 참조하십시오.

1장. 3scale 관리 API용 개발자 포털 생성 개요

3scale 개발자 포털은 API 소비자가 사용하는 웹 사이트입니다.

3scale 관리 업스트림 API에 대한 액세스에 등록합니다.
업스트림 API 사용 방법에 대한 문서 읽기

3scale은 대부분의 API 공급자가 개발자 포털에서 구현하려는 기능을 샘플 개발자 포털에 제공합니다. 이 네이티브 개발자 포털은 샘플 Echo API를 사용하여 일반적인 개발자 포털의 구조를 보여줍니다. 네이티브 개발자 포털을 탐색한 후 고유한 개발자 포털을 생성하는 방법을 배울 수 있도록 해당 포털을 변경하는 방법에 대한 지침이 있습니다.

네이티브 개발자 포털을 탐색하고 수정하기 위한 사전 요구 사항은 없습니다. 그러나 자체 개발자 포털을 생성하도록 네이티브 개발자 포털을 수정한 후에는 API 소비자에 대한 개발자 포털을 열기 전에 로그인 워크플로 및 인증도 구현해야 합니다.

1.1. 개발자 포털을 생성하기 위한 3scale 편집 환경 구성

개발자 포털을 생성하기 전에 3scale과 함께 제공되는 샘플 Echo API 개발자 포털을 살펴봅니다. Echo API 개발자 포털은 자체 개발자 포털을 생성하기 위한 시작점입니다. 개발자 포털을 처음부터 생성하지 않습니다. 대신 기본 Echo API 개발자 포털을 수정하여 원하는 모양과 느낌의 개발자 포털을 생성합니다.

프로세스

3scale 관리 포털에서 상단에 있는 컨텍스트 선택기를 확장하고 Audience 를 클릭합니다.
왼쪽의 탐색 트리에서 개발자 포털 을 확장하고 콘텐츠를 클릭합니다. 개발자 포털을 생성하기 위한 주요 편집 환경이 표시됩니다.
Root 아래에서 3scale은 개발자 포털 리소스 계층 구조를 표시합니다.
1. 문서 , 홈 페이지 및 표시는 개발자 포털의 기본 페이지입니다. 각 페이지에 대해 아래로 스크롤하여 페이지 콘텐츠를 정의하는 HTML을 확인합니다.
2. 해당 페이지 아래의 폴더에는 3scale 리소스를 개발자 포털로 가져오는 페이지가 포함되어 있습니다. 예를 들어 계정 폴더에는 3scale 관리자가 관리 포털에서 생성한 3scale 계정을 표시하고 편집하기 위한 페이지가 포함되어 있습니다. 이 페이지를 시작점으로 사용하고 필요에 따라 수정합니다.
3. 오른쪽 상단에서 새 페이지 드롭다운을 사용하면 페이지, 레이아웃, 부분, 섹션, 파일 또는 포틀릿을 추가할 수 있습니다. 하나를 만들려면 각 항목을 선택하여 제공하는 정보를 확인합니다.
개발자 포털 > 콘텐츠를 선택한 상태에서 레이아웃이 표시될 때까지 리소스 계층 구조를 거의 아래로 스크롤하고 기본 레이아웃을 클릭합니다.
레이아웃 'Main Layout' 제목이 표시되도록 맨 위로 스크롤합니다.
내부 제목 및 시스템 이름 후에 리쿼드가 활성화되어 있음을 확인할 수 있습니다. 유동성은 3scale 시스템에서 대부분의 데이터를 표시하고 처리하는 데 사용하는 프레임워크입니다. 페이지 콘텐츠를 정의하는 코드에는 리쿼드 태그와 HTML이 포함되어 있습니다. 개발자 포털 페이지의 기본 레이아웃 코드가 포함된 Draft 탭에서 확인할 수 있습니다.
왼쪽의 탐색 트리에서 개발자 포털 > 콘텐츠 아래에서 각 하위 범주를 차례로 클릭하여 Drafts ,Redirects,Groups,Logo,Feature Visibility, ActiveDocs.
왼쪽의 탐색 트리에서 개발자 포털 아래 마지막 항목인 Visit Portal 을 클릭합니다.
새 브라우저 탭에는 3scale 제공 Echo API 개발자 포털의 개발 버전에 대한 웹 페이지가 표시됩니다. 이 개발 버전을 사용하여 3scale 네이티브 개발자 포털을 확인합니다. 그런 다음 기본 개발자 포털을 반복적으로 사용자 지정하고 변경 사항을 확인하여 고유한 개발자 포털을 생성할 수 있습니다.
이는 Draft|Published at the right에 다크 회색 패널이 있기 때문에 개발자 포털의 개발 버전입니다. Draft 보기는 반복/수상 개선 사항을 지원합니다. Draft 버전은 원하는 방식으로 보이고 작동하면 게시할 수 있습니다.
오른쪽 패널에는 현재 페이지의 콘텐츠를 제공하는 요소가 나열됩니다.
1. 페이지 홈 페이지
2. 레이아웃 기본 레이아웃
3. 부분적인 하위 메뉴
4. 부분적인 분석
페이지 홈 페이지를 클릭합니다. 편집할 수 있도록 페이지 'homepage' 가 열려 있는 개발자 포털 편집 환경이 새 브라우저 탭에 표시됩니다.
Echo API 개발자 포털의 개발 버전으로 돌아가서 오른쪽 상단에서 API 소비자가 개발자 포털에 로그인하는 데 사용하는 SIGN IN 페이지가 표시됩니다.
오른쪽의 회색 패널에서 템플릿 목록 아래에는 개발자 포털에 로그인을 시뮬레이션하는 데 사용할 수 있는 사용자 이름과 암호가 있습니다.
1. SIGN IN 페이지의 USERNAME OR EMAIL (사용자 이름 또는 EMAIL) 필드에 오른쪽의 회색 패널에 나열된 사용자 이름인 0.0.0.0/0을 입력합니다.
2. PASSWORD 필드에 회색 패널에 나열된 암호인 123456 을 입력합니다.
3. Sign In 을 클릭하여 API 소비자가 볼 수 있듯이 개발자 포털을 표시합니다.

다음 단계

계속해서 기본 개발자 포털을 원하는 만큼 탐색합니다. 편집 환경 및 Echo API 개발자 포털의 개발 버전을 쉽게 탐색하는 경우 3scale 네이티브 개발자 포털을 수정하는 절차를 따르십시오.

1.2. 3scale 네이티브 개발자 포털 수정

Echo API 개발자 포털을 탐색한 후 자체 개발자 포털을 생성하기 전에 변경합니다. 이러한 실습 단계는 개발자 포털 생성을 준비하는 데 도움이 됩니다.

이 절차에서는 샘플 3scale Echo API 시작 페이지 제목을 공통 Swagger Petstore API의 제목으로 교체합니다. 또한 Petstore API에 대한 문서를 표시하도록 개발자 포털을 업데이트하는 방법도 보여줍니다.

프로세스

3scale 관리 포털에서 상단에 있는 컨텍스트 선택기를 확장하고 Audience 를 클릭합니다.
왼쪽의 탐색 트리에서 개발자 포털 을 확장하고 콘텐츠를 클릭합니다.
Root 에서 개발자 포털 방문 페이지의 내부 제목인 Homepage 를 클릭하고 개발자 포털의 개발 버전에 표시되는 시작 페이지 제목을 변경합니다.
1. 페이지 '홈페이지' 에서 아래로 스크롤하여 랜딩 페이지를 렌더링하는 코드를 확인합니다.
2. 5 줄에서 변경
```
<h1>Echo API</h1>
```
  다음으로 변경
```
<h1>Petstore API</h1>
```
3. 페이지 하단에서 게시 를 클릭합니다.
4. 왼쪽의 탐색 트리에서 개발자 포털 을 클릭하여 개발자 포털 의 개발 버전을 표시하고 시작 페이지 제목이 Petstore API 인지 확인합니다.
개발자 포털의 개발 버전에 남아 있으며 상단 메뉴 표시줄에 있는 문서 를 클릭합니다. 개발자 포털에는 Echo API의 ActiveDocs가 표시됩니다.
3scale 관리 포털로 돌아가서 개발자 포털 > ActiveDocs 를 선택하여 Echo API에 대한 항목을 확인합니다. 3scale은 Echo API를 정의하는 OpenAPI 문서를 제공합니다. 3scale은 이 OpenAPI 문서를 사용하여 Echo API의 ActiveDocs를 표시합니다.
Swagger Petstore API를 정의하는 OpenAPI 문서를 가져옵니다.
1. https://petstore.swagger.io/v2/swagger.json 로 이동하여 JSON 콘텐츠를 클립보드에 복사합니다.
2. 개발자 포털 > ActiveDocs 선택된 상태에서 3scale 관리 포털 로 돌아갑니다.
3. ActiveDocs 페이지에서 새 사양 만들기 를 클릭합니다.
4. 이름 필드에 Petstore 를 입력합니다.
5. 게시 를 선택합니다.
6. API JSON 사양 창에서 클릭하고 클립보드에서 Swagger Petstore JSON 콘텐츠를 붙여넣습니다.
7. 페이지 하단에서 Create Spec 를 클릭합니다. 3scale은 Petstore API의 ActiveDocs를 표시합니다.
8. 왼쪽의 탐색 트리에서 개발자 포털 의 ActiveDocs 를 클릭합니다. Echo API 후 Petstore 의 두 번째 항목이 있습니다.
개발자 포털에서 Petstore API에 대한 문서를 표시합니다.
1. 왼쪽의 탐색 트리에서 개발자 포털 의 콘텐츠를 클릭합니다.
2. Root 에서 개발자 포털 설명서 페이지의 내부 제목인 문서 를 클릭합니다.
3. 페이지 '설명서' 에서 아래로 스크롤하여 문서 방문 페이지를 렌더링하는 코드를 확인합니다. 5 행은 개발자 포털에 ActiveDocs가 표시되는 OpenAPI 문서를 식별합니다. 5 행의 기본값은 다음과 같습니다.
```
{% assign spec = provider.api_specs.first %}
```
  기본 동작은 개발자 포털에서 처음에 Echo API인 개발자 포털 > ActiveDocs 페이지의 첫 번째 항목에 대한 ActiveDocs 가 표시된다는 것입니다. 이 그림은 5 행을 강조합니다.
4. ActiveDocs 페이지에서 두 번째 항목을 식별하는 인덱스가 있도록 5 행을 수정하여 provider.api_specs.first 를 변경합니다.
```
{% assign spec = provider.api_specs[1] %}
```
  기본 동작은 개발자 포털에는 하나의 OpenAPI 문서에 대한 ActiveDocs가 표시됩니다. 두 개 이상의 OpenAPI 문서에 대한 ActiveDocs를 표시하려면 이 간단한 변경 사항 이외의 문서 페이지를 수정해야 합니다.
5. 페이지 하단에서 게시 를 클릭합니다.
왼쪽의 탐색 트리에서 개발자 포털 아래에서 방문 포털 을 클릭하여 개발자 포털의 개발 버전을 표시합니다.
상단 메뉴 모음에서 문서를 클릭하여 Swagger Petstore 설명서를 확인합니다.

다음 단계

네이티브 개발자 포털 페이지를 변경하여 개발자 포털 생성을 시작하여 3scale 관리 API에 대한 액세스 및 API 설명서에 대한 액세스에 대한 정보를 표시합니다.

1.3. 네이티브 개발자 포털을 변경하기 위한 추가 3scale 기능에 대한 설명

3scale은 네이티브 개발자 포털을 사용자 정의하여 고유한 개발자 포털을 생성하는 다양한 기능을 제공합니다.

개발자 포털을 개발하는 동안 개발자 포털을 확인해야 하는 모든 사용자는 액세스 코드를 지정해야 합니다. API 공급자가 API 소비자가 액세스할 수 있도록 개발자 포털을 여는 데 필요한 작업을 수행하는 동안 이 액세스 코드를 보관합니다. 액세스 코드는 사용자 또는 이 코드가 있는 사용자만 개발자 포털을 볼 수 있도록 합니다. 액세스 코드는 Domains & Access 페이지에 있으며 Audience > Developer Portal > Domains & Access 를 선택하여 관리 포털에서 사용할 수 있습니다.

다음 목록에는 기본 개발자 포털을 수정하는 몇 가지 기능이 포함되어 있습니다.

개발자 포털 > 콘텐츠 환경에서 오른쪽 상단에 있는 새 페이지 드롭다운을 통해 개발자 포털에 다음 요소를 추가할 수 있습니다.
- 페이지 - 개발자 포털 콘텐츠의 기본 단위입니다.
- 레이아웃 - 여러 페이지가 사용할 수 있는 템플릿입니다.
- 부분 - 다른 부분, 레이아웃 및 페이지에서 재사용할 수 있는 콘텐츠입니다.
- 섹션 - 디렉터리에 기능적으로 동일합니다. 개발자 포털 콘텐츠를 구성하는 섹션을 생성합니다.
- file - 개발자 포털에서 스타일 시트, 이미지 또는 스크립트와 같이 사용할 리소스입니다.
- Portlet - 외부 RSS 피드, 목차 또는 최신 포럼 게시물
HTML, 마크다운 또는 textile으로 코드를 입력할 수 있습니다. 코드 편집기는 코드 강조 표시, 탭화, 줄 번호 및 기타 기능을 지원합니다.
페이지 초안 또는 게시된 버전을 미리 볼 수 있습니다. 페이지의 텍스트 편집기 아래에 Preview 를 클릭하면 개발자 포털의 개발 버전이 표시됩니다.
미리 보기에는 오른쪽에 어두운 회색 세로 막대가 있습니다. 어두운 회색 표시줄의 맨 위에는 Draft | Published 중 하나가 보고 있는 버전을 나타내는 강조 표시됩니다. 이 모음에는 다음을 위한 편집 환경에 대한 링크가 포함되어 있습니다.
- 페이지입니다.
- 페이지가 사용하는 레이아웃입니다.
- 페이지가 사용하는 부분 요소입니다. 부분적은 다른 페이지의 여러 위치에서 재사용할 수 있는 코드입니다.
개발자 포털의 개발 버전에 대한 Draft 보기는 반복/수상 개선 사항을 지원합니다. Draft 버전이 올바르게 보이고 작동하는 경우 이를 게시할 수 있습니다. 액세스 코드가 있는 경우 페이지를 게시하면 개발자 포털이 활성화되어 있는지 API 소비자가 볼 수 있는 항목을 볼 수 있습니다. 액세스 코드가 더 이상 없으면 라이브 개발자 포털에서 페이지가 업데이트됩니다.
filter 필드를 사용하면 개발자 포털 환경에서 리소스를 검색할 수 있습니다. 3scale은 검색 중인 요소만 표시하므로 작업하려는 요소만 더 쉽게 찾을 수 있습니다. filter 필드는 아이콘 바로 아래에 있습니다.
개발자 포털 > 리디렉션 페이지를 사용하면 한 개발자 포털 URL에서 다른 개발자 포털 URL로 리디렉션을 설정할 수 있습니다. 예를 들어 생성한 페이지를 사용 중단하는 경우 요청을 새 페이지로 리디렉션할 수 있습니다.
자리 표시자는 편집 가능한 필드입니다. 예를 들어 개발자 포털 > 콘텐츠 > 로그인 > 새 페이지에는 여러 자리 표시자가 있습니다.
```
<input id="session_username" name="username" tabindex="1"
  autofocus="autofocus" type="text"
  placeholder="Authenticate with your email"
  class="form-control">
...
<input id="session_password" name="password" tabindex="2"
  type="password"
  placeholder="…and password"
  class="form-control">
```
이 코드는 개발자 포털에 다음 필드를 생성합니다.
자리 표시자 텍스트를 업데이트하여 게시하여 개발자 포털에서 업데이트를 확인할 수 있습니다. 예를 들어, 이메일을 사용하여 Authenticate 를 이메일 인증으로 변경할 수 있습니다. 페이지를 게시한 후 개발자 포털에 업데이트된 프롬프트가 표시됩니다. 예를 들면 다음과 같습니다.

1.4. 3scale 레이아웃 및 부분 중 개발자 포털을 재사용하는 방법

개발자 포털 > 콘텐츠 환경에서 리소스 계층 구조에서 아래로 스크롤하면 레이아웃 및 파트에 대한 제목을 볼 수 있습니다. 레이아웃 및 일부를 사용하면 개발자 포털에서 콘텐츠를 재사용할 수 있습니다.

레이아웃은 페이지의 기본 구조를 정의하고 페이지 템플릿으로 작동합니다. 특정 레이아웃을 사용하는 모든 페이지에는 레이아웃에서 정의하는 콘텐츠가 포함되어 있습니다. Layouts 의 리소스 계층 구조에서 볼 수 있듯이 기본 개발자 포털에서는 Error 레이아웃과 Main 레이아웃 을 제공합니다. 이러한 레이아웃의 코드를 수정하고 레이아웃을 만들 수 있습니다.
부분적인 정의는 개발자 포털에서 둘 이상의 위치에서 사용하는 코드를 정의합니다. 예를 들어 부분적으로는 모든 레이아웃 또는 여러 페이지의 사이드바에 발너를 정의할 수 있습니다. 페이지, 레이아웃, 다른 부분 또는 이메일 템플릿에서 부분적을 사용할 수 있습니다. 리소스 계층 구조에서 기본 개발자 포털에서 제공하는 부분만 볼 수 있습니다. 분석 수집, 애플리케이션 계획 구독, 하위 메뉴 표시 등에는 부분적 요소가 있습니다. 다시 말하지만, 이러한 부분만 수정하면 부분만 생성할 수 있습니다.
부분적 사용을 위해 페이지, 레이아웃, 부분 또는 이메일 템플릿에서는 부분적 이름으로 include 명령을 지정합니다. 예를 들어 부분 메뉴의 일부를 사용하려면 다음을 지정합니다.
```
{% include “submenu” %}
```

레이아웃 및 부분에는 초안 및 게시된 상태뿐만 아니라 버전 기록이 있습니다. 예를 들어 초안을 저장하고 게시한 후 마지막으로 게시된 버전으로 되돌릴 수 있습니다.

레이아웃 및 부분적인 코드 편집 및 작성에 대한 자세한 내용은 3scale 리쿼드 참조를 참조하십시오.

1.5. 3scale 관리 API의 개발자 포털에 이미지 및 기타 자산 추가

일반적으로 자체 이미지, 파일 또는 기타 자산을 사용하여 기본 개발자 포털을 사용자 지정하려고 합니다. 이렇게 하려면 개발자 포털 콘텐츠 라이브러리에 파일을 추가하고 이 환경의 경로를 기록한 다음 콘텐츠 라이브러리에 있는 파일의 위치에 링크를 추가합니다.

사전 요구 사항

개발자 포털에서 사용하려는 이미지, 파일 또는 기타 자산에 대한 액세스

프로세스

개발자 포털 콘텐츠 라이브러리에 자산을 추가합니다.
1. 개발자 포털 > 콘텐츠 환경의 오른쪽 상단에서 새 페이지를 확장하고 새 파일을 선택합니다.
2. Upload File (파일 업로드)에서 섹션 필드를 클릭하여 추가하는 자산을 저장할 수 있는 디렉터리 목록을 표시하고 적절한 디렉터리를 클릭하여 선택합니다. 예를 들어 |- 이미지를 선택할 수 있습니다.
3. 선택 사항: 경로 필드에 유용한 추가 경로 수준을 입력합니다.
4. Downloadable 을 선택합니다.
5. Choose File 을 클릭하고 추가할 파일로 이동한 다음 Open 을 클릭합니다.
6. 선택 사항: Tag 목록 필드에 이 새 콘텐츠를 코드에 포함하는 데 사용할 리쿼드 태그를 입력합니다. 예를 들어 my-logo 를 입력할 수 있습니다.
7. Create File 을 클릭하여 개발자 포털 콘텐츠 라이브러리에 자산을 추가합니다.
추가한 자산의 경로를 기록합니다. 예를 들어 MyLogo.png 이미지를 이미지 섹션에 추가한 경우 경로는 / images /MyLogo.png 입니다.
코드에서 자산을 사용하려면 HTML < a> 요소를 삽입합니다. 예를 들면 다음과 같습니다.
```
<a href="/images/MyLogo.png"/>
```
또는 자산에 리쿼드 태그를 추가한 경우 태그를 지정하여 자산을 코드로 사용할 수 있습니다. 예를 들면 다음과 같습니다.
```
{% my-logo %}
```

1.6. 3scale 관리 API에 대한 기본 개발자 포털 사용자 정의 고려 사항

고유한 개발자 포털을 생성하기 위해 기본 개발자 포털을 사용자 정의하기 전에 기본 요소, 재사용 가능한 콘텐츠, 페이지 계층 구조, 페이지 헤더 및 발작 및 브랜딩에 대한 계획이 있어야 합니다.

기본 개발자 포털 요소 - 개발자 포털 계획에는 다음이 포함되어야 합니다.
- 사이트 맵: 포털 구성 방법의 개념.
- 상단 메뉴 표시줄: 각 페이지에서 반복되는 탐색입니다.
- 사이드 메뉴 표시줄: 각 섹션의 개별 페이지에 액세스합니다.
- 페이지 레이아웃 지침: 일관된 모양과 느낌의 경우.
- 재사용 가능 콘텐츠 - 레이아웃 및 부분적으로 개발자 포털에서 일관성을 보장합니다. 페이지를 만들기 전에 만듭니다.
페이지 계층 구조 - 사이트 맵의 루트 수준에서 시작하여 각 최상위 메뉴 항목에 대한 섹션을 만듭니다.
다음으로 각 최상위 메뉴 항목에 필요한 페이지를 생성합니다. 페이지를 만들 때는 올바른 섹션과 연결되어 있어야 합니다. 이렇게 하면 개발자 포털의 URL 경로에 대한 일관된 구조가 생성됩니다. 텍스트 또는 마크다운과 같은 태그 언어로 페이지를 코딩하려면 페이지의 ADVANCED 옵션을 확장합니다. Handler 필드는 태그 언어를 식별합니다.
페이지 헤더 및 하위 페이지 요소(Repetitive page elements are typically defined in partials) 몇 개의 레이아웃만 있으면 부분적인 것이 아니라 레이아웃에서 직접 헤더와 footers를 정의하는 것을 선호할 수 있습니다.
브랜딩 - 기본 네이티브 개발자 포털 스타일시트, default.css 는 크고 복잡합니다. 이 스타일 시트를 확장하는 대신 기본값을 덮어쓰는 사용자 지정으로 고유한 스타일 시트를 만듭니다.
페이지를 만드는 것과 동일한 방식으로 새 스타일 시트를 만들 수 있습니다. 고급 페이지 설정에서 css 섹션 및 적절한 MIME 콘텐츠 유형을 선택합니다. 그런 다음 레이아웃에서 default.css 에 대한 링크 후 사용자 지정 스타일 시트에 대한 링크를 추가합니다. 예를 들어 my-custom.css 를 생성하는 경우 다음을 삽입합니다.
```
<link rel="stylesheet" href="/css/my-custom.css" />
```
수정할 수 없는 기본 제공 기능은 다음과 같습니다.
- 페이지 번호
- 메시지 메뉴
- 포럼 - 레이아웃만 변경할 수 있습니다.
- payment - 이러한 페이지의 일부 텍스트 필드만 편집할 수 있습니다.

1.7. 3scale 관리 API에 대한 개발자 포털에 대한 액세스 허용 요구 사항

개발자 포털에 대한 API 소비자 액세스 권한을 부여하려면 API 공급자가 다음 작업을 수행해야 합니다. 이러한 작업은 동시에 수행할 수 있습니다.

원하는 모양과 느낌으로 3scale 네이티브 개발자 포털을 변경합니다.
- 유동성: 개발자 포털 은 리쿼드 태그를 사용하여 API와 관련된 3scale 시스템 데이터를 표시하고 처리하는 방법을 보여줍니다. 유동 마크업은 개발자 포털 페이지에 논리를 추가하는 기본 방법입니다.
- 개발자 포털 레이아웃 사용자 지정 에서는 고유한 브랜딩과 일치하도록 네이티브 개발자 포털을 변경하는 방법을 설명합니다. 표준 CCS(cascading stylesheet)를 통해 사용자 지정에 쉬운 시작점을 제공할 수 있습니다.
- 변경 기본 제공 페이지는 CSS 및 JavaScript를 사용하여 시스템 생성 페이지에서 요소를 수정하거나 숨기는 방법을 설명합니다. 네이티브 개발자 포털의 일부로 제공되는 모든 페이지를 시스템 생성 페이지라고 합니다.
HTML, CSS, 리쿼드 및 웹 사이트에 익숙한 개발자는 네이티브 Echo API 개발자 포털을 수정하여 개발자 포털 웹 페이지를 생성할 수 있습니다. 이 개발자는 페이지를 생성하고 시스템 생성 페이지에서 코드를 수정하여 개발자 포털에서 API 소비자가 볼 수 있는 모든 항목을 생성할 수 있습니다.
3scale API 제품, 백엔드 및 애플리케이션 계획을 정의하고 제품에 정책을 할당합니다.
3scale 제품은 사용자에게 API를 노출하는 3scale 리소스입니다. 개발자 포털에서 API 소비자는 제품에 대한 문서를 읽고 제품에서 제공하는 API를 사용하도록 구독합니다. 3scale 제품에는 다음과 같은 특징이 있습니다.
- 번들은 사용자가 생성한 내부 3scale API인 하나 이상의 백엔드입니다.
- 제한, 가격 및 사용 가능한 기능과 관련하여 제품 사용에 대한 규칙을 정의하는 애플리케이션 계획이 있습니다.
- 에는 게이트웨이가 API로 보내기 전에 API 소비자 호출을 처리하는 방법에 대한 APIcast 게이트웨이 구성이 있습니다. 제품에 추가하는 정책은 기본 APIcast 게이트웨이 동작을 변경합니다.
관리 포털 가이드를 참조하십시오.
3scale 관리 API를 정의하고 문서화하는 OpenAPI 문서를 가져옵니다.
개발자 포털의 기반은 API를 정의하는 OpenAPI 문서입니다. OpenAPI 문서를 3scale로 가져올 때 3scale은 ActiveDocs를 생성하거나 업데이트하여 API에 대한 기능 문서를 즉시 사용할 수 있도록 합니다. 개발자 포털에서 API 소비자는 이 문서를 사용하여 API를 탐색, 테스트 및 통합합니다.
OpenAPI 문서에 정의된 각 작업에 대해 문서를 가져오면 3scale이 메서드 및 매핑 규칙을 생성합니다. 메서드 및 매핑 규칙은 API 소비자 액세스에 대한 제한 및 규칙을 적용하는 데 도움이 됩니다.
개발자 포털의 Providing API 인 3scale 가이드에는 3scale 및 OpenAPI 문서 작업에 대한 정보 및 절차가 포함되어 있습니다. 특히 3scale 사양으로 사용할 OpenAPI 문서 작성 방법 및 3scale 에 ActiveDocs 추가 를 참조하십시오.
API 소비자가 3scale 관리 API에 액세스하는 방법에 대한 워크플로우를 구성합니다.
등록 워크플로는 개발자 포털에서 API 소비자 경험의 중요한 측면입니다. 워크플로는 셀프 서비스 범위부터 누가 액세스 권한을 얻을 수 있는지에 대한 총 제어까지 다양할 수 있습니다. 계정, 서비스 및 애플리케이션 계획은 여러 수준의 세분성을 제공합니다. 각 수준에서는 운영하는 승인 게이트와 API 소비자가 어떤 선택을 해야 하는지 여부를 제어합니다.
최대 자동화 및 셀프 서비스를 위해 모든 승인 단계를 제거하고 가능한 모든 기본 계획을 활성화할 수 있습니다. 등록 직후 개발자 포털에서 개발자 포털에 대한 API 소비자 액세스 권한을 제공하는 키를 발행할 수 있습니다.
네이티브 개발자 포털은 사용자, 계정 및 애플리케이션 등록에 일반적으로 사용되는 필드를 제공합니다. 일반적으로 사용되는 필드에 사용자 지정 필드를 추가해야 할 수 있습니다. 자세한 내용은 등록 흐름 구성 및 사용자 정의 등록 양식 필드를 참조하십시오. 이메일 템플릿을 사용자 지정하기 전에 워크플로를 구성해야 합니다.
API 소비자 인증을 구현합니다.
개발자 포털에 대한 API 소비자 액세스 인증은 개발자 포털 리소스 및 API를 보호합니다. 다음 방법 중 하나를 사용하여 개발자 포털에 대한 액세스 권한을 인증할 수 있습니다.
개발자 포털 인증을 참조하십시오.
개발자 포털과 API 소비자 간의 이메일 통신을 위해 3scale 네이티브 템플릿을 사용자 정의합니다.
다양한 이벤트에서는 등록 시 계정 활성화 링크 제공, 암호 복구, 서비스 요금, 변경 알림 등 개발자 포털과 API 소비자 간의 통신이 필요합니다. 3scale은 개발자 포털이 API 소비자에게 보내는 각 일반적인 이메일 유형에 대한 템플릿을 제공합니다.
등록 워크플로를 정의한 후 이메일 메시지의 내용을 사용자 지정합니다. 이를 통해 개발자 포털에 설정한 워크플로우와 밀접하게 일치할 수 있습니다.
이메일 템플릿 및 i quids: 이메일 템플릿을 참조하십시오.
API 소비자가 3scale 관리 API에 액세스하기 위해 동의해야 하는 용어, 조건 및 정책을 지정합니다.
API 소비자가 API에 가입하고 호출할 수 있도록 허용하면 일반적으로 액세스 권한을 부여하기 전에 귀하의 용어, 조건 및 정책에 동의해야 합니다. 개발자 포털에서 두 개 이상의 서비스를 제공하는 경우 특정 애플리케이션을 사용하거나 특정 서비스를 사용하기 위해 다양한 버전의 용어(예: 등록)를 사용할 수 있습니다.
API 사용을 위해 비용을 청구하는 경우 신용 카드 정책에 동의해야 할 수 있습니다.
사용 약관 설정을 참조하십시오.
API 소비자 청구 및 신용 카드 게이트웨이를 설정합니다.
3scale 청구 프로세스는 매일 실행됩니다. 유료 서비스에 가입된 각 API 소비자 계정에 대한 송장을 생성합니다. 송장은 open, finalized, pending, unpaid, paid, failed, canceled 등 하나의 상태 중 하나에 포함될 수 있습니다. 3scale은 송장을 처리하도록 구성한 결제 게이트웨이를 사용합니다.
3scale 청구 프로세스는 사전 구매 또는 유료 모드로 실행할 수 있습니다. 3scale 청구는 해당 월을 기반으로 하며 해당 월의 첫날에 발생하는 특수 이벤트가 있습니다.
관리 포털 가이드, billing을 참조하십시오.

개발자 포털이 활성화되기 전에 수행해야 하는 마지막 작업은 액세스 코드를 제거하는 것입니다. 개발자 포털에 대한 액세스에 대한 인증 후에만 수행하며 개발자 포털을 철저히 테스트한 후 원하는 대로 작동하는지 확인합니다.

액세스 코드를 삭제하려면 개발자 포털 > 콘텐츠 환경을 표시합니다. 오른쪽 하단에서 세계로 포털 열기를 클릭하고 이 작업을 확인합니다.

1.8. 3scale 관리 API에 대한 개발자 포털을 사용자 정의하는 선택적 단계

API 소비자에 대한 개발자 포털을 열기 위한 요구 사항 외에도 다음을 수행할 수 있습니다.

개발자 포털에서 여러 API를 제공합니다.
3scale로 가져오는 각 OpenAPI 문서는 별도의 API 오퍼링을 위한 기반을 제공합니다. 여러 서비스를 제공하도록 개발자 포털을 구성하려면 주요 작업은 API 소비자가 구독할 서비스 또는 서비스를 선택할 수 있는 페이지를 생성하는 것입니다.
자세한 내용은 다중 서비스 등록 을 참조하십시오.
지정한 API 소비자에게만 표시되는 개발자 포털 페이지 또는 페이지 부분을 표시합니다.
특정 API 소비자 그룹에서만 Developer Portal에 액세스할 수 있는 일부가 있어야 할 수 있습니다. 페이지, 페이지 일부 또는 일반적으로 섹션에 해당하는 메뉴 선택에 대한 액세스를 제한할 수 있습니다.
섹션에 대한 액세스를 제한하는 편리한 방법은 각 섹션을 API 소비자의 논리 그룹에 매핑하는 것입니다. 예를 들어, 파트너인 API 소비자가 있다고 가정합니다. partners라는 그룹을 생성하고 해당 그룹에 특정 섹션에 대한 액세스 권한만 부여할 수 있습니다.
상태 변경에 따라 API 소비자에 대한 제한된 콘텐츠에 대한 액세스를 제공할 수 있습니다. 예를 들어 API 소비자가 새 애플리케이션 계획으로 업그레이드하면 추가 페이지가 자동으로 해당 API 소비자에 표시될 수 있습니다.
액세스를 제한하는 또 다른 방법은 API 소비자가 특정 콘텐츠를 보기 위해 로그인해야 하는 것입니다.
자세한 내용은 제한된 콘텐츠를 참조하십시오.
Webhook를 구현합니다.
Webhook를 사용하면 3scale을 백엔드 워크플로와 긴밀하게 통합할 수 있습니다. 3scale 시스템에서 지정된 이벤트가 발생하면 Webhook 메시지와 함께 백- Cryostat 애플리케이션을 알릴 수 있습니다. 그러면 애플리케이션에서 새 계정에 대한 정보와 같이 해당 데이터를 사용하여 개발자 포털을 채울 수 있습니다.
자세한 내용은 Webhook를 참조하십시오.

1.9. 2.8 이전의 3scale 릴리스에서 사용되는 개발자 포털 업데이트

3scale 2.8에서는 외부 자산이 CDN(Content Delivery Networks)에서 3scale 코드베이스로 이동되었습니다. 결과적으로 3scale 2.8부터 cdn_asset Liquid 태그를 사용하여 네이티브 개발자 포털이 생성됩니다. 2.8 미만의 3scale 릴리스에서 업그레이드하는 경우 새 자산을 cdn_asset 태그로 사용하도록 개발자 포털을 업데이트해야 합니다. 이 태그를 사용하면 더 이상 외부 웹 사이트에서 자산을 다운로드하기 위한 종속성이 없습니다.

사전 요구 사항

3scale 2.8 이상 설치
3scale 2.7 이하로 생성한 개발자 포털

프로세스

3scale 관리 포털에서 Audience > Developer Portal > Content 가 선택되어 있는 리소스 계층 구조 상단에서 </>를 클릭하여 레이아웃만 표시합니다.
레이아웃에서 주 레이아웃 을 클릭합니다.

기본 레이아웃의 코드 편집기에서 17 행 또는 주위에 다음 행을 바꿉니다.

{{ '//netdna.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.css' | stylesheet_link_tag }}

이 줄에서 다음을 수행합니다.

{% cdn_asset /font-awesome/4.3.0/css/font-awesome.css %}

19 행 또는 주위에 다음 행을 바꿉니다.

{{ '//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js' | javascript_include_tag }}

이 줄에서 다음을 수행합니다.

{% cdn_asset /jquery/1.7.1/jquery.min.js %}

아래로 스크롤하여 게시 를 클릭합니다.
리소스 계층 구조 맨 위로 이동하여 를 클릭하여 부분적인 정보를 표시합니다.
Partials 에서 stats/chart 를 클릭합니다.

통계/ 도도에 대한 코드 편집기에서 3 행 또는 주위에 다음 행을 바꿉니다.

{{ '//ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/themes/ui-lightness/jquery-ui.css' | stylesheet_link_tag }}

이 줄에서 다음을 수행합니다.

{% cdn_asset /jquery-ui/1.11.4/jquery-ui.css %}

아래로 스크롤하여 게시 를 클릭합니다.
선택 사항: 기본 레이아웃을 기반으로 파일을 만들거나 통계/차량 부분만을 기반으로 파일을 생성한 경우 해당 파일을 마찬가지로 업데이트해야 합니다.

추가 리소스

3scale Liquid 참조에서 유동성 삭제, 태그 및 필터

2장. 사용자 정의 등록 양식 필드

이 기능에 대한 사용자 정의 등록 필드와 다양한 옵션을 추가하는 방법을 알아봅니다.

기본적으로 3scale은 사용자/계정/애플리케이션 등록에서 일반적으로 사용되는 필드를 제공합니다. 이러한 일반적인 기본값에 고유한 사용자 지정 필드를 추가해야 할 수도 있습니다.

관리 포털에서 Audience > Accounts > Field Definitions 로 이동하여 기본 양식 필드를 확인하고 새 필드를 정의할 수 있습니다.

새 계정/사용자 등록 페이지는 실제로 처음 두 섹션의 암명입니다. 계정 필드가 맨 위에 표시되고 사용자 필드 뒤에 구성할 필요가 없는 암호 필드가 표시됩니다.

3 개의 추가 필드, 2 사용자 등록 섹션 및 계정 섹션에 1을 추가하십시오. create를 클릭하고 다음 새 필드 정의를 추가한 다음 생성합니다. 필수 확인란은 물론 등록 양식에서 필수입니다. 또한 항목을 숨기고 읽기 전용으로 만드는 옵션도 있습니다. 예를 들어, 새 서명에 기본적으로 비어 있는 access_restricted_areas와 같이 강조 표시하고 싶지 않은 숨겨진 필드가 추가될 수 있습니다. 관리자는 나중에 사용자별로 이 값을 true로 업데이트할 수 있습니다. 페이지 논리를 읽고 표시할 내용을 결정할 수 있습니다. 읽기 전용 필드(예: 페이지 로드 시 JavaScript를 사용하여 설정할 수 있는 브라우저 위치)일 수 있습니다.

이제 사용자 등록 양식에 드롭다운을 추가하십시오. 이를 "employment type"이라고 합니다. 선택 필드에 쉼표로 구분된 값을 추가합니다(전체 시간, 파트 시간, 계약). 드롭다운은 이러한 값으로 채워집니다.

이제 미리 정의된 필드를 계정에 추가합니다. 일반적으로 추가하는 필드에는 시스템 기능이 없습니다. 나중에 액세스할 수 있는 데이터를 간단히 보관합니다. ( 제한된 콘텐츠 참조)

필드를 정상적으로 생성합니다. 그런 다음 위의 "name" 드롭다운에서 po_number를 선택합니다. 이 필드를 사용하면 이 개발자 계정으로 전송된 3scale 생성 송장에 PO 번호가 표시됩니다. 시스템 생성 필드는 언제든지 관리자가 덮어쓸 수 있습니다. 필드에 이름 - "PO 번호"를 지정하고 만듭니다.

이제 작업을 살펴보십시오. 무료 텍스트 성을 볼 수 있으며 고용 유형 드롭다운이 사용자 섹션에 추가되었습니다. PO 번호 시스템 필드, 무료 텍스트도 계정 섹션에 추가되었습니다.

마지막으로 이러한 사용자 지정 필드는 3scale ActiveDocs를 사용하여 설정할 수 있습니다(예: 애플리케이션 생성 ).

3장. 등록 흐름 구성

이 섹션에서는 등록 워크플로우를 조정하도록 구성할 설정을 확인할 수 있습니다.

등록 워크플로는 개발자 포털을 통해 제공되는 개발자 환경의 중요한 측면입니다. 이 프로세스는 완전히 자동 및 셀프 서비스가 되는 것부터 다양한 수준의 세분성으로 누가 무엇을 얻을 수 있는지에 대한 완전한 제어가 필요한 기타 극단적까지 다양할 수 있습니다.

3scale 플랫폼을 사용하면 계정(선택 사항), 서비스(선택 사항) 및 애플리케이션 계획을 조합하여 API를 모델링할 수 있습니다. 이러한 각 계획에 대해 운영 승인 게이트가 있는지 여부를 제어할 수 있습니다. 각각에 대해 기본값이 있는지 아니면 개발자가 다음 단계를 수행하여 선택을 해야 하는지도 확인합니다.

최대 자동화 및 셀프 서비스의 경우 모든 승인 단계를 제거하고 가능한 모든 기본 계획을 활성화합니다. 이렇게 하면 등록 후 즉시 API에 대한 액세스를 제공하도록 키를 발행할 수 있습니다.

3.1. 모든 승인 단계 제거

승인을 제거하려면 Audience > Accounts > Usage Rules 로 이동하고 Signup 섹션에서 Developers 옵션이 자체적으로 등록할 수 있는지 확인합니다.

계정 및 서비스 계획이 활성화된 경우 페이지 아래로 스크롤하고 두 경우 모두 변경 계획 변경 옵션이 활성화되어 있는지 확인합니다.

3.2. 가능한 모든 기본 계획 활성화

애플리케이션 계획

필요한 경우 계정 및 서비스 계획이 활성화된 경우 해당 계획에 대한 기본 계획을 선택합니다.

계정 계획 (선택 사항)

서비스 계획 (선택 사항)

3.3. 워크플로우 테스트

원하는 설정을 변경한 후 개발자 포털로 이동하여 새 개발자로 등록하여 결과를 테스트합니다. API에 적합한 워크플로우를 얻기 위해 실험하고 필요한 조정을 수행합니다. 워크플로우에 만족하는 경우 이메일 알림을 확인하여 개발자에게 올바른 정보를 제공하는 것이 좋습니다.

4장. 다중 서비스 등록

이 섹션을 마치면 다중 서비스 등록 페이지를 생성하고 사용자 지정하는 절차를 잘 알고 있습니다.

여러 서비스 기능을 사용하는 경우 고객이 다양한 서비스에 등록할 수 있도록 등록 절차를 사용자 지정할 수 있습니다.

4.1. 전제 조건

레이아웃 및 페이지 생성 프로시저와 리쿼시 형식 태그의 기본 사항에 대해 잘 알고 있어야 합니다. 유동 태그에 대한 자세한 내용은 iquid 참조를 참조하십시오. 계정에서 "여러 서비스" 기능도 활성화해야 합니다(프로 계획 및 up에서 사용 가능).

등록 워크플로 에 대해 자세히 읽어보는 것이 좋습니다. 따라서 전체 설정이 준비되고 어떻게 작동하는지 알 수 있습니다.

4.2. 소개

다중 서비스 등록 페이지의 템플릿 역할을 하는 새 레이아웃을 생성하여 프로세스를 시작합니다. CMS 시스템의 레이아웃 섹션으로 이동하여 새 레이아웃을 만듭니다. 이를 multipleservicesignup 이라고 호출하여 다른 레이아웃과 쉽게 구분할 수 있습니다. 편집기에서 표준 레이아웃(예: 홈 또는 기본 레이아웃)의 일반 구조를 붙여넣습니다. 이제 필요하지 않은 모든 것을 삭제하십시오 - 모든 컨테이너, 사이드바, 추가 상자 등.

레이아웃의 백본을 생성한 후 등록 위해 코드 사용자 지정을 진행합니다.

4.3. 다중 서비스 등록

4.3.1. 서비스에 대한 정보 검색

적절한 등록 링크를 구성하는 데 필요한 서비스에 대한 모든 정보를 검색하려면 서비스 오브젝트를 통해 반복해야 합니다. 서비스는 모델 오브젝트의 일부입니다.

{% for service in provider.services %}
  .
  .
  .
{% endfor %}

4.3.2. 등록 열 구성

서비스 오브젝트에 대한 레이아웃과 루프가 이미 있습니다. 이제 서비스 및 등록 링크에 대한 정보를 표시하는 방법을 결정합니다. 예를 들어 서비스 설명과 하단의 등록 링크를 사용하여 열로 나눕니다. 모든 열은 필요한 모든 정보를 포함하는 service-column 클래스가 있는 div 박스가 됩니다.

{% for service in provider.services %}
  <div class="service-column">
    <p>{{ service.name }}</p>
    <p>{{ service.description }}</p>
    .
    .
    .
  </div>
{% endfor %}

내부 컨테이너는 사용자 지정 설명 필드 역할을 합니다. service.name은 서비스 이름입니다. 이 경우 컨테이너 이름이 됩니다.

4.3.3. 서브스크립션 구성

이제 사용자 정의 서비스 등록의 주요 부분 - 가입 링크를 만들려면 등록 URL과 서비스 ID를 추출합니다. URL 오브젝트에서 등록 URL과 루프에서 반복한 서비스 오브젝트의 서비스 ID를 가져옵니다. 최종 링크 코드는 다음과 같습니다.

<a href="{{ urls.signup }}?{{ service | toparam }}">Signup to {{ service.name }}</a>

또한 사용자가 이미 일부 서비스에 가입했을 수 있음을 고려해야 합니다. 확인할 조건부 블록을 만듭니다.

{% unless service.subscribed? %}
  <a href="{{ urls.signup }}?{{ service | toparam }}">Signup to {{ service.name }}</a>
{% endunless %}

이를 통해 최종 코드를 생성할 수 있습니다.

{% for service in provider.services %}
  <div class="service-column">
      <p>{{ service.name }}</p>
      <p>{{ service.description }}</p>
      {% unless service.subscribed? %}
        <a href="{{ urls.signup }}?{{ service | to_param }}">Signup to {{ service.name }}</a>
      {% endunless %}
  </div>
{% endfor %}

4.3.4. 스타일링

사용 중인 서비스 수에 따라 생성된 태그에 몇 가지 최종 영향을 추가합니다. 이 예제의 경우 두 개이므로 service-column div의 CSS 코드는 다음과 같습니다.

.service-column {
    float: left;
    margin-left: 10%;
    width: 45%;
}
.service-column:first-child {
  margin-left: 0;
}

예에서는 백분율 기반 레이아웃을 사용하여 div의 차원을 포함하는 에서 기본 열의 너비를 동적으로 할당했습니다.

이제 제대로 작동하고 좋은 여러 서비스 하위 페이지가 있어야합니다. 축하합니다!

열을 특정 순서로 표시하려면 서비스 이름 또는 알고 있는 다른 값을 조건하는 조건부 식(if/else/case)을 사용해 보십시오.

5장. 개발자 포털 인증

개발자 포털에 대한 액세스를 구성하려면 다음 단계를 따르십시오.

이 문서에서는 개발자가 등록하거나 로그인할 수 있도록 개발자 포털에서 사용할 수 있는 다양한 유형의 인증을 활성화하고 비활성화하는 방법을 보여줍니다.

현재 3scale은 다음 섹션에서 다루는 개발자 포털에 대한 여러 가지 인증 방법을 지원합니다.

사용자 이름/이메일 및 암호
GitHub를 통한 인증
Auth0을 통한 인증
Red Hat Single Sign-On을 통한 인증

기본적으로 3scale.net에 등록한 경우 개발자 포털에서 하나의 인증 유형만 활성화됩니다.

사용자 이름/이메일 및 암호
GitHub를 통한 인증(3scale GitHub 애플리케이션 사용) - 3scale.net에 등록한 경우에만 기본적으로 활성화됨

참고

이전 3scale 계정(2015년 12월 14일 이전에 생성)은 GitHub 및 Auth0 인증을 활성화하려면 추가 단계를 수행해야 할 수 있습니다.

이 기능이 사용자에게 적용되는 경우 두 양식에서 이 기능을 활성화하려면 로그인 및 등록 템플릿에 다음 코드 조각을 추가해야 합니다.

    {% include 'login/sso' %}

5.1. 사용자 이름/이메일 및 암호 활성화 및 비활성화

기본적으로 개발자 포털에서 사용자 이름/이메일 및 암호 인증이 활성화됩니다. 일반적으로 여기에 변경 사항이 없습니다. 이는 개발자가 계정을 만들고 로그인할 수 있는 표준 방법입니다.

그러나 드문 경우지만 이 인증 유형을 제거해야 하는 경우도 있습니다. 이렇게 하려면 아래 스크린샷과 같이 로그인 > 새 템플릿을 편집합니다.

개발자 포털에 사용자 이름/이메일 및 암호 인증을 다시 추가해야 하는 경우 이전 단계에서 추가한 liquid 주석 태그를 제거하기만 하면 됩니다.

5.2. GitHub를 통한 인증 활성화 및 비활성화

고유한 GitHub 애플리케이션을 활성화하려면 먼저 해당 인증 정보를 생성하고 검색해야 합니다.

GitHub를 통해 인증을 구성할 수 있는 방법은 다음 두 가지가 있습니다.

3scale GitHub 애플리케이션 사용(기본적으로 호스팅된 3scale 계정에 사용)
자체 GitHub 애플리케이션 사용(온-프레미스 설치용)

이 기본 구성을 변경하려면 Audience > Developer Portal > SSO 통합 에서 3scale 관리 포털로 이동하여 다음 화면이 표시됩니다.

GitHub 를 클릭하여 구성 화면에 액세스합니다.

이 화면에서는 다음을 수행할 수 있습니다.

개발자 포털에서 GitHub 인증을 사용할 수 없거나 사용할 수 없도록 하려면 "게시됨" 상자를 선택하거나 선택 취소하기만 하면 됩니다.
3scale 브랜드 GitHub 애플리케이션을 선택하거나 자체 GitHub 애플리케이션을 추가합니다 - 기본적으로 3scale GitHub 애플리케이션이 활성화되어(게시됨)됩니다. 편집을 클릭하고 GitHub("Client" 및 "Client secret")에서 생성된 OAuth 애플리케이션의 세부 정보를 입력하여 고유한 GitHub 애플리케이션을 구성할 수 있습니다. 자체 GitHub 애플리케이션과의 통합이 제대로 작동하려면 "콜백 URL" 옵션을 사용하여 GitHub 애플리케이션의 권한 부여 콜백 URL을 구성해야 합니다(예: https://yourdomain.3scale.net/auth/github/callback).
구성된 인증 흐름이 예상대로 작동하는지 테스트합니다.

5.3. Auth0을 통한 인증 활성화 및 비활성화

5.3.1. 참고

이 기능은 Enterprise 플랜에서만 사용할 수 있습니다.

Auth0을 사용하여 개발자를 인증하려면 먼저 유효한 Auth0 서브스크립션이 필요합니다.

Auth0을 통한 인증은 기본적으로 활성화되어 있지 않습니다. 3scale과 함께 Auth0 계정을 사용하여 개발자 포털에 대한 액세스를 관리하려면 다음 단계에 따라 구성합니다.

3scale 관리 포털로 이동하여 Audience > Developer Portal > SSO Integration 에서 Auth0 을 클릭합니다.

이 구성 화면에서 Auth0 계정의 세부 정보를 추가해야 합니다. 클라이언트 ID, 클라이언트 시크릿 및 사이트를 입력한 후 "Published" 상자를 선택하고 Create Auth0 을 클릭하여 개발자 포털에서 사용할 수 있도록 합니다.

5.4. Red Hat Single Sign-On을 통한 인증 활성화 및 비활성화

참고

이 기능은 엔터프라이즈 계획에서만 사용할 수 있습니다.

RH-SSO(Red Hat Single Sign-On)는 3scale과 함께 사용할 때 사용 가능한 RH-SSO ID 브로커 및 사용자 페더레이션 옵션을 사용하여 개발자를 인증할 수 있는 통합 SSO(SSO) 솔루션입니다.

3scale과 호환되는 Red Hat Single Sign-On 버전에 대한 정보는 지원되는 구성 페이지를 참조하십시오.

5.4.1. 시작하기 전

Red Hat Single Sign-On을 3scale과 통합하려면 먼저 Red Hat Single Sign-On 인스턴스가 작동해야 합니다. 설치 지침은 Red Hat Single Sign-On 설명서를 참조하십시오. RH-SSO 7.2 설치

5.4.2. 개발자 포털을 인증하도록 RH SSO 구성

Red Hat Single Sign-On을 구성하려면 다음 단계를 수행합니다.

Red Hat Single Sign-On 설명서에 설명된 대로 영역을 생성합니다.
클라이언트로 이동하여 Create 를 클릭하여 클라이언트를 추가합니다.
다음 필드 및 값을 고려한 양식을 작성합니다.
- Client ID: 클라이언트에 원하는 이름을 입력합니다.
- enabled: ON 으로 전환합니다.
- 동의 필요: OFF 로 전환합니다.
- 클라이언트 프로토콜: openid-connect 를 선택합니다.
- 액세스 유형: 기밀을 선택합니다.
- 표준 흐름 사용: ON 으로 전환합니다.
- Root URL: 3scale 관리 포털 URL을 입력합니다. 개발자 포털에 로그인하는 데 사용하는 URL 주소여야 합니다(예: https://yourdomain.3scale.net 또는 사용자 정의 URL).
- 유효한 리디렉션 URL: 다음과 같이 /* 로 개발자 포털을 다시 입력합니다. https://yourdomain.3scale.net/*.
  다른 모든 매개 변수는 비워 두거나 OFF 로 전환해야 합니다.
다음 단계를 사용하여 클라이언트 시크릿을 가져옵니다.
- 방금 만든 고객으로 이동합니다.
- 인증 정보 탭을 클릭합니다.
- Client Authenticator 필드에서 Client Id 및 Secret 을 선택합니다.
email_verified mapper를 구성합니다. 3scale에서는 사용자 데이터의 email_verified 클레임을 true 로 설정해야 합니다. "Email Verified" 사용자 속성을 email_verified 클레임에 매핑하려면 다음을 수행합니다.
- 클라이언트의 Mappers 탭으로 이동합니다.
- 내장 추가를 클릭합니다.
- 이메일 확인 옵션을 선택하고 선택한 추가 를 클릭하여 변경 사항을 저장합니다.
  Red Hat Single Sign-On 로컬 데이터베이스에서 사용자를 관리하는 경우 사용자의 이메일 확인 특성이 ON 으로 설정되어 있는지 확인합니다.
  3scale SSO 통합을 위해 이전에 생성된 클라이언트에서 User Federation 을 사용하는 경우 토큰 이름을 email_verified 로 설정하고 claim 값을 true 로 설정하여 하드 코딩된 클레임을 구성할 수 있습니다.
필요한 경우 org_name mapper를 구성합니다.
사용자가 3scale에 등록할 때 사용자는 조직 이름 값으로 등록 양식을 작성하도록 요청됩니다. 개발자 포털의 등록 양식을 작성할 필요가 없으므로 Red Hat Single Sign-On을 통해 사용자를 투명하게 등록하려면 추가 org_name 매퍼를 구성해야 합니다.
- 클라이언트의 Mappers 탭으로 이동합니다.
- 생성을 클릭합니다.
- 다음과 같이 매퍼 매개변수를 작성합니다.
  - name: 원하는 이름을 입력합니다(예: org_name ).
  - 동의 필요: OFF 로 전환합니다.
  - 매퍼 유형: 사용자 속성을 선택합니다.
  - User Attribute: org_name 을 입력합니다.
  - 토큰 클레임 이름: org_name 을 입력합니다.
  - 클레임 JSON 유형: 문자열 을 선택합니다.
  - ID 토큰에 추가: ON 으로 전환합니다.
  - 추가 액세스 토큰: ON 으로 전환합니다.
  - Add to userinfo: switch to ON.
  - multivalued: OFF 로 전환합니다.
- 저장을 클릭합니다.
  Red Hat Single Sign-On의 사용자에게 org_name 속성이 있는 경우 3scale은 계정을 자동으로 생성할 수 있습니다. 그렇지 않은 경우 계정을 생성하기 전에 사용자에게 조직 이름을 표시하라는 메시지가 표시됩니다. 또는 하드 코딩된 클레임 유형의 매퍼를 생성하여 Red Hat Single Sign-On 계정으로 로그인하는 모든 사용자의 하드 코딩된 값으로 설정할 수 있습니다.
통합을 테스트하려면 사용자를 추가해야 합니다. 이 작업을 수행하려면 사용자로 이동하여 사용자 추가 를 클릭하고 필수 필드를 작성합니다. Red Hat Single Sign-On에서 사용자를 생성할 때 이메일 확인 속성(email_verified)을 ON 으로 설정해야 합니다. 그러지 않으면 사용자가 3scale에서 활성화되지 않습니다.

Red Hat Single Sign-On을 ID 브로커로 사용

Red Hat Single Sign-On을 ID 브로커로 사용하거나 외부 데이터베이스를 통합하도록 구성할 수 있습니다. 이러한 구성 방법에 대한 자세한 내용은 ID 브로커 및 사용자 페더레이션 에 대한 Red Hat Single Sign-On 설명서를 참조하십시오.

Red Hat Single Sign-On을 ID 브로커로 사용하고 개발자가 RH-SSO 및 3scale 계정 생성 단계를 모두 건너뛰려면 다음 구성을 권장합니다. 제공된 예제에서는 GitHub를 ID 공급자로 사용하고 있습니다.

Red Hat Single Sign-On에서 ID 공급자 에서 GitHub를 구성한 후 Mappers 탭으로 이동하여 생성 을 클릭합니다.
이름을 지정하여 식별할 수 있도록 합니다.
매퍼 유형에서 특성 가져오기 를 선택합니다.
소셜 프로필 JSON 필드 경로에서 GitHub의 속성 이름인 company를 추가합니다.
사용자 속성 이름에서 org_name을 추가합니다. 이는 Red Hat Single Sign-On에서 특성을 호출하는 방법입니다.
참고
Red Hat Single Sign-On에는 이름과 이메일 및 필수 필드가 필요합니다. 3scale에는 이메일 주소, 사용자 이름, 조직 이름이 필요합니다. 따라서 조직 이름에 대한 매퍼를 구성하고 사용자가 다음 양식을 모두 건너뛸 수 있도록 하려면 다음을 확인합니다.
- IdP 계정에는 이름과 성이 설정되어 있습니다.
- IdP 계정에서는 해당 이메일 주소에 액세스할 수 있습니다. 예: GitHub에서 이메일 주소를 비공개로 설정하면 공유되지 않습니다.

5.4.3. 개발자 포털을 인증하도록 3scale 구성

RH-SSO(Red Hat Single Sign-On)를 사용하여 개발자 포털에 대한 인증을 허용하도록 API 공급자로 3scale을 구성합니다.

참고

RH-SSO를 통한 인증은 기본적으로 활성화되어 있지 않습니다. RH-SSO는 엔터프라이즈 3scale 계정에서만 사용할 수 있으므로 RH-SSO를 통해 계정 관리자에게 인증을 활성화하도록 요청해야 합니다.

사전 요구 사항

RH-SSO를 사용하도록 엔터프라이즈 3scale 계정이 설정됩니다.
개발자 포털을 인증하도록 RH SSO 구성 후 다음 세부 정보를 알고 있습니다.
- client : RH-SSO의 클라이언트 이름
- 클라이언트 시크릿: RH-SSO의 클라이언트 시크릿
- realm: RH-SSO 계정에 대한 이름 및 URL 주소

프로세스

3scale 관리 포털에서 Audience > Developer Portal > SSO 통합을 선택합니다.
Red Hat Single Sign-On 을 클릭합니다.
5.4.2절. “개발자 포털을 인증하도록 RH SSO 구성” 에서 구성한 RH-SSO 클라이언트의 세부 정보(클라이언트, 클라이언트 시크릿 및 영역)를 지정합니다.
변경 사항을 저장하려면 Red Hat Single Sign-On 생성을 클릭합니다.

6장. Red Hat Single Sign On for Developer Portal

RH SSO(Red Hat Single Sign On)를 사용하면 여러 독립 시스템의 액세스 제어를 관리할 수 있습니다. 이 가이드를 따라 시스템에 로그인한 사용자가 다시 로그인하라는 메시지가 표시되지 않고 3scale 기반 개발자 포털에 자동으로 로그인할 수 있도록 허용할 수 있습니다.

이 문서에서는 웹 사이트의 기존 사용자 인증 정보를 사용하여 3scale 기반 개발자 포털에 자동으로 로그인하는 방법을 보여줍니다.

이 기능은 API 공급자가 ID 공급자인 경우와 같이 API 소비자의 ID(사용자 이름 및 암호)를 이미 소유하고 있는 API 공급자를 위한 것입니다.

6.1. 3scale 플랫폼에서 사용자 생성

먼저 API 소비자는 개발자 포털에 계정이 있어야 합니다. 계정 관리 API를 사용하여 사용자를 3scale로 가져오거나 수동으로 생성할 수 있습니다. 관리 포털에서 사용 가능한 3scale ActiveDocs에서 계정 관리 API를 오른쪽 상단의 문서(정수 표시 아이콘) → 3scale API 문서 섹션에서 찾습니다.

6.2. 로그인 링크 요청

사용자가 존재하면 API 요청 호출을 사용하여 기본 제공 SSO 토큰으로 URL을 생성할 수 있습니다.

curl -X POST -d "provider_key=YOUR_PROVIDER_KEY&username=USERNAME&expires_in=60" https://YOUR_ADMIN_PORTAL.3scale.net/admin/api/sso_tokens.xml

이 호출에는 토큰을 요청하는 사용자와 expires_in을 지정하는 2개의 매개변수가 있습니다. 이 매개변수는 토큰이 유효한 시간(기본값: 10분)입니다.

로그인에 성공한 후 사용자를 리디렉션할 위치로 추가 매개변수 redirect_url을 전달할 수도 있습니다. 이 매개변수는 백분율로 인코딩 되어야 합니다. XML 응답에는 시크릿 토큰이 포함된 URL이 포함됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<sso_url>
https://YOUR_DEVELOPER_PORTAL/session/create?expires_at=1365087501&token=Q0dNWGtjL2h2MnloR11yWmNwazVZY0NhenlabnBoRUNaNUlyWjZaVG8wMnBGdVNhT0VGN1NUb3FRc1pwSnRrclBZSTIwOUFwRkVTc3NuK1JTbjUrMEE9PS0tY1ZrOGFldzFJNkxna1hrQzQyZ0NGQT09--712f2990ac9248ab4b8962be6467fb149b346000
</sso_url>

참고

user_id 또는 username 중 하나를 전달하여 3scale 사용자를 식별할 수 있습니다. 일반적으로 사용자 이름은 시스템 및 3scale 포털에 대해 동일합니다. 이 경우 사용자 이름을 사용하는 것은 추가 정보가 필요하지 않으므로 쉽게 사용할 수 있어야 합니다. 그러나 URL에 일부 페어링 및 머신 프로세스를 수행해야 하는 경우 user_id를 사용하는 것이 더 나을 수 있습니다.

6.3. 자동 로그인을 사용하여 사용자 리디렉션

응답에는 토큰이 있는 RH SSO 로그인 URL이 포함되어 있습니다.

https://YOUR_DEVELOPER_PORTAL/session/create?expires_at=1365087501&token=Q0dNWGtjL2h2MnloR11yWmNwazVZY0NhenlabnBoRUNaNUlyWjZaVG8wMnBGdVNhT0VGN1NUb3FRc1pwSnRrclBZSTIwOUFwRkVTc3NuK1JTbjUrMEE9PS0tY1ZrOGFldzFJNkxna1hrQzQyZ0NGQT09--712f2990ac9248ab4b8962be6467fb149b346000

URL에는 3scale 개발자 포털 SSO가 로그인하는 데 필요한 모든 정보가 포함되어 있습니다. 웹에 직접 포함할 수 있습니다. 그러나 URL은 사용자가 클릭하기 전에 만료될 수 있으므로 새 SSO URL을 동적으로 요청하고 리디렉션할 일반 링크를 페이지에 사용하는 것이 좋습니다. 이렇게 하면 사용자가 개발자 포털에 원활하게 로그인됩니다.

참고

URL 주소는 이스케이프되지 않아야 합니다. 브라우저에서 수동으로 시도하려면 브라우저에서 &amp를 &amp ; 로 교체해야 합니다. 또한 토큰의 모든 % 인코딩은 이스케이프되지 않은 문자로 교체해야 합니다.

7장. 제한된 콘텐츠

여기에서 일부 사용자에게만 표시되는 개발자 포털에 콘텐츠를 보유하는 방법을 확인할 수 있습니다.

특정 메뉴의 페이지 또는 항목의 일부인 특정 개발자 그룹에 대해서만 액세스할 수 있는 개발자 포털의 일부 페이지가 필요할 수 있습니다. 두 가지 목표는 아래 두 가지 기술을 통해 달성될 수 있습니다.

7.1. 제한된 페이지

restricted 섹션을 생성할 때는 각 섹션이 논리 사용자 그룹에 매핑되도록 하는 것이 유용합니다. 이 예제에서는 "파트너"라는 개발자 그룹이 있다고 가정합니다.

액세스를 제한하려는 모든 페이지 또는 페이지 그룹에 대해 개발자 포털에서 새 섹션을 생성합니다. "public" 상태 필드를 선택 해제합니다. 그런 다음 이 섹션에 원하는 페이지를 끌어다 놓습니다.

그룹을 생성하고 생성한 섹션에 대한 액세스 권한을 부여합니다.

이제 이 섹션에 대한 사용자 액세스 권한을 부여해야 할 때마다 이 그룹에 할당해야 합니다. 이렇게 하려면 해당 계정 세부 정보 페이지로 이동한 다음 "그룹 권한"으로 이동합니다. 그런 다음 허용하려는 섹션의 확인란을 선택합니다.

7.2. 제한된 콘텐츠 블록

유동 태그는 개발자 포털을 사용자 지정하는 매우 강력한 방법입니다. 조건에 따라 페이지의 일부를 숨기거나 표시하려면 여기에서 사용하십시오. 3scale을 사용하면 계정, 애플리케이션 및 사용자에 대한 사용자 정의 필드를 생성할 수 있습니다. 이를 활용하여 API 공급자로서 유용한 정보를 저장할 수 있습니다. 여기에서 모든 계정에 연결된 사용자 지정 필드를 생성하고 지정된 계정이 파트너인지 여부를 나타내는 데 사용합니다. Audience > Account > Field Definitions 로 이동하여 이 필드를 생성할 수 있습니다. 계정 섹션에 필드를 추가하고 등록 페이지 또는 포털의 다른 위치에 표시되지 않도록 숨겨진 것으로 표시합니다.

이제 사용자 지정 필드를 배치하면 다음 코드 조각과 같이 조건부로 래핑하여 파트너에게 특수 콘텐츠를 표시할 수 있습니다.

{{ if current_account.extra_fields.partner == 'true' }}
  // content only accessible to partners
{{ endif }}

또는 케이스에 더 적합한 경우 역 논리를 사용하십시오.

{{ unless current_account.extra_fields.partner == 'true' }}
  // content forbidden for partners
{{ endunless }}

여기에서 이러한 숨겨진 콘텐츠를 사용자에게 표시하려면 계정 세부 정보 페이지의 파트너 필드에 'true'를 입력합니다.

7.3. 추가 필드 구성 자동화

상태 변경에 따라 개발자에게 제한된 콘텐츠에 대한 액세스를 제공할 수 있습니다. 예를 들어 애플리케이션 계획을 업그레이드하면 다음과 같습니다.

계정 관리 API와 함께 Webhook 를 사용하여 액세스 프로비저닝 프로세스를 간소화합니다. 계정 관리 API는 3scale ActiveDocs에 있으며 관리 포털에서 사용할 수 있습니다.

창의 오른쪽 상단에 있는 물음표 아이콘(?)을 클릭합니다.
3scale API 문서 를 선택합니다.
Webhook 요청에서 보낸 메시지를 확인하여 제한된 콘텐츠에 액세스할 개발자의 새 계획을 가져옵니다.
개발자의 새 계획에 따라 파트너 필드를 업데이트하기 위해 API를 호출하여 개인 콘텐츠에 대한 액세스 권한을 부여합니다.

7.4. 사용자 로그인 필요

위에서 설명한 컨텐츠에 대한 액세스를 제한하는 두 가지 방법 외에도 유용한 또 다른 기술(로그인된 사용자 필요)이 있습니다.

리쿼드 태그를 사용하는 것은 매우 쉽습니다. 해야 할 일은 다음 조건 내에서 로그인한 사용자에게만 사용할 수 있는 콘텐츠를 래핑하는 것입니다.

{{ if current_user }}
  // only visible if the user is logged in
{{ endif }}

8장. 이메일 템플릿

이 섹션을 완료하면 사용자 지정 이메일 템플릿을 편집하고 저장합니다.

개발자와 모든 표준 이메일 통신의 내용을 완전히 사용자 지정할 수 있으므로 개발자 포털에 대해 설정한 워크플로우와 밀접하게 일치시킬 수 있습니다.

8.1. 이메일 템플릿 사용자 정의

8.1.1. 이메일 구성 전에 워크플로 정의

이메일 템플릿 옵션이 많이 있으며, 이 중 일부만 워크플로우와 관련이 있습니다. 이메일 템플릿을 편집하기 전에 워크플로우에 만족하는지 확인하여 시간을 절약하십시오. 이렇게 하면 실제로 사용할 템플릿만 편집할 수 있습니다.

8.1.2. 워크플로우를 테스트하고 활성 이메일 템플릿 확인

최종 워크플로우 예행 실행을 수행하여 가능한 모든 분기(예: 승인 및 거부)를 테스트합니다. 그런 다음 테스트 개발자 계정에서 다음 단계에서 편집할 내용을 결정하기 위해 수신하는 각 이메일 알림을 식별합니다.

8.1.3. 사용자 정의 템플릿 편집 및 저장

처음으로 템플릿을 편집하면 사용자 지정 템플릿을 "생성"할 수 있습니다. 그런 다음 후속 편집에서 변경 사항을 저장합니다. 경고: 버전 제어가 없습니다. 변경 사항을 되돌리려면 로컬 사본을 작성하는 것이 좋습니다.

이메일의 동적 컨텐츠에 유동 태그를 사용할 수 있습니다. 특히 유동 태그를 변경할 때 백업을 수행하는 것이 좋습니다.

8.1.4. 워크플로우의 모든 템플릿에 대해 반복합니다.

워크플로우에 사용 가능한 모든 분기를 처리할 때까지 동일한 단계를 완료합니다.

8.2. 더 많은 정보

이메일 템플릿을 사용자 정의하기 전에 등록 흐름이 완전히 완료되고 테스트되도록 하는 것이 가장 좋습니다.
이메일 템플릿 내의 유동 태그를 변경하려면 유동 참조 설명서를 읽으십시오.

9장. 이메일 도메인 구성

3scale 시스템에서 사용자를 대신하여 개발자로 전송된 이메일은 Send Cryostat에 의해 배포됩니다. 이 섹션의 구성 지침을 통해 이메일은 3scale이 아닌 도메인 중 하나에서 가져올 수 있습니다.

이 기능은 개인 계획 계정에서 사용할 수 없습니다.

이메일 설정이 구성되면 Red Hat 고객 포털에서 지원 케이스를 열어 프로세스를 완료합니다. SSL 인증서에 대해서는 최대한 빨리 이러한 단계를 완료하는 것이 좋습니다.

9.1. 프로세스

9.1.1. 이메일 도메인 구성

다음 세부 정보를 포함하여 새 지원 케이스 를 생성합니다.
- 관리자 포털 URL
- 아웃 바운드 메일에 대한 이메일 주소
- 국가를 포함한 전체 회사 주소
- 연락처 전화 번호
지원 케이스를 통해 추가 지침을 기다립니다. 이 작업은 영업일 기준 3~5일이 걸릴 수 있습니다.

9.1.2. DNS 변경 확인

명령줄에서 다음 hieradataG 문을 사용하여 DNS 변경 사항이 올바르게 구현되었는지 확인합니다.

  dig cname APIMAIL.YOURDOMAIN.com
  # should return "u11705.wl206.sendgrid.net"

  dig cname s1._domainkey.YOURDOMAIN.com
  # should return "s1.domainkey.u11705.wl206.sendgrid.net"

  dig cname s2._domainkey.YOURDOMAIN.com
  # should return "s2.domainkey.u11705.wl206.sendgrid.net"

  dig a o1.APIMAIL.YOURDOMAIN.com
  # should return "167.89.103.115"

  dig txt APIMAIL.YOURDOMAIN.com
  # should return "v=spf1 include:u11705.wl206.sendgrid.net -all"

9.1.3. 이메일 도메인 변경 완료를 위해 지원팀에 문의

마지막 단계로 다음 정보를 사용하여 이메일 변경 사항을 시작하도록 지원에 알립니다.

아웃 바운드 메일에 대해 원하는 이메일 주소입니다. 이메일 주소는 apicontact@YOURDOMAIN.com 이어야 합니다.
APIMAIL.YOURDOMAIN에 사용한 항목입니다.
전체 회사 주소(국가 포함).
연락처 전화 번호.

10장. 사용자 정의 도메인 구성

개발자 포털의 브랜딩은 https://developer.mydomain.com 또는 https://api.mydomain.com 와 같은 위치에서 자체 회사 도메인 이름으로 구성할 수 있습니다. 3scale 고객 중 가장 일반적인 옵션은 developer.mydomain.com 입니다.

3scale SaaS 플랫폼은 사용자 정의 개발자 포털 도메인에 대해 Let's Encrypt 인증 기관에서 발행한 SSL 인증서를 관리합니다.

아래 단계에 따라 개발자 포털의 URL을 회사 도메인 이름 아래에 있는 항목으로 변경합니다.

10.1. 사전 요구 사항

유료 3scale 플랜에 가입해야 합니다.
유효한 3scale 인타이틀먼트가 있는 Red Hat 계정이 있어야 합니다.

Red Hat 계정에 대한 지원이 필요한 경우 Red Hat 고객 서비스에문의하십시오.

10.2. 프로세스

10.2.1. DNS 설정에 CNAME 항목 추가

DNS 내에서 도메인 이름을 가리키는 CNAME 레코드를 autossl.3scale.net. 예를 들어 autossl.3scale.net 을 가리키는 도메인 developer.mydomain.com 은 다음과 같을 수 있습니다.

developer.mydomain.com.  CNAME  autossl.3scale.net.

일반적으로 개발자 포털에 대한 공용 액세스를 허용하기 전에 사용자 지정 도메인을 변경해야 합니다. 이미 공용 사용자가 있는 경우 mydomain.3scale.net에서 사용자 지정 도메인으로 리디렉션을 정의할 수 없으므로 사용자에게 도메인 변경 사항에 대해 알려야 합니다.

CNAME을 사전에 구현하는 것이 가장 좋습니다. 드문 경우지만 해당 도메인에서 기존 사이트를 공개적으로 사용하는 경우와 같이 불가능합니다. Red Hat 지원팀에 문의하여 전환 방식을 동기화하는 가장 좋은 방법을 결정하십시오.

DNS와의 변경 사항이 전파되는 데 다소 시간이 걸릴 수 있습니다. CNAME 레코드가 올바르게 구성되었는지 확인합니다. 다음 명령을 사용하여 CNAME 구성을 검증할 수 있습니다.

dig cname developer.mydomain.com

또는

nslookup developer.mydomain.com

10.2.2. DNS 설정에 CAA 레코드 추가(선택 사항)

CAA(인증 기관 인증) 를 사용하는 경우 root 도메인에 letsencrypt.org 주소에 대한 CAA 레코드를 추가하여 Let's Encrypt 인증 기관이 도메인에 대한 인증서를 발행하도록 허용해야 합니다. 예를 들어 letsencrypt.org 를 가리키는 mydomain.com 도메인은 다음과 같을 수 있습니다.

mydomain.com.  CAA 0 issue "letsencrypt.org"

DNS 공급자에 따라 루트 도메인의 CAA 레코드의 인증 기관 목록에 0 issue "letsencrypt.org" 플래그, 태그 및 값을 추가해야 할 수 있습니다. CAA 레코드를 구성하는 방법에 대한 지침은 DNS 공급자를 참조하십시오.

10.2.3. Red Hat 지원 문의

CNAME 항목을 추가하고 선택적으로 DNS 설정에 CAA 레코드를 추가한 후에는 다음을 지정하여 Red Hat 지원 케이스 를 열어 개발자 포털 도메인 변경을 요청해야 합니다.

"Red Hat 3scale API Management Platform" 제품을 선택합니다.
케이스 설명에 다음을 포함합니다.
- 3scale 계정의 관리 포털 도메인(예: mydomain-admin.3scale.net)
- 사용하려는 개발자 포털의 사용자 정의 도메인(예: developer.mydomain.com)

티켓을 제출하면 Red Hat 지원은 DNS 설정을 확인하고 변경이 적용되면 확인을 제공하거나 적절하게 대응합니다.

10.2.4. 개발자 포털 검토

도메인 변경에 대한 Red Hat 지원 확인 메시지가 표시되면 개발자 포털을 검토하고 테스트합니다. 사용자 정의 도메인에 대한 비관계형 링크가 업데이트되었는지 확인합니다.

11장. 유동성: 개발자 포털

이 섹션에서는 iquid 포맷 태그 및 태그의 다른 요소, 간의 연결 및 개발자 포털에서 사용하는 방법에 대한 간단한 예제를 포함하여 3scale 시스템에서 작동하는 방법에 대한 정보를 제공합니다.

리쿼드에 대한 기본 사항을 알아보려면 리쿼드 참조를 참조하십시오.

11.1. 개발자 포털에서 리쿼드 사용

이 섹션에서는 레이아웃 및 페이지에서 유동 태그 처리를 활성화하는 방법을 설명합니다.

11.1.1. 리쿼드 활성화

모든 부분 및 이메일 템플릿에 대해 유동 태그 처리가 기본적으로 활성화됩니다. 레이아웃에서 활성화는 system_name 입력 필드 아래에 있는 확인란을 선택하여 수행됩니다. 그러나 페이지에서 이를 활성화하려면 페이지의 고급 옵션 섹션으로 이동해야 합니다.

고급 옵션 섹션을 확장하고 iquid enabled 확인란을 표시합니다. 이제부터 모든 유동 태그를 내부 엔진에 의해 처리되고 개발자 포털 내장 편집기도 유동성을 위한 코드 강조 표시도 추가됩니다.

11.1.2. 페이지, 부분 및 레이아웃에서 서로 다른 사용

유동성을 사용하는 것은 일반적으로 페이지, 부분 및 레이아웃 간에 약간 다릅니다. 페이지 내에서 유동 요소는 단일 사용 요소이며 부분 및 레이아웃이 있는 유동 항목은 개발자 포털의 재사용 가능한 요소입니다. 즉, 페이지마다 작은 변경 사항이 있는 여러 레이아웃 또는 부분적을 적용하는 대신 일부 논리 유동 태그를 추가하고 사용자가 있는 페이지에 따라 레이아웃을 변경할 수 있습니다.

<!-- if we are inside '/documentation' URL -->
<li class="{% if request.request_uri contains "/documentation" %}active{% endif %}"><!-- add the active class to the menu item -->
  <a href="/documentation">Documentation</a>
</li>

11.1.3. CSS/JS와 함께 사용

유동 태그는 HTML에서만 작동하는 것이 아니라 CSS 및/또는 JavaScript 코드와 쉽게 결합하여 더 많은 제어를 할 수 있습니다. 스타일 시트 또는 JS에서 유동을 활성화하려면 페이지로 만들고 일반 페이지에서 활성화한 것과 동일한 단계를 수행합니다. 이렇게 하면 CSS에서 몇 가지 조건부 태그를 추가하거나 JavaScript에서 서버 측 데이터를 사용할 수 있습니다. 페이지의 콘텐츠 유형을 CSS 또는 JS로 설정해야 합니다.

11.2. 이메일 템플릿에서 유동 사용

이 섹션에서는 유동 태그를 사용하여 이메일 템플릿을 사용자 지정하는 방법을 설명합니다.

11.2.1. 개발자 포털의 차이점

앞서 언급했듯이, 유동 태그를 사용하여 사용자에게 전송된 이메일 템플릿을 사용자 지정할 수도 있습니다. 이전에 언급된 유동 쓰기에 대한 모든 일반 규칙은 이메일 템플릿에도 적용되며 몇 가지 예외는 다음과 같습니다.

모든 템플릿에서 사용할 수 있는 일반적으로 공유 변수 목록은 없습니다. 대신 이전에 언급된 {% debug:help %} 태그를 사용하여 일부 테스트를 수행해야 합니다.
이메일은 본질적으로 웹 페이지와 다르기 때문에 일부 태그를 제한하거나 액세스하지 않습니다. 예를 들어, 이메일에 URL이 없으므로 {{ request.request_uri }} 는 의미가 없습니다.

11.3. 문제 해결

이 문제 해결 섹션에서는 발생할 수 있는 일반적인 오류를 디버그하고 수정하는 데 도움이 됩니다.

11.3.1. 디버깅

어떤 것이 의도한 대로 작동하지 않지만 올바르게 저장되는 경우 다음을 확인하십시오.

모든 태그가 올바르게 닫힙니다.
현재 페이지에서 사용 가능한 변수를 참조하고 있습니다.
배열에 액세스하려고 시도하지 않음 - 예를 들어 current_account.applications는 애플리케이션 배열입니다.
논리가 맞습니다.

11.3.2. 일반적인 오류 및 해결 방법

유동 오류로 인해 문서를 저장할 수 없는 경우 일반적으로 일부 태그 또는 드롭이 올바르게 닫히지 않았기 때문입니다. 모든 {% %} 및 {{ }} 태그가 올바르게 닫히고 논리 표현식(예: 경우 )이 end if 인enfor 를 사용하여 올바르게 종료되었는지 확인합니다. 일반적으로 이 경우 설명이 포함된 오류 메시지와 함께 편집기 위의 페이지 상단에 오류가 표시됩니다.
모든 것이 올바르게 저장되고 효과가 표시되지 않으면 빈 요소를 참조하지 않고 콘텐츠를 표시하는 논리 태그를 사용하지 않는지 확인하십시오. {% %} 는 더 복잡한 태그 세트 및 드롭 다운의 별칭인 태그에서 사용하는 것 외에도 콘텐츠를 렌더링하지 않습니다.
# 기호만 표시되면 배열인 요소를 표시하려고 했습니다. 유동 계층 구조의 섹션을 확인합니다.

11.3.3. 지원 문의

문제가 여전히 있는 경우 Red Hat 고객 포털 을 통해 새 케이스를 열 수 있습니다.

12장. 유동성: 이메일 템플릿

3scale은 조직의 고유한 메시징 및 용어를 사용하여 이메일 템플릿을 사용자 지정하는 기능을 제공합니다. 또한 각 고객에 대한 개인화된 정보를 표시하기 위해 유동 드롭을 활용할 수도 있습니다.

개발자 포털에서 유동 항목이 사용되는 방법과 유사하게 모든 이메일 템플릿에는 자체 컨텍스트가 있습니다. 즉, 하나의 이메일 템플릿에서 사용할 수 있는 유동 정보가 다른 이메일 템플릿에서 반드시 사용 가능하지 않을 수 있습니다.

이 참조에서는 이메일 템플릿을 주제별로 그룹화한 이메일 템플릿과 지원하는 유동 감소 세트를 통해 어디에서 사용할 수 있는지에 대해 간단히 설명합니다.

12.1. 계정 관리

이러한 이메일 템플릿은 계정 관리 범주에 속합니다.

구매자 계정 확인
승인 된 구매자 계정
구매자 계정 거부

이러한 템플릿의 경우 다음과 같은 유동 드롭을 사용할 수 있습니다.

사용자 Cryostat 사용자
도메인 Cryostat 문자열
계정 Cryostat 계정
공급자 Cryostat
support_email Cryostat 문자열

또한 다음 템플릿도 있습니다.

구매자를 위한 암호 복구
다음과 같은 유동 감소에 액세스할 수 있습니다.
사용자 Cryostat 사용자
공급자 Cryostat
URL Cryostat URL

계정에 추가 사용자를 초대하는 이메일:

초대
액세스할 수 있습니다.
계정 Cryostat 계정
공급자 Cryostat
URL Cryostat URL

12.2. 신용 카드 알림

공급자에 대한 신용 카드 만료 알림
구매자에 대한 신용 카드 만료 알림

다음과 같은 균열을 사용할 수 있습니다:

user_account Cryostat 계정
계정 Cryostat 계정
provider_account Cryostat 공급자
공급자 Cryostat

12.3. 경고 제한

공급자에 대한 경고 알림(>= 100%)
구매자에 대한 경고 알림 (>= 100%)
공급자에 대한 경고 알림(< 100%)
구매자에 대한 경고 알림 (< 100%)

다음에 액세스할 수 있습니다.

애플리케이션 Cryostat 애플리케이션
계정 Cryostat 계정
공급자 Cryostat
서비스 Cryostat 서비스
경고 Cryostat 경고

12.4. 애플리케이션

다음 이메일 템플릿은 모두 애플리케이션 및 애플리케이션 계획 알림을 처리합니다.

공급자용으로 생성된 애플리케이션

액세스할 수 있습니다.

URL Cryostat URL

애플리케이션 계획 변경 요청 알림 이메일 템플릿:

구매자에 대한 계획 변경 요청
공급자에 대한 계획 변경 요청

액세스할 수 있습니다.

애플리케이션 Cryostat 애플리케이션
공급자 Cryostat
계정 Cryostat 계정
사용자 Cryostat 사용자
계획 계획
credit_card_url ⇒ credit_card_url

다음 이메일 템플릿에는 다음과 같은 여러 사용 가능한 드롭 항목이 포함되어 있습니다.

구매자에 대한 애플리케이션 계획 변경
공급자에 대해 애플리케이션 계획이 변경되었습니다.
구매자를 위한 애플리케이션 평가판 만료

액세스할 수 있습니다.

공급자 Cryostat
계정 Cryostat 계정
사용자 Cryostat 사용자
계획 계획

위의 모든 유동 정보가 삭제될 뿐만 아니라 다음 애플리케이션 계획 메시지…

구매자에 대해 일시 중단된 애플리케이션
구매자를 위해 승인됨
구매자에 대한 요청이 거부됨
공급자의 애플리케이션 계약이 취소됨

추가 유동 삭제가 나열됨

애플리케이션 Cryostat 애플리케이션
서비스 Cryostat 서비스

애플리케이션 키에 대한 다음 이메일 템플릿에 대해 더 많은 유동 정보가 누적됩니다.

구매자를 위해 생성된 애플리케이션 키
구매자를 위해 삭제된 애플리케이션 키
키 Cryostat 키

12.5. Invoicing

다음 이메일 템플릿…

공급자를 청구하기 전에 송장 검토

액세스할 수 있습니다.

공급자 Cryostat
URL Cryostat 문자열>

또한 다음 templates…

재시도하지 않고 공급자에 대한 송장 청구 실패
구매자에 대한 예정된 비용
재시도 횟수가 있는 공급자에 대한 송장 청구 실패
재시도하지 않고 구매자에 대한 송장 청구 실패
구매자에 대한 송장이 성공적으로 청구되었습니다.
재시도 시 구매자에 대한 송장 청구 실패

다음의 스테이크를 공유합니다:

계정 Cryostat 계정
공급자 Cryostat
비용 Cryostat
invoice_url Cryostat invoice_url
payment_url Cryostat payment_url

12.6. 서비스

다음 이메일 템플릿:

공급자의 서비스 계약이 취소됨
구매자를 위한 서비스 평가판 만료
공급자에 대한 서비스 계획 변경
구매자를 위해 서비스 계약이 일시 중지됨

다음에 액세스할 수 있습니다.

공급자 Cryostat
계정 Cryostat 계정
사용자 Cryostat 사용자
계획 계획

위의 유동성이 떨어지면 다음 서비스 템플릿…

공급자용으로 생성된 서비스
구매자를 위한 서비스 허용
구매자에 대한 서비스가 거부되었습니다.

추가 유동 제거가 나열되어 있어야 합니다.

서비스 Cryostat 서비스
service_contract ⇒ Contract
서브스크립션 계약

12.7. 등록

다음 이메일 템플릿…

공급자에 대한 등록 알림
구매자에 대한 등록 알림

다음에 액세스할 수 있습니다.

사용자 Cryostat 사용자
공급자 Cryostat
URL Cryostat activate_url

13장. 개발자 포털 레이아웃 사용자 정의

전체 개발자 포털의 모양과 느낌은 고유한 브랜딩과 일치하도록 사용자 지정할 수 있습니다. 표준 CSS 스타일 시트를 사용하여 사용자 지정에 쉬운 시작점을 제공할 수 있습니다. 레이아웃 템플릿을 만들려면 Main 레이아웃 의 코드를 시작점으로 사용합니다.

이 튜토리얼에서는 개발자 포털에 자체 CSS 사용자 정의를 추가하고 이를 다시 로드하여 새로운 스타일 변경 사항을 라이브로 설정합니다.

13.1. 새 CSS 파일 만들기

기본 스타일 시트가 있습니다. default.css. 매우 크고 복잡하므로 확장하지 않고 사용자 정의 중 하나에 대해 고유한 스타일시트를 생성하여 기본값을 덮어쓰는 것이 좋습니다. 페이지를 생성하는 것과 동일한 방식으로 새 스타일 시트를 만듭니다(고급 페이지 설정에서 적절한 MIME 콘텐츠 유형을 선택해야 함).

선택한 레이아웃이 비어 있어야 합니다. 그렇지 않으면 페이지 레이아웃 HTML에서 CSS 규칙을 모호하게 됩니다.

13.2. 페이지 레이아웃에 스타일 시트를 연결

bootstrap.css에 대한 링크 뒤에 각 레이아웃 템플릿(또는 공통 HEAD 섹션이 있는 경우 부분)에서 사용자 지정 CSS에 대한 링크를 추가합니다. 예를 들면 다음과 같습니다.

<link rel="stylesheet" href="/stylesheets/custom.css">

이제 자신의 고유 한 브랜딩의 풍미를 누릴 수 있습니다!

13.3. 페이지 레이아웃 템플릿 정의

일반적인 개념은 포털에서 다양한 페이지 스타일마다 별도의 레이아웃을 정의하는 것입니다. 시작할 때 Main 레이아웃이라는 표준 레이아웃이 있습니다. 모든 시스템 생성 페이지에서 이 레이아웃을 사용하므로 개발자 포털을 사용하는 전문가가 될 때까지 이 레이아웃을 변경하지 마십시오.

일반적으로 포털의 홈 페이지에 고유한 스타일이 필요합니다. 기본 레이아웃 템플릿은 사용자 정의의 시작점입니다. 페이지 레이아웃 템플릿을 생성하려면 다음을 수행합니다.

주 레이아웃 을 열고 코드를 클립보드에 복사합니다.
새 레이아웃을 만들고 제목, 시스템 이름을 지정한 다음 리쿼드 활성화를 선택합니다.
주 레이아웃 코드를 새 레이아웃에 붙여넣습니다.Paste the Main layout code into your new layout.
새 레이아웃에서 이 행을 삭제하여 사이드바 메뉴를 제거합니다.
```
{% include 'submenu'%}
```
레이아웃 템플릿을 생성하도록 코드를 사용자 지정합니다.

14장. 기본 제공 페이지 변경

이 섹션을 완료하면 시스템 생성 페이지에서 모든 요소의 가시성을 수정하고 구성할 수 있습니다.

시스템에서 생성한 일부 요소는 Signup, Dashboard, Account 페이지 등 개발자 포털에서 수정할 수 없습니다. 이 가이드에서는 CSS 및 JavaScript로 이러한 페이지의 콘텐츠를 사용자 지정하는 방법을 보여줍니다.

시스템 생성 페이지는 백엔드 규칙에 따라 액세스 및 가시성을 따르므로 해당 URL은 특정하고 하드 코딩된 값이어야 합니다. 고객 포털 의 기술 자료 문서는 시스템에서 생성된 페이지 및 해당 URL 목록을 제공합니다.

경고

3scale 시스템 생성 페이지는 변경될 수 있습니다(잘못된 페이지). 이러한 변경 사항은 이 가이드에 따라 구현하는 사용자 정의가 손상될 수 있습니다. 이러한 해킹을 사용하지 않는 것을 피할 수 있다면 그렇게하십시오. 계속하기 전에 중단된 변경 사항을 모니터링하고 포털이 올바르게 작동하도록 하는 데 필요한 유지 관리 작업을 수행할 수 있는지 확인하십시오.

14.1. 요소 식별

가장 먼저 해야 할 일은 숨기고 싶은 것을 파악하는 것입니다. 이를 위해 Firebug (또는 Chrome 개발자 도구 또는 Opera Dragonfly와 같은 다른 개발자 도구)를 사용합니다. 원하는 요소를 선택하고 콘솔에서 마우스 오른쪽 버튼으로 클릭하고 CSS 경로 복사를 선택합니다. 이렇게 하면 쉽게 조작할 수 있도록 정확한 CSS 경로를 저장합니다. 요소가 사이드바 탐색 위젯의 일부인 경우 목록의 위치를 지정해야 합니다. 이를 위해 "+" 선택기(예: 3rd li element: ul + li + li + li + li + li) 또는 :nth-child(n) CSS3 의사 클래스를 사용할 수 있습니다.

14.2. 요소 수정 또는 숨기기

이제 요소를 식별하면 표시 설정을 변경할 수 있습니다. 요소 유형에 따라 CSS 조작 또는 Cryostat 스크립트의 두 가지 방법 중에서 선택할 수 있습니다. CSS 조작은 더 가볍고 신뢰할 수 있지만 여러 페이지에 존재하는 일부 종류의 요소에서는 제대로 작동하지 않습니다 (예: 관리 포털 대시보드 사이드바의 3 번째 요소도 계정 섹션에 있지만 다른 값이 있습니다). 일부 요령 구현에서는 이전 브라우저에서 지원하지 않는 CSS3 사용을 필요로 합니다. 다음 두 단계에서는 이 두 가지 접근 방식을 모두 볼 수 있습니다.

14.3. 옵션 A: CSS

예를 들어 대시보드 페이지에서 최신 요소를 숨기십시오. 첫 번째 단계에 따라 CSS 경로를 다음과 같이 확인했습니다.

#three-scale .dashboard_bubble

동일한 경로가 있는 두 번째 상자이므로 "+" 선택기를 사용합니다. 이제 경로는 다음과 같습니다.

.main_layout #three-scale .dashboard_bubble + .dashboard_bubble
/* or */
.main_layout #three-scale .dashboard_bubble:nth-child(1)

display 속성을 none으로 변경하면 해당 상자가 표시되지 않습니다.

.main_layout #three-scale .dashboard_bubble:nth-child(1) {
  display: none;
}

14.4. 옵션 B: Cryostat

사이드바 메뉴 요소와 같이 숨겨야 할 악의적인 요소가 있는 경우, 몇 가지 Cryostat를 사용하는 것이 좋습니다. 이러한 요소의 CSS 경로는 대시보드 및 계정 섹션에서 동일하며 두 섹션 모두에서 요소를 숨기고 싶지 않습니다. 따라서 CSS 경로와 콘텐츠에 따라 요소를 선택합니다. 이 예에서는 대시보드의 사이드바에서 messages 섹션을 숨기려고 한다고 가정합니다. CSS 경로는 다음과 같습니다.

#three-scale #submenu li a

콘텐츠를 일치시키려면 .text() 함수를 사용합니다. 또한 문서의 헤드 내부에 코드를 포함시키고 모든 콘텐츠가 생성된 후 실행되도록 준비 함수에 포함됩니다.

생성된 코드 조각은 다음과 같습니다.

$(function() {
  $('#three-scale #submenu li a').each(function() {
    if ($(this).text() == "Messages")
      $(this).parent().css('display', 'none');
  });
});

이것이 유일한 해결책은 아닙니다. 이것은 단지 한 가지 가능한 방법을 보여줍니다. 동일한 예는 특성 값을 기반으로 CSS3 선택기가 있는 순수 CSS를 사용하여 수행할 수 있습니다. 전체 CSS3 선택기 사양을 보려면 여기를 참조하십시오.

15장. 이용 약관 설정

개발자가 API에 등록할 수 있도록 허용하면 액세스 권한을 부여하기 전에 정책 중 일부를 명확히 하기 위해 사용 약관에 동의하게 됩니다.

개발자가 준수할 수 있도록 다양한 버전의 사용 약관이 있을 수 있습니다. 등록 프로세스 전체에서 다른 지점에서 쉽게 설정할 수 있습니다. 예를 들면 다음과 같습니다.

이용 약관 등록
애플리케이션 약관
서비스/서브스크립션 약관 (여러 서비스가 있는 경우에만 사용 가능)

또한 API 사용을 위해 비용을 청구하는 경우 신용 카드 정책을 명시적으로 만들 수 있습니다. 3scale은 다음과 같은 종류의 신용 카드 정책 URL을 쉽게 설정할 수 있는 방법을 제공합니다.

법적 약관
개인 정보
취소

15.1. 이용 약관

워크플로우의 이 부분은 아래 단계에 따라 관리 포털에서 쉽게 설정할 수 있습니다.

Audience > Developer Portal > Signup 으로 이동합니다. 여기서 등록 법률 조건을 채울 빈 페이지가 표시됩니다. HTML, JavaScript 및 CSS의 모든 조합을 사용할 수 있습니다. 또한 Insert toggling code를 클릭하여 제공하는 일부 코드도 있습니다. 이 상자에 작성한 콘텐츠는 개발자 포털의 가입 페이지에 있는 Sign Up 버튼 바로 위에 표시됩니다.

사용 약관을 작성하고 나면 업데이트를 클릭하여 저장합니다.

코드를 사용한 경우, "다음 법률적 약관에 동의한 후 지정한 사용 약관을 표시하고 숨기는 링크"가 표시됩니다.

이는 기본적으로 서명 페이지에 배치되지만 개발자 포털의 어느 곳에든 포함될 수 있는 부분(signup_licence)입니다. 서명 페이지에서 이를 제거하려면 페이지에서 {% include 'signup_licence' %} 행을 제거하면 됩니다. 마찬가지로 다른 곳에 포함하려는 경우 개발자 포털의 아무 곳에나 배치할 수 있는 스니펫을 통해 동일한 부분적 요소를 사용할 수 있습니다.

사용자가 새 애플리케이션(new_application_licence 부분)을 생성할 때 및/또는 새 서비스(service_subscription_licence 부분)를 생성할 때 다른 사용 약관 세트를 수락하도록 할 수도 있습니다. 이를 설정하려면 위에 설명된 것과 동일한 절차를 수행할 수 있습니다.

15.2. 신용 카드 정책

다른 정책이 있는 다른 URL을 정의할 수도 있습니다. Audience > billinging > credit Card Policies 로 이동하여 정책 페이지가 있는 경로를 설정합니다.

이러한 링크가 작동하려면 개발자 포털에서 새 페이지를 생성해야 합니다.

완료되면 URL의 유동 드롭을 사용하여 참조할 수 있습니다. 예를 들면 다음과 같습니다.

<a href="{{ urls.credit_card_terms }}">Legal Terms</a>
<a href="{{ urls.credit_card_privacy }}">Privacy</a>
<a href="{{ urls.credit_card_refunds }}">Refunds</a>

그리고 이 모든 것이 다!

법적 공지

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Language and Page Formatting Options

개발자 포털 생성

좋은 개발자 포털은 API를 계속 채택해야 합니다. 시간 내에 을 만듭니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

1장. 3scale 관리 API용 개발자 포털 생성 개요

1.1. 개발자 포털을 생성하기 위한 3scale 편집 환경 구성

1.2. 3scale 네이티브 개발자 포털 수정

1.3. 네이티브 개발자 포털을 변경하기 위한 추가 3scale 기능에 대한 설명

1.4. 3scale 레이아웃 및 부분 중 개발자 포털을 재사용하는 방법

1.5. 3scale 관리 API의 개발자 포털에 이미지 및 기타 자산 추가

1.6. 3scale 관리 API에 대한 기본 개발자 포털 사용자 정의 고려 사항

1.7. 3scale 관리 API에 대한 개발자 포털에 대한 액세스 허용 요구 사항

1.8. 3scale 관리 API에 대한 개발자 포털을 사용자 정의하는 선택적 단계

1.9. 2.8 이전의 3scale 릴리스에서 사용되는 개발자 포털 업데이트

2장. 사용자 정의 등록 양식 필드

3장. 등록 흐름 구성

3.1. 모든 승인 단계 제거

3.2. 가능한 모든 기본 계획 활성화

3.3. 워크플로우 테스트

4장. 다중 서비스 등록

4.1. 전제 조건

4.2. 소개

4.3. 다중 서비스 등록

4.3.1. 서비스에 대한 정보 검색

4.3.2. 등록 열 구성

4.3.3. 서브스크립션 구성

4.3.4. 스타일링

5장. 개발자 포털 인증

5.1. 사용자 이름/이메일 및 암호 활성화 및 비활성화

5.2. GitHub를 통한 인증 활성화 및 비활성화

5.3. Auth0을 통한 인증 활성화 및 비활성화

5.3.1. 참고

5.4. Red Hat Single Sign-On을 통한 인증 활성화 및 비활성화

5.4.1. 시작하기 전

5.4.2. 개발자 포털을 인증하도록 RH SSO 구성

5.4.3. 개발자 포털을 인증하도록 3scale 구성

6장. Red Hat Single Sign On for Developer Portal

6.1. 3scale 플랫폼에서 사용자 생성

6.2. 로그인 링크 요청

6.3. 자동 로그인을 사용하여 사용자 리디렉션

7장. 제한된 콘텐츠

7.1. 제한된 페이지

7.2. 제한된 콘텐츠 블록

7.3. 추가 필드 구성 자동화

7.4. 사용자 로그인 필요

8장. 이메일 템플릿

8.1. 이메일 템플릿 사용자 정의

8.1.1. 이메일 구성 전에 워크플로 정의

8.1.2. 워크플로우를 테스트하고 활성 이메일 템플릿 확인

8.1.3. 사용자 정의 템플릿 편집 및 저장

8.1.4. 워크플로우의 모든 템플릿에 대해 반복합니다.

8.2. 더 많은 정보

9장. 이메일 도메인 구성

9.1. 프로세스

9.1.1. 이메일 도메인 구성

9.1.2. DNS 변경 확인

9.1.3. 이메일 도메인 변경 완료를 위해 지원팀에 문의

10장. 사용자 정의 도메인 구성

10.1. 사전 요구 사항

10.2. 프로세스

10.2.1. DNS 설정에 CNAME 항목 추가

10.2.2. DNS 설정에 CAA 레코드 추가(선택 사항)

10.2.3. Red Hat 지원 문의

10.2.4. 개발자 포털 검토

11장. 유동성: 개발자 포털

11.1. 개발자 포털에서 리쿼드 사용

11.1.1. 리쿼드 활성화

11.1.2. 페이지, 부분 및 레이아웃에서 서로 다른 사용

11.1.3. CSS/JS와 함께 사용

11.2. 이메일 템플릿에서 유동 사용

11.2.1. 개발자 포털의 차이점

11.3. 문제 해결

11.3.1. 디버깅

11.3.2. 일반적인 오류 및 해결 방법

11.3.3. 지원 문의

12장. 유동성: 이메일 템플릿

12.1. 계정 관리

12.2. 신용 카드 알림

12.3. 경고 제한

12.4. 애플리케이션