kratos
v1.3.1
すべての個々の貢献者に感謝します
* Oryの主要なプロジェクトの1つを生産に使用しています。
簡単な例を始めるには、Get Start Documentationにアクセスしてください。
Ory Developer Documentationにアクセスして、Linux、MacOS、Windows、DockerにOry Kratosをインストールする方法と、ソースからOry Kratosを構築する方法を学びます。
建築設計に関しては、いくつかの指針となる原則に基づいて構築します。
Ory's Architectureは、Kubernetes、CloudFoundry、OpenShift、同様のプロジェクトなどのコンテナオーケストレーションシステムで最適に実行するように設計されています。バイナリは小さく（5〜15MB）、すべての人気のあるプロセッサタイプ（ARM、AMD64、I386）およびシステム依存関係なし（Java、Node、Ruby、Libxml、...）のないオペレーティングシステム（FreeBSD、Linux、MacOS、Windows）で利用できます。
Ory Kratosは、クラウドアーキテクチャのベストプラクティスに従って構築されたAPIファーストIDおよびユーザー管理システムです。ほとんどすべてのソフトウェアアプリケーションが対処する必要があるコアユースケースを実装します：セルフサービスログインと登録、多要因認証（MFA/2FA）、アカウントの回復と検証、プロファイル、およびアカウント管理。
Ory Hydraは、OpenID Certified™OAuth2およびOpenID Connectプロバイダーであり、小さな「ブリッジ」アプリケーションを作成することで既存のIDシステムに簡単に接続できます。ユーザーインターフェイスとユーザーエクスペリエンスフローを絶対に制御できます。
Ory Oathkeeperは、構成可能な認証、承認、およびリクエストされた変異ルールを備えたBeyondCorp/Zero Trust Identity＆Access Proxy（IAP）です。含まれるサブジェクトがリクエストの実行を許可されているかどうかを確認します。結果のコンテンツをカスタムヘッダー（ X-User-ID ）、JSON Webトークンなどにエンコードします！
Ory Ketoは政策決定ポイントです。サブジェクト（ユーザー、アプリケーション、サービス、車、...）がリソースで特定のアクションを実行することを許可されているかどうかを判断するために、AWS Iamポリシーと同様の一連のアクセス制御ポリシーを使用します。
IDインフラストラクチャを実行するには、脅威モデルの注意と知識が必要です。
セキュリティの脆弱性が見つかったと思われる場合は、フォーラム、チャット、またはGitHubに公開しないでください。 Security.txtで責任ある開示のためのすべての情報を見つけることができます。
Oryのサービスは、要約された匿名化されたデータを収集し、オプションでオフにすることができます。詳細については、ここをクリックしてください。
ガイドはこちらから入手できます。
HTTP APIはここに文書化されています。
新しいリリースでは、壊れた変更が導入される可能性があります。これらの変更を特定して組み込むのを支援するために、これらの変更をchangelog.mdに文書化します。アップグレードについては、アップグレードガイドにアクセスしてください。
kratos -hまたはkratos helpを実行します。
すべての貢献を奨励し、貢献ガイドラインを読むことをお勧めします
1.16+を使用する必要があります（テストスイートの場合）：
WindowsでOry Kratosを開発することは可能ですが、すべてのガイドがBashやZSHのようなUnixシェルを想定していることに注意してください。
インストールします
make formatを使用してすべてのコードをフォーマットできます。 CIは、コードが適切にフォーマットされているかどうかを確認します。
実行できるテストには3つのタイプがあります。
短いテストはかなり速く実行されます。すべてのコードを一度にテストできます
go test -short -tags sqlite ./...または、特定のモジュールのみをテストします。
cd client ; go test -tags sqlite -short . 定期的なテストでは、データベースを設定する必要があります。私たちのテストスイートは、Dockerを直接（Ory/Dockertestを使用して）連携することができますが、代わりにMakeFileを使用することをお勧めします。 Dockertestを使用すると、システム上のDocker画像の数が膨張し、非常に遅いことがあります。代わりに、次のことをお勧めします。
テストを行います
make testするたびにmake testデータベースを再作成することに注意してください。これは、非常に具体的なものを修正しようとしていて、常にデータベーステストを必要としている場合に面倒です。その場合、データベースを以下で初期化することをお勧めします。
make test-resetdb
export TEST_DATABASE_MYSQL= ' mysql://root:secret@(127.0.0.1:3444)/mysql?parseTime=true '
export TEST_DATABASE_POSTGRESQL= ' postgres://postgres:[email protected]:3445/kratos?sslmode=disable '
export TEST_DATABASE_COCKROACHDB= ' cockroach://[email protected]:3446/defaultdb?sslmode=disable 'その後、あなたはあなたが望むだけ頻繁にgo testを実行できます：
go test -tags sqlite ./...
# or in a module:
cd client ; go test -tags sqlite . 一部のテストでは、備品を使用しています。ペイロードが変更された場合、次のように更新できます。
make test-update-snapshots
これにより、短いテストのスナップショットのみが更新されます。すべてのスナップショットを更新するには、実行してください。
UPDATE_SNAPSHOTS=true go test -p 4 -tags sqlite ./...サブフォルダーからこのコマンドを実行することもできます。
サイプレスを使用してE2Eテストを実行します。
softwareupdate --install-rosetta --agree-to-license
E2Eテストを開発する最も簡単な方法は、次のとおりです。
./test/e2e/run.sh - dev sqlite
以下を使用して（データベース付き）すべてのテストを実行できます。
Test-E2eを作成します
詳細については、実行してください。
./test/e2e/run.sh
特異なテストのみを実行します
実行したいテストに加えて.only 。
例えば：
it . only ( 'invalid remote recovery email template' , ( ) => {
...
} )テストのサブセットを実行します
これにはtest/e2e/ folderにあるcypress.jsonファイルを編集する必要があります。
testFilesオプションを追加し、 cypress/integrationフォルダー内で実行するテストを指定します。例として、 networkテストのみを追加します。
"testFiles" : [ " profiles/network/* " ],次に、実行スクリプトまたはMakeFileを使用して、再度テストを開始します。
以下を使用して開発Docker画像を作成できます。
Dockerを作成します
make sdkmake docs/apimake docs/swagger
