％username％さん、ご安心ください！
この一連の投稿では、支払いシステムの実装のいくつかの側面についてお話しします（幸運であれば、2つ）。これは、広大な国の都市の1つで2000年代半ばから本当に光栄でした。
PS全般とは何ですか？また、どの原則によってPSが機能するのですか？ 私は、顧客と同じように、WebMoneyと支払い端末のユーザーとしてのみこの考えを持っていました。 しかし、欲望とお金がトリックを行い、開発が始まりました。
まず、支払いシステムとして一般に理解されていたものと、開発がどのように始まったか。
UPD：
第二部！
顧客はサイトを望んでいました。 同様に、
Webサーバーは、Apacheを備えたFreeBSDと、MySQLを備えたWindows上のデータベースサーバーです。
残念ながら、当時のPostgreは私にとって（そして今でも）密林であり、MS SQL ServerからFreeBSDに直接接続することはできませんでした。 さらに、DBMS用の外部モジュールを作成し、暗号化を担当する部分を担当することで、OSの選択に終止符を打つことが計画されていました。
開発中の私にとって重要な問題は、セキュリティの問題でした。 システムは何でも機能しましたが、それでもお金はかかりました。
ほとんどすぐに、次の単純なWEBサーバー<-> DBサーバー操作スキームが生まれました。
- Webサーバーは、1つのデータベース内の許可されたストアドプロシージャにのみアクセスできます。 SELECT \ INSERT \ DELETEはありません。 いくつかのストレージとすべての呼び出しのみ。
- Auth（ログイン、パス）を除く、Webサーバーで使用可能なすべてのストレージは、セッションIDを最初のパラメーターとして取得し（そして最初にその存続可能性を確認します）、ハッシュとしてAuthに戻り（ランダム（））、非アクティブになってから数分後にのみ有効になります。
このように
- SQLインジェクトから100％保護されています
- 99％は、Webサーバーが完全に侵害された場合に攻撃者から防御しました（1％はMySQLとファイアウォールの穴に残されます）。 web / qwertyデータベースでWebサーバーアカウントのログイン/パスワードを実行し、静かにスリープできます。 ハッカーの敗者には、ストレージの空の結果のみが表示されます
- システムのすべてのロジックはストレージに実装されています。実際、Webサーバーはそれらを呼び出すだけで、ユーザーに結果を表示します。
ユーザー側からは、VeriSignから購入した証明書を使用して、トラフィックをSSLで保護しました。
最初の近似として、「3リンク」のない安全な「3リンク」が得られました。これは操縦に非常に便利で、私の意見では、良好なセキュリティ基準を満たしていました。 問題が発生したのは、新しいストレージが追加されたときだけで、駐車場でWebサーバーアカウントのアクセス許可を設定するのを忘れていました）
データベースの構造（面白くない）と仮想ウォレットの保護システムについて考える必要がありました。
habrasocietyに興味がある場合は、次の部分で説明します。
- 特に楕円曲線を使用し、この奇跡をすべてMySQLにねじ込むEDSシステムについて、クライアントを保護します。
- 「農場支払いモジュール」のプロトタイプ。
- セルフサービス端末の支払いシステムをゼロから開発します。