Files
log/my-blog/content/posts/2025-12-04-atproto.md
2025-12-04 18:48:42 +09:00

129 lines
5.8 KiB
Markdown

---
title: "atprotoでozoneを動かした"
slug: "atproto"
date: "2025-12-04"
tags: ["atproto"]
language: ["ja", "en"]
draft: false
---
最近は、atprotoとai.card(ios)の連携を作っていました。ozoneが必要そうになったので動かしてみます。
## atprotoをゲームアカウントに
ゲームのアカウントシステムを作る際、atprotoが便利だと思っています。独自にシステムを作るのではなく、既にあるものを使って構築します。
しかし問題もあります。atprotoはユーザーがデータを自由に書き換えられます。もちろん、知識があればですが、そう難しいことではありません。
そのため、ゲームのアカウントシステムとして使う場合、ユーザーがデータを改ざんできないようにする必要があります。これは、rustで書いた独自のシステムと連携し、ユーザーに一部のデータしか操作できないuuidを発行することで解決することにしました。
## ゲームアカウントの仕組み
ゲームアカウントの仕組みは非常にシンプルです。
1. [新規登録] handleを入力すると自動でアカウントが作成される
2. パスワードは自動生成され、dbに保存。ユーザーには表示しない
3. uuidを発行し、それを用いてユーザーはsessionを復元できる
この仕組みをiosアプリに実装することで、ゲームデータの改ざんを防止するゲームアカウントとして利用します。
<iframe width="100%" height="415" src="https://www.youtube.com/embed/jEPkcXtjZ0E?rel=0&showinfo=0&controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
## ゲームアカウントの特典
私はゲームデータが改ざんされるとは考えていません。知識を持った大半も、そんな面倒なこと普通しません。ほとんどの人は普通に遊ぶだろうと考えています。
とはいえ、それも楽しみ方の一つとして許容する気持ちもあります。
また、改ざんされたとしてそれで壊れるような仕組みではいけません。ですからそれをされてもいいようゲームを構築しなければいけません。要は前提をどう考えるかです。
私が作っているゲームはai.cardが改ざんできないローカルデータのみを扱い、ai.rseはリモートデータを使うという構造です。したがって、改造もai.rseでしか有効ではありません。
そのため、結果としてより重視されるのはai.cardの方になるだろうと思っています。ai.rseはおまけみたいなものと認識されるのでは。
ai.rseでのデータの扱いは以下のような形になります。
管理者のpdsで作成されたアカウントはゲームデータ改ざんがないものとみなし
1. maxの値を通常アカウントより大きく設定
2. {user}.syu.isのドメイン部分を省略して表示
## ozoneの導入
そうなるとユーザー管理も大変なので、ozoneがあったほうが良いと判断し、ozoneを動かしてみることにします。
[![](/img/atproto_ozone_0001.png)](/img/atproto_ozone_0001.png)
### backend, frontend
ozoneはback, frontの2つがあり、これらを動かす必要があります。
- [https://github.com/bluesky-social/atproto/tree/main/services/ozone](https://github.com/bluesky-social/atproto/tree/main/services/ozone)
- [https://github.com/bluesky-social/ozone](https://github.com/bluesky-social/ozone)
```md
1 ozone /xrpc/* :2585
2 ozone /.well-known/* :2585
3 ozone * :2586
```
このようにすればよいでしょう。
### atproto_pds
注意書きがあり、通常のアカウントは好ましくないようです。
`AtprotoPersonalDataServer`
```diff
diff --git a/lib/identity.ts b/lib/identity.ts
index a8ec3a7..8e4d171 100644
--- a/lib/identity.ts
+++ b/lib/identity.ts
@@ -83,7 +83,7 @@ export function didDocToData(doc: {
const [, id] = s['id'].split('#')
acc[id] = {
type: s['type'],
- serviceEndpoint: s['serviceEndpoint'],
+ endpoint: s['serviceEndpoint'],
}
}
return acc
```
その他のpatchはこちらが参考になります。
- [https://github.com/itaru2622/bluesky-selfhost-env/tree/master/patching](https://github.com/itaru2622/bluesky-selfhost-env/tree/master/patching)
### oauth
これは`atproto`のpatchです。pdsをbuildします。
通常異なるdomain間でoauth認証を行う場合、`fetch-site``cross-site`になります。しかし、今回の構成ではozoneは同一site内で認証が行われるため、`same-site`も許可する必要があります。
```diff
diff --git a/packages/oauth/oauth-provider/src/router/create-authorization-page-middleware.ts b/packages/oauth/oauth-provider/src/router/create-authorization-page-middleware.ts
index f653b0353..45c45fac1 100644
--- a/packages/oauth/oauth-provider/src/router/create-authorization-page-middleware.ts
+++ b/packages/oauth/oauth-provider/src/router/create-authorization-page-middleware.ts
@@ -53,7 +53,7 @@ export function createAuthorizationPageMiddleware<
res.setHeader('Cache-Control', 'no-store')
res.setHeader('Pragma', 'no-cache')
- validateFetchSite(req, ['cross-site', 'none'])
+ validateFetchSite(req, ['cross-site', 'same-site', 'none'])
validateFetchMode(req, ['navigate'])
validateFetchDest(req, ['document'])
validateOrigin(req, issuerOrigin)
```
### user verify
```sh:envs/ozone
OZONE_VERIFIER_URL=https://{PDS}
OZONE_VERIFIER_DID=${ADMIN_DID}
OZONE_VERIFIER_PASSWORD=${APP_PASSWORD}
```