数週間前に、 django-registration 2.4.1をリリースしました。 ビルド2.4.xはdjango-registration 2.xバージョンの最後であり、次にバグ修正のみが行われます。 現在、メインブランチはバージョン3.0の準備を進めており、過去10年間のサポートで蓄積された大量の不要なジャンクを削除する予定です。最新のDjangoアプリケーションのベストプラクティスを考慮に入れます。

近い将来、新しいバージョンについて詳しく説明しますが、今は対処しなければならない一見単純な問題について少しお話したいと思います。 これらはユーザー名です。 はい、 「プログラマーのXに関する誤解」のような人気のある記事の1つを書くことはできますが、それがなぜそれが見かけよりも複雑なのかを本当に説明し、問題を解決する方法についてのヒントを提供することを好みます。 そして、有用なコンテキストなしで冗談を言うだけではありません。

備考：識別する正しい方法

ユーザー名-多くのサイトやサービス、および多くの一般的なフレームワーク（Djangoを含む）で実装されている形式では、ユーザーの助けを借りて解決しようとしている問題を解決するには、ほぼ間違いなく間違った方法です。 ユーザー識別に関して本当に必要なのは、次のいくつかの組み合わせです。

1. データベース内の外部キーのシステムレベル識別子。
2. 資格情報の検証を実行するためのログインID。
3. 他のユーザーに表示する公開識別子。

多くのシステムはユーザー名を要求し、これら3つのタスクすべてに同じユーザー名を使用します。 これはおそらく間違っています。 より有能なアプローチは、各識別子が異なり、複数のログイン識別子および/または公開識別子を1つのシステム識別子に関連付けることができる3方向の識別テンプレートです。

アカウントシステムを構築および拡張しようとする際の多くの問題と苦しみは、このモデルを無視することに起因します。 迷惑なほど多くのハックが、 このようなパターンをサポートしていないシステムで使用されているため、あたかもそれをサポートしているかのように見えて動作します。

したがって、2018年にシステムをゼロから開発している場合は、このモデルをベースとして使用することをお勧めします。 最初は少し作業する必要がありますが、将来的には優れた柔軟性と時間の節約が得られ、いつか誰かが再利用可能な使用のための許容可能なユニバーサル実装を作成することさえできます（もちろん、Djangoのためにそれを行うか、いつかそれを行うかもしれません）。

この記事の残りの部分では、一意のユーザー名が少なくともシステム識別子として機能し、システムへのログインと、ほとんどの場合すべてのユーザーに表示されるパブリック識別子として機能する、より一般的な実装を使用していると想定します。 そして、「ユーザー名」とは、本質的に任意の文字列識別子を意味します。 たとえば、RedditやHacker Newsなどのフォーラムのようなユーザー名を使用したり、メールアドレスや他の一意の行を使用したりできます。 重要ではありませんが、おそらく何らかの種類の一意の文字列を使用している可能性があります。 したがって、いくつかの問題について知る必要があります。

一意性は見た目よりも難しい

おそらくあなたは質問をします：それはどれほど難しいですか？ データベースに一意の列を作成するだけで完了です！ Postgresのユーザーでテーブルを作成しましょう：

CREATE TABLE accounts ( id SERIAL PRIMARY KEY, username TEXT UNIQUE, password TEXT, email_address TEXT ); 

以下に、ユーザーと一意の名前の列を含む表を示します。 簡単！

実際のアプリケーションについて考え始めるまでは簡単です。 john_doeとして登録されている場合、 JOHN_DOEとして登録するとJOHN_DOEますか？ これは別のユーザー名ですが、自分をあなただと思わせることはできますか？ 友人のリクエストを受け入れ、機密情報を私と共有するのは、コンピューターの場合は大文字と小文字が異なることに気付かないからです。

これは、多くのシステムで正しく実装されていない単純なことです。 この記事の調査中に、Djangoの認証システムは、他の多くのことを実装する正しいアプローチにもかかわらず、大文字と小文字を区別しないユーザー名を提供しないことがわかりました。 バグトラッカーにはユーザー名の大文字と小文字を区別しないチケットがありますが、大文字と小文字を区別しないユーザー名を一括で作成すると下位互換性が失われるため、WONTFIXとしてマークされます。 。 私はおそらくdjango-registration 3.0でこれを強制することを考えますが、それがそこに実装できるかどうかはわかりません。大文字と小文字を区別するアカウントが既に存在するサイトで問題が発生します。

したがって、今日システムをゼロから構築することを計画している場合、最初からユーザーのユーザー名の一意性チェックを行う必要がありますjohn_doe 、 John_Doe 、およびJOHN_DOEは同じ名前と見なされる必要があります。 それらのいずれかが登録されると、残りはアクセスできなくなります。

しかし、これはほんの始まりに過ぎません。 私たちはユニコードの世界に住んでおり、ここでは、操作username1 == username2を単に実行するよりも、一致する2つの名前を比較するのが困難です。 まず、キャラクターの構成と分解があります。 それらをUnicodeコードポイントのシーケンスとして比較する場合は異なりますが、画面上では同じように見えます。 したがって、ここでは正規化について考え、正規化フォーム（NFCまたはNFD）を選択し、一意性チェックを実行する前に各ユーザー名を選択したフォームに 正規化する必要があります。


「Unicodeの正規化」という記事の図-約 あたり

また、大文字と小文字を区別しない名前の一意性をチェックするシステムを開発するときは、ASCIIに含まれていない文字を考慮する必要があります。 StraßburgJoeとStrassburgJoeユーザー名は同一と見なされますか？ 答えは、多くの場合、小文字で正規化してチェックするか、大文字でチェックするかによって異なります。 また、Unicodeでの分解にはまださまざまなオプションがあります。 正規等価モードを使用するか互換モードを使用するかに応じて、多くの行で異なる結果を取得（および取得）できます。

これがすべて紛らわしい場合-そして、Unicodeの専門家であってもそうです！ -Unicode Technical Report 36のアドバイスに従い、 NFKCフォームの名前を正規化することをお勧めします。 DjangoまたはそのサブクラスでUserCreationFormを使用する場合（django-registrationはUserCreationFormサブクラスを使用します）、これは既に行われています。 Pythonを使用し、Djangoを使用しない（またはUserCreationForm使用しない）場合、これは標準ライブラリのヘルパーを使用して1行で実行できます。

 import unicodedata username_normalized = unicodedata.normalize('NFKC', username) 

他の言語については、優れたUnicodeライブラリを探してください。

いいえ、本当に、一意性は見た目よりも難しいです

残念ながら、それだけではありません。 正規化された文字列の大文字と小文字を区別しない一意性チェックが始まりですが、キャッチする必要があるすべてのケースをカバーしているわけではありません。 たとえば、次のユーザー名jane_doeます。 次に、別のユーザー名jane_doe検討します。 これは同じユーザー名ですか？

この記事で使用するフォントと、ブログで使用可能なフォントでは、それらは同じように見えます。 ただし、ソフトウェアの場合、それらは完全に異なり 、Unicodeの正規化および大文字と小文字を区別しない比較の後も変わりません（正規化を小文字または大文字でチェックするかどうかに関係なく）。

理由を理解するには、2番目のコードポイントに注意してください。 ユーザー名の1つでは、これはU+0061 LATIN SMALL LETTER A 別の例では、 U+0430 CYRILLIC SMALL LETTER A また、Unicodeの正規化や大文字と小文字の区別をなくしても、これらのコードポイントは同じになりますが、視覚的には完全に区別できません。

これは、 国際化ドメイン名のコンテキストで最初に広く知られたホモグラフィック攻撃の基礎です。 そして問題を解決するには、もう少し手間がかかります。

ネットワークホストの場合、1つの解決策は、 Punycodeビューに名前を表示することです。これは、ASCII文字のみを使用するエンコーディングで名前を表示することでこの特定の問題を解決するために作成されます。 上記のユーザー名に戻ると、それらの違いが明らかになります。 自分で試してみたい場合は、Pythonのワンライナーと、キリル文字を使用したユーザー名の結果を次に示します。

 >>> 'jne_doe'.encode('punycode') b'jne_doe-2fg' 

（ j\u0430ne_doe非ASCII文字のj\u0430ne_doe問題がある場合、この名前は文字列リテラルj\u0430ne_doeとして表現できます）。

ただし、この形式でユーザー名を表示することは実際には実用的ではありません。 もちろん、Punycodeを毎回表示できますが、これにより、非ASCII文字を含む多くの完全に通常のユーザー名の表示が壊れます。 本当に欲しいのは、登録時に上記のユーザー名を拒否することです 。 どうやってやるの？

さて、今回はUnicodeテクニカルレポート39に進み、セクション4と5を読み始めます。互いに異なる（正規化後でも）が、混同されても視覚的に同一または類似のコードポイントのセットは、混乱」（混乱）、およびUnicodeは、このようなコードポイントを検出するメカニズムを提供します。

この例のユーザー名は、Unicodeが「混合スクリプト混同可能」と呼ぶものであり、これが私たちが発見したいものです。 言い換えると、ユーザー名は完全にラテン語で「紛らわしい」文字を含んでおり、おそらく通常の文字と考えられます。 また、「紛らわしい」文字を含む完全なキリル文字のユーザー名は、おそらく通常のものと見なすこともできます。 しかし、名前が主にラテン文字と、視覚化すると混合前にラテン文字のようになった唯一のキリル文字コードポイントで構成されている場合、これは機能しません。

残念ながら、Python標準ライブラリは、そのような比較を行うためにUnicodeプロパティとテーブルの完全なセットに必要なアクセスを提供しません。 しかし、 Victor Felderという親切な開発者が適切なライブラリを作成し、無料のオープンソースライセンスでリリースしました。 confusable_homoglyphsライブラリを使用して、問題を特定できます。

 >>> from confusable_homoglyphs import confusables >>> s1 = 'jane_doe' >>> s2 = 'j\u0430ne_doe' >>> bool(confusables.is_dangerous(s1)) False >>> bool(confusables.is_dangerous(s2)) True 

2番目のユーザー名に対してis_dangerous()関数を実行した実際の結果は、潜在的な問題に関する詳細情報を含むデータ構造ですが、主なことは、混同を招くアルファベットとコードポイントが混在する文字列を識別できることです。 これが必要なものです。

Djangoでは、ユーザー名に非ASCII文字を使用できますが、異なるエンコーディングの同一の文字はチェックしません。 ただし、バージョン2.3以降、django-registrationはconfusable_homoglyphsライブラリに依存するconfusable_homoglyphs 、そのis_dangerous()関数はユーザー名と電子メールアドレスの検証プロセスで使用されます。 Django（または一般にPython）でユーザー登録を実装する必要があり、django-registrationを使用できない、または使用したくない場合は、 confusable_homoglyphsライブラリを同じ方法で使用することをお勧めします。

一意性を達成するのは難しいと言いましたか？

混乱を招くUnicodeコードポイントを扱っている場合、 同じアルファベットの類似文字をどう処理するかを考えるのは理にかなっています。 たとえば、 paypalおよびpaypa1 。 一部のフォントでは、互いに区別するのが困難です。 これまで、私の提案はすべて一般に適していますが、ここでは特定の言語、アルファベット、および地理的地域に固有の領域を入力しています。 ここでは、慎重に決定を下し、起こりうる結果を考慮に入れる必要があります（たとえば、誤解を招くラテン文字の禁止は、あなたが望むよりも多くの誤検知結果を引き起こす可能性があります）。 考える価値があります。 同じことは、異なるが互いに非常に類似しているユーザー名についても言えます。 データベースレベルでは、さまざまな形式でチェックインできます-たとえば、PostgresにはSoundexおよびMetaphoneのサポートが含まれ、 Levenshteinの距離とファジーマッチングトリグラムのサポートもあります-ただし、これはケースごとに行う必要があり、常にではありません。

名前の一意性に関する別の問題に言及したいと思います。 確かに、それは主に電子メールアドレスを指します。これは現在、ユーザー名としてよく使用されます（特に、サードパーティのIDプロバイダーに依存し、OAuthおよび同様のプロトコルを使用するサービスで）。 電子メールアドレスが一意であることを確認する必要があるとします。 以下にリストされているアドレスの数はいくつですか？

• johndoe@example.com
• johndoe+yoursite@example.com
• john.doe@example.com

明確な答えはありません。 ほとんどのメールサーバーは、ユーザー名を決定するときに、アドレスのローカル部分の+記号の後のすべての文字を長い間無視していました。 次に、多くの人がこの技術機能を使用して、ラベルとフィルタリングの特別なシステムとして「プラス」の後に任意のテキストを示します。 また、Gmailはドット（ . ）を無視することでも有名.サービスの分散ドメインを含むローカル部分では、DNSクエリがないと、一般に外部メールサーバーjohndoeとjohn.doe johndoe区別するかどうかを理解できませjohn.doe 。

したがって、一意の電子メールアドレスが必要な場合、または電子メールアドレスをユーザーIDとして使用する場合は、一意性チェックを実行する前に、おそらくローカル部分からすべてのポイントと+およびその後のテキストを削除する必要があります。 現在、django-registrationはこれを行いませんが、バージョン3.xでこの機能を追加する計画があります。

さらに、メールアドレスの混乱を招くUnicodeコードポイントを処理する場合は、このチェックをローカル部分とドメインに別々に適用してください。 ドメインで使用されているアルファベットを常に変更できるとは限らないため、ローカル部分とドメイン部分で異なるアルファベットを使用したことで罰せられることはありません。 ローカル部分もドメインの一部も、混乱を招くアルファベットの混合物を個別に含んでいない場合、おそらくすべてが正常です（そして、django-registrationバリデーターがこのチェックを行います）。

互いにあまりにも似ているために「異なる」と見なされないように、ユーザー名に関する他の多くの問題が発生する可能性がありますが、大文字と小文字の区別をオフにし、正規化を開始してアルファベットの混合を確認し、すぐに領土に入るとすぐに収益の減少[イノベーションごとに利益が減少する場合- 約 あたり ]。特に、言語、アルファベット、または地域に依存する多くのルールが適用されるためです。 これは、それらについて考える必要がないという意味ではありません。 誰にでも適した普遍的なアドバイスをするのは難しいというだけです。

状況を少し広げて、別のタイプの問題を考えてみましょう。

一部の名前は予約する必要があります。

多くのサイトでは、ログインフォームのフィールドとしてだけでなく、ユーザー名も使用しています。 一部のユーザーは、各ユーザーのプロファイルページを作成し、URLにユーザー名を入力します。 ユーザーごとにメールアドレスを作成するものもあります。 サブドメインを作成するものもあります。 そのため、いくつかの質問が発生します。

• サイトでプロファイルページのURLにユーザー名を入力した場合、 loginという名前のユーザーを作成するとどうなりloginか？ 自分のプロファイルに「ログインページが移動されました。ログインするにはここをクリックしてください」というテキストと、資格情報収集サイトへのリンクを投稿してください。 何人のユーザーが私をだますことができると思いますか？
• サイトがユーザー名から電子メールアドレスを作成する場合、 webmasterまたはpostmasterという名前のユーザーとして登録するとどうpostmasterますか？ ドメインのこれらのアドレス宛のメールを受信しますか？ 正しいユーザー名と自動生成されたメールアドレスでドメインのSSL証明書を取得できますか？
• サイトがユーザー名からサブドメインを作成する場合、 wwwという名前のユーザーとして登録するとどうなりますか？ またはsmtp 、またはmail ？

これらが単なる馬鹿げた仮説的な質問だと思うなら、 実際にはこのようなことが起こっています。 そして一度ではなく、 数回 。 いいえ、実際、 そのようなことが何度か起こりました 。

ユーザーアカウント用に自動的に作成されたサブドメインが、実際に何らかの目的で使用している既存のサブドメインと競合しないようにするために、いくつかの予防措置を講じることができます。 または、自動生成された電子メールアドレスが重要なアドレスや既存のアドレスと競合しないこと。

ただし、最大限のセキュリティを確保するには、特定のユーザー名が登録されないようにする必要があります。 Jeffrey Thomasによるこの記事で、 このようなアドバイスと予約名のリスト、および上記の最初の2つの記事を目にしたのは初めてです。 バージョン2.1以降、django-registrationには予約名のリストが付属しており、このリストはバージョンごとに大きくなります。 現在、約100のエントリがあります。

django-registrationリストでは、名前はいくつかのカテゴリに分割されており、必要に応じてそれらのサブセットを作成できます（バリデータはデフォルトですべてを適用しますが、指定された予約名の必要なセットのみで再構成できます）：

• 既知のサービスの自動検出/自動構成に使用されるホストアドレス。
• 一般的に使用されるプロトコルに関連付けられているホストアドレス。
• ドメイン所有権を確認するために認証局が使用するメールアドレス。
• 他の予約名のセットにリストされていない、 RFC 2142にリストされている電子メールアドレス。
• 共通アドレスは返信なし@。
• 機密ファイル名に一致する行（クロスドメインアクセスポリシーなど）。
• contactやloginような他の潜在的に機密性の高い名前の長いリスト。

django-registrationバリデーターは、 RFC 5785標準を使用して 「既知のURI」を示すすべてを保護するために、 .well-knownで始まるユーザー名も拒否します。

ユーザー名の混乱を招く文字の場合と同様に、django-registrationリストの必要な要素をコピーし、必要に応じて追加することをお勧めします。 同様に、このリストはJeffrey Thomasリストの拡張バージョンです。

これはほんの始まりに過ぎません。

ユーザー名をテストするためにできることのすべてがここにリストされているわけではありません。 完全なリストを作成しようとすると、私は永遠にここにとどまります。 ただし、これは優れた開始プラットフォームであり、これらのヒントのほとんどまたはすべてに従うことをお勧めします。 この記事が、ユーザーアカウントのような一見「単純な」問題の背後にどのような困難が隠されているかをおおよそ示したことを願っています。

すでに述べたように、Djangoおよび/またはdjango-registrationはすでにこれらのチェックのほとんどを実行しています。 そして、少なくともバージョンdjango-registration 3.0ではおそらく何もしないでしょう。 Django自体は、後方互換性の問題が強いため、近い将来（またはこれまでに）このようなチェックを実装できない場合があります。 すべてのソースコードは（BSDライセンスに基づいて）オープンであるため、問題なくコピー、改変、および改善してください。

重要なものを見逃した場合は、お知らせください。バグを報告するか、プルリクエストをGitHubのdjango-registrationに送信するか、 直接私に連絡してください 。