a
考え中 - プシューサービス
考え中
しばらく全サービスを止めます
その理由は以下の通りです
果たして何が正解なのか、実際プシューサービスは様々サービスを開発し提供してきた、でももう限界
../
.env
main
pips
toolbox
p-memo
etc...
という構成を描いてた、そもそも私のサービスは保存先はそのENVに機密鍵をいれ、各プロジェクトフォルダpipsやmainなどをさす、の中の個人情報を保護する形式だった、少なくとも公開されたフォルダからダウンロードされた場合にはそれは使い物にならない物になるようにはできた
でも私は飽きてしまった、クッキーなしで機能するようにサーバ内にくっきーじょうほうを同様の暗号で保持し、URLにはその場所を示すURLはその場所を示してもユーザーの指定した言葉と交換鍵によりクッキーなしデバイスでもログイン認証などを実現、JavaScriptなしで機能、まで達せしした
でもいま。ふと思う、結局私は何を手に入れたかったのか・確かに明確になり構造的になった、限界も知った、、そのライブラリはインクルードなどで複数のプロダクトをまたいだ、故にこんな問題が発生した、そのライブラリがない場合それを用いる一部機能を制限するようにした、でも非公開フォルダはそう簡単ではなかった、故にサービス起動時にはそれが適切で存在する公開外であるかを隠してから機能する仕様にした、でもそれだけで解決しない、非公開フォルダを参照するのは、自身のプロダクトだけでなくそのライブラリも参照していたという点だ、そのため定数に指定したチェックが通った非公開フォルダのパスを渡す仕様になった、でも私は不満だ、プロダクトフォルダを単体で移動できないからだ、移動するにはプロダクトのIndex.phpに内蔵するか、そのアセットに入れるか、一緒に移動するかを迫られた、これはとても苦痛だった
でも同じファイルをいくつも作れられるのは納得がいかなかった、単体で移動することを想定するなら各フォルダに同じライブラリが内包されることは納得がいくのにそれが集合で用いられる環境でもそうなるのはどうしても気持ち悪かった
そうして今思うのはホントわがままだという点だけです、どう考えても解決できる問題ではなかった。、じゃあ普通にNEXTJSなどのライブラリ用いてNPMで持ってくればいいじゃんって言われそうだが(でもこれは口だけではなく移行を試した、現実的ではない)、それは解決ではない、話すと長くなるから避けるけど、少なくとも使わないことには好き嫌いでは測れない構造的理由と実現したい課題があるってことです
この問題を問い考え続けようとする根源
背景には以下の様な理由があると考えている
NONE
解決法の案があればいかに書き込んでください
# PIPSにおける自己完結性と環境依存の扱い
## 1. 基本思想
PIPSでは、一般的なWebアプリケーションで暗黙に信頼されている外部環境を、できるだけ無条件には信用しない。
これは「一般的な構成が悪い」という意味ではない。
PIPSが想定するのは、
- 特殊なレンタルサーバー
- 設定を自由に変更できないサーバー
- Apache以外のWebサーバー
- `.htaccess` を利用できない環境
- サービスだけを別のサーバーへ移動する環境
- 一部の依存ファイルやディレクトリが存在しない環境
など、必ずしも理想的ではない環境である。
そのため、
> 「この環境なら普通はこうなっている」
という前提よりも、
> 「PIPSが必要とする条件が、本当に成立しているか」
を確認してから利用することを重視する。
---
## 2. 非公開領域を `.htaccess` に依存させたくない理由
Webアプリケーションでは、例えば次のような構成が考えられる。
pips/
index.php
private/
session.key
そして `.htaccess` によって `private/` へのWebアクセスを禁止する。
これは一般的な方法の一つである。
しかしPIPSでは、この構造を基本構成にはしたくない。
理由は、`private/` が安全である理由がPIPS自身のファイル構造ではなく、
PIPS
↓
Apache設定
↓
.htaccess
↓
「このディレクトリは公開しない」
という外部設定に依存するからである。
PIPSだけを別のサーバーへ移動した場合、
pips/
index.php
private/
というファイル群をコピーしただけでは、安全性まで移動したことにはならない。
`.htaccess` がコピーされなかったり、そもそも`.htaccess`を使用できなかったりすれば、秘密情報がWebから取得可能になる可能性がある。
つまり、
> ファイルを移動しただけでは、ソフトウェアが成立するための安全条件まで移動できない。
ここに問題がある。
---
## 3. そのため、秘密情報をWeb公開領域の外側へ置く
PIPSでは、可能な限り秘密情報をDocumentRootの外側に置く。
例えば、
/var/www/
private/
pips/
session.key
html/
pips/
index.php
のような構造である。
この場合、PIPSから見れば、
../private/pips/
という場所に秘密情報を置くことになる。
この方法では、
> 「privateという名前のディレクトリだから非公開」
というサーバー設定上の約束ではなく、
> 「そもそもWeb公開領域の外側に存在する」
というファイルシステム上の境界を利用できる。
ただし、これも無条件に信用するわけではない。
---
## 4. PIPS自身が必要条件を検査する
PIPSでは、秘密領域を定数などで明示的に指定する。
例えば概念的には、
PRIVATE_DIR = "../private/pips"
のようにする。
そして起動時などに、その場所について確認する。
### 確認する条件
1. 指定されたパスが存在するか
2. それが期待するディレクトリであるか
3. 実際の解決先がどこなのか
4. Web公開領域の外側に存在するか
5. PIPSが秘密情報を保存してよい場所として利用できるか
これらの条件を満たさなければ、秘密情報を保存する処理を実行しない、あるいは必要な機能を停止する。
重要なのは、
> Apacheに「ちゃんと非公開にしてください」とお願いして終わらない
ことである。
Apacheの設定を前提として利用するのではなく、
Apache / ファイルシステムの環境
↓
PIPSによる検査
↓
条件が成立している
↓
秘密情報を利用
という流れにする。
---
## 5. これは「二重確認」である
この設計では、環境に対して一つの前提だけを置かない。
例えば、
「この場所をprivateとして指定した」
↓
「実際に存在する」
↓
「ディレクトリとして利用できる」
↓
「DocumentRootの外側にある」
↓
「秘密情報を置く条件を満たしている」
という複数の確認を行う。
したがって、
> 設定値が正しいこと
と
> その設定値が実際の環境でも安全条件を満たしていること
を分離して考える。
これは一見すると遠回りである。
しかし、PIPSにとってはこの遠回りそのものが設計上の意味を持つ。
---
## 6. なぜそこまで確認するのか
一般的なWebアプリケーションでは、
Webサーバー
↓
DocumentRoot
↓
Apache設定
↓
PHP
↓
アプリケーション
という環境全体を、ある程度正常に構成されているものとして扱う。
そのため、
> 「このディレクトリは非公開設定になっている」
という時点で話を終えることもできる。
しかしPIPSでは、
> 「なぜそれが安全なのか？」
をもう一段掘り下げる。
例えば、
- その設定が存在しなかったら？
- `.htaccess` が使えなかったら？
- 別のWebサーバーだったら？
- PIPSだけ別サーバーへ移動したら？
- 管理者が設定を変更したら？
- 指定したディレクトリが存在しなかったら？
- 秘密情報を置く場所そのものが公開領域だったら？
という条件まで考える。
つまり、
> 「正常な環境だから安全」
ではなく、
> 「安全に動作するための条件を確認し、その条件が成立した場合だけ動作する」
という考え方を採る。
---
## 7. ライブラリにも同じ問題がある
この問題はPIPS本体だけでは終わらない。
例えばPIPSが、
- account
- session
- encryption
- private storage
などのライブラリを使用するとする。
これらのライブラリも、それぞれ秘密情報を必要とする可能性がある。
例えばsessionライブラリが暗号鍵を必要とするなら、
session/
session.php
だけをPIPS内部へコピーすれば終わりではない。
そのライブラリには、
> 「暗号鍵をどこに保存するのか？」
という別の問題が存在する。
そこで、
PIPS
↓
検証済みのprivate領域
↓
sessionライブラリ
↓
session専用の秘密情報
というように、PIPSが確認した安全な保存領域をライブラリへ渡す設計が考えられる。
つまり、
> ライブラリの移植性と、ライブラリが秘密情報を保存する場所の移植性は別問題ではない。
この二つは一体として設計する必要がある。
---
## 8. 「ライブラリが存在するか」も同じ考え方になる
外部ライブラリについても、
require "../account/account.php";
のように、外部ディレクトリが当然存在すると仮定する構造は避けたい。
重要なのは、単にパスを正しく計算することではない。
例えば、
__DIR__
を使えば、PHPファイル自身の場所を基準としてパスを計算できる。
しかし、
require __DIR__ . "/lib/account/account.php";
としても、そのファイルが存在しなければエラーになる。
つまり、
> `__DIR__` はパスを正しくする仕組みであって、依存関係を存在させる仕組みではない。
そのため、
依存関係を確認する
↓
存在している
↓
読み込む
↓
存在していない
↓
適切に処理する
という仕組みそのものが必要になる。
---
## 9. 開発単位と配布単位を分離する
ここから、ライブラリの扱いについても同じ思想が適用できる。
開発時には、
account
session
encryption
PIPS
を別々に開発してよい。
しかし配布時には、
pips/
index.php
bootstrap.php
dependencies.json
dependencies.lock
lib/
account/
session/
encryption/
のように、PIPSが必要とするものを自身の中へまとめることができる。
つまり、
> 開発上は分離する。
>
> 配布上は自己完結させる。
という考え方である。
これならPIPSだけを別のサーバーへ移動させても、外部の共通ライブラリディレクトリを必要としない。
---
## 10. インターネット上の配布元にも依存しすぎない
ライブラリを必要に応じて取得する場合も、
PIPS
↓
インターネット
↓
配布サーバー
↓
ライブラリ
という依存だけにしてしまうと、配布元が消滅した場合に問題になる。
そこで、
ライブラリ本体
バージョン
ハッシュ
必要なら署名
などを記録し、取得した成果物そのものをPIPS側へ保持する。
そうすれば、
> 「配布サーバーが存在するから動く」
のではなく、
> 「一度取得して検証した成果物が手元に存在するから動く」
という状態にできる。
更新機能と動作に必要な依存関係を分離することが重要になる。
---
## 11. 目指しているのは「普通の環境」ではない
この設計思想では、
> 危険だから、その環境では使わない
という結論を最初から採らない。
むしろ、
> 危険になり得る環境なら、何が危険なのかを特定し、その条件をソフトウェア自身が検査できるようにする。
という方向へ進む。
例えば、
秘密領域がない
↓
作れない
↓
安全に秘密を保存できない
↓
その機能を停止する
という動作も許容する。
「どんな環境でも動かす」ことが目的なのではない。
**「動かしてよい環境かどうかを、可能な範囲でPIPS自身が判断できるようにする」**
ことが目的である。
---
## 12. なぜ「遠回り」に見えるのか
この設計は、一般的な設計と比較すると遠回りに見える。
例えば、
「.htaccessで禁止すればいい」
なら一行で済むかもしれない。
しかしそれでは、
なぜ安全なのか
↓
Apacheの設定を信用しているから
となる。
PIPSが求めているのは、
なぜ安全なのか
↓
指定された場所を検査した
↓
実際のパスを確認した
↓
公開領域との関係を確認した
↓
条件を満たした
↓
だから利用する
という因果関係である。
そのため、他人から見ると「そこまでやる必要があるのか」と思われる処理が、自分にとっては必要になる。
---
## 13. もやもやの正体
この設計へのこだわりは、単なる神経質さや潔癖さではない。
おそらく根本にあるのは、
> **「動いている」だけでは納得できず、「なぜ動いているのか」を自分で追跡できる状態にしたい**
という要求である。
外部環境に、
「たぶん存在する」
「普通なら設定されている」
「このサーバーなら大丈夫」
「このフォルダ名なら非公開だろう」
という暗黙の前提が残っていると、そこが自分から見えない。
そして、その見えない部分が残っている限り、
> 「もしその前提が崩れたら？」
という疑問が残る。
そのため、多少遠回りになっても、
前提
↓
検査
↓
成立条件
↓
実行
まで明示したくなる。
それによって初めて、システム全体の因果関係が自分の中で閉じる。
---
## 14. PIPSの設計思想
以上をまとめると、PIPSの思想は次のように表現できる。
> **PIPSは、正常な環境を当然のものとして信用するのではなく、自身が必要とする環境条件を可能な範囲で検査し、その条件が成立した場合にのみ安全性を成立させることを目指す。**
そのために、
- Webサーバー設定への依存を減らす
- `.htaccess` に安全性を丸投げしない
- 秘密情報は可能な限りWeb公開領域の外へ置く
- 秘密領域を定数として明示する
- その存在と公開範囲をPIPS自身が検査する
- ライブラリの存在も前提にしすぎない
- ライブラリ自身の秘密情報の保存場所まで設計する
- 開発上の分離と配布上の自己完結を分離する
- 外部配布サーバーが消えても、既に導入したものは動作できるようにする
- 更新機能と動作に必要な依存関係を分離する
- 条件が成立しない場合は、無理に動かすのではなく停止・機能制限する
という構造を取る。
これは「何でも自前で作る」という思想ではない。
**外部に依存する場合でも、その依存を明示し、検査可能にし、必要なら代替できる状態にする。**
その結果として、PIPSは「普通の環境でだけ正常に動くソフトウェア」ではなく、
> **環境が普通でないことを前提にしても、自分が安全に動作できる条件を確認しながら動くソフトウェア**
を目指すことになる。
---
## 15. 最後に
この設計は、一見すると遠回りである。
しかし、その遠回りによって、
「たぶん安全」
「普通なら存在する」
「サーバー側で設定されているはず」
という暗黙の前提を減らすことができる。
そして、
> **「なぜ安全なのか」をソフトウェア自身が説明できる状態に近づける。**
PIPSにとって、この確認処理は余計な処理なのではない。
それ自体が、PIPSをどのような環境でも扱えるようにするための主要な設計要素である。