4

base64 エンコーディング / デコーディングは決定論的アルゴリズムを使用します。そのため、特定の入力文字列は常に既知の出力文字列にエンコードされ、その逆も同様です。

ブラウザーを使用して基本認証で保護された URL にアクセスすると、ブラウザーはユーザー名とパスワードのペアを base64 文字列にエンコードし、その文字列を HTTP Authorization 要求ヘッダーに配置します。Firebug を使用すると、そのエンコードされた文字列をネットワーク モニターから簡単に読み取ることができます。これを文字列 A としましょう。

ラズベリー (Debian Wheezy を実行) に ddclient をインストールして、dyndns を使用してドメインの dns レコードを更新しました。ddclient 構成には、ブラウザーで URL にアクセスするために使用されるのと同じユーザー名:パスワードのペアが提供されます。クライアントは (基本認証を使用して) 同じ URL にアクセスしようとしますが、認証が正しくないためにアクセスが失敗します。ddclient のデバッグ出力内で、base64 でエンコードされた文字列を読み取ることができます。これを文字列 B と呼びましょう。

なんらかの理由で、ストリング A とストリング B は異なります。ただし、それらは同じユーザー名とパスワードのペアから作成されます。Debian シェルで文字列をデコードすると

echo myBase64EncodedStringGoesHere | base64 --decode

または JavaScript を使用してブラウザ コンソールで

atob('myBase64EncodedStringGoesHere')

結果は、文字列 A と文字列 B のどちらをデコードしても、常に同じユーザー名とパスワードのペアになります。

私の唯一の説明は、base64 エンコードの結果に影響を与える、ddclient のユーザー名:パスワード構成に目に見えない制御文字が含まれている可能性があるということです。viしたがって、エディターでコマンドを使用して ddclient 構成を確認しました

:set list

それはすべて良さそうです。私は困惑しています。誰かが何が起こっているのか接着剤を持っていますか?

更新 1

@C4storのコメントのため、ユーザー名とパスワードのペアを取り、シェルコマンドでエンコードするとどうなるかを確認しました

echo username:password | base64

その結果==、最後にパディング文字を含む文字列 A が得られます。パディングのほかに、debian OS は Web ブラウザ (Windows で使用) と同じ文字列を作成しました。

更新 2

@umläute のリクエストに応じて、2 つのデモ文字列を以下 に示します。 Stirng A: bXlkb21haW4uY29tOmRueURucz String B: bXlkb21haW4uY29tOmR5bkRucz

atob('STRING')

常に同じデコードされた文字列を提供します。

4

1 に答える 1

1

ddclient の構成ファイル内に、おそらくコピーと貼り付けが原因で、目に見えない制御文字がいくつかあったはずです...

を使用viして、ファイルからコンテンツを削除し、各行を手動で書きました。これで、ddclient は予期される base64 でエンコードされた文字列を生成します。

なぜ vi のコマンドで文字が表示されなかったのか、今でも疑問に思っています:set listが、少なくとも問題は解決しました。

于 2015-07-06T08:13:04.503 に答える