コードは1つの場所にのみ存在します。 この記事の主な目的は、アイデア自体を伝えることであり、コードがどれほど美しいかを示すことではありません。
はじめての何とか何とか
新しい「ユニークな」機能を実現するために、自分自身や仲間の旅行者に何時間も頭を悩ませるよりも、誰かの経験を読んで研究する方がはるかに簡単な場合があります。 私たちの時代のユニークなものはめったに見られません。 多くの場合、任意の機能が既に誰かによって使用されており、ボタンチェンジャーであるあなたはそれを自分の作業領域にのみ統合できます。
私が取り組んでいるプロジェクトでは、どのユーザーでも弁護士に質問をすることができます。 これが彼の主なタスクであり、この記事で検討します。
私のパスワードは何ですか？
私たちのプラットフォームに来て、ユーザーが必要とすることはただ一つ-助けです。 彼は登録したくないので、質問するためだけにログインします。 彼は今ここで答えを必要としています。
最初は、ログインせずに質問をすることはできませんでした。 ユーザーはこれについて苦情はありません。 登録フォームにボックスとパスワードを入力しても問題ありませんでした。 当初、弁護士はゆっくりと反応しました。 多くの質問はなかったので、クライアントはそのような質問があったことを忘れることさえできました。 システムで応答とメールへの通知を受け取ったので、クライアントが弁護士がそこに書いたものを見つける時間でした。 そして、ここで崩壊が起こります。ほとんどのユーザーは承認を習得していません。 パスワードを忘れました。 パスワード復旧フォームがなかったわけではありませんが、あまり役に立ちませんでした。 私たちは顧客を失い始めました...
質問したいだけです
彼らは、ゲストに質問を作成する可能性を開くことができると決めました。 エンティティを作成する形式のクライアントは、メールボックスを追加で入力します。 登録手順はありません。 クライアントは質問したかった-彼は彼に尋ねた。
弁護士は、ゲストから
Nashproekt.com Alahomora！
システムは、彼の質問に回答したという通知をクライアントに送信します。 しかし、手紙には特定のリンクが表示されます-魔法のリンクをクリックすると、ユーザーは承認され、満足のいく顔をした彼が質問のページに表示されます。 それだけです
ここで、おとぎ話は終わりました、そして、誰がよく聞きました。
次に、この「進行」の技術的な側面についてお話します。
ハッシュを得た
このプロジェクトは、前面と背面の2つの部分で構成されています。 バックエンドでサービスが開発され、マジックリンクシステムの動作を担当します。
最初に、システムは6文字のランダムなセット（文字+数字）を生成します-ハッシュ、データベースに保存します。 もちろん、ハッシュは一意性がチェックされます。
各ハッシュには独自の存続期間があり、それは生成されるユーザーの役割（後でパスワード用のメモリホールが増えた弁護士にそのようなリンクが届き始めたため）と、生成された結果の操作の種類（質問への回答、質問の作成、コメントなど）。 データベースには約14,000人のユーザーがいます。 実践が示すように、これまでのところ、6文字のハッシュは非常に適切に動作します。 期限切れのハッシュは削除されます。 6文字は、覚えておくか、アドレスバーに入力するのに理想的であると判断しました。
各ハッシュは、生成対象のユーザーに関連付けられています。 また、エンティティ（ID +タイプ）、つまりハッシュの生成を引き起こした操作にも関連付けられています。
マジックリンクを通過すると、フロントはバックハッシュを送信し、応答で次の操作の指示を待ちます。 ハッシュが有効な場合、ユーザーは承認され、エンティティの詳細ビューにリダイレクトされます。 ハッシュが有効でない場合、フロントはログインするようユーザーに要求します。
時間が経つにつれて、プラットフォームの開発は、コメント操作の場合、ハッシュをナビゲートするユーザーが新しいコメントにスクロールする必要があるという要件を満たしました。 したがって、ハッシュは追加の設定を受け取りました。これは「ロケーション」と呼ばれ、追加のパラメーター（この場合はコメントID）を含むフロントルートを格納します。ユーザーは承認後にリダイレクトされます。
プラットフォームの次の開発では、ユーザーが承認される前に多くの操作を実行する機能が必要でした。 たとえば、プロファイルを確認するか、質問に回答する期限までに何らかのタイマーを開始します。 これにより、ハッシュにエイリアスと呼ばれる設定が与えられました。 ハッシュを処理し、データベースで目的のハッシュを見つけるシステムは、エイリアス（テキスト定数を格納する通常の文字列）の存在を探します。 エイリアスが存在する場合、システムはその上にメソッド呼び出しを作成し、ユーザーが認証される前に必要な操作が実行されます
public function executeAlias() { if(!$this->hash->alias){ return $this; } //camelCase alias $aliasMethod = Str::camel($this->hash->alias); if(!method_exists($this, $aliasMethod)){ return $this; } return $this->{$aliasMethod}(); }
このハッシュ管理システムはそれ自体が非常によく証明されているため、ファイルにアクセスするように拡張しました。 状況は単純です。質問では、クライアントはファイルをダウンロードし、バックアップはサーバーの暗い腸のどこかに保存しますが、ユーザー（そのクライアント、弁護士）は美しいリンク/ストレージ/ hash12 / some_CODEを見ます。 ファイルをダウンロードするとき、ファイルハッシュを管理するシステムはハッシュコードペアをすぐに生成し、さらにファイルへのパスをそれらにバインドし、データベースにすべて保存します。
将来的に2要素認証に使用するために、マジックリンクのコードも統合する予定です。 ユーザーは、マジックリンクをクリックすると、電話でコードを受け取り、フロントが提案したフォームにコードを入力します。
このシステムにより、システムへの便利で柔軟なユーザーアクセスを構成できました。 状況を分析すると、間違ったパスワードとパスワードリマインダーを含む文字数のエラーがほとんどなくなったことがわかります。 各ハッシュのライフタイムを個別に変更したり、リクエストに応じて個々のユーザー用に生成したりできます。
プラーク、プラーク
そして最後に私は泣きます。 私は時々そのようなシステムを使用するサイト/プラットフォームが使用しないか、40文字の文字列がハッシュとして機能するという事実から泣きます 手紙のリンクをたどるのではなく、アドレスバーに手動で入力する必要がある場合があります。 私たちのプロジェクトの成長に伴い、いつかそのようなハッシュの長さに達することを否定しませんが...
ご清聴ありがとうございました。
PSこれは個人的な経験であり、小石を情報の大きな庭に置いていることを思い出します。