他のユーザーがあなたにメールを送信する際に、誤ってメールアドレスにピリオドを追加した場合でも、メールはあなたの受信トレイに届きます。たとえば、メールアドレスが「johnsmith@gmail.com」の場合、次のようにピリオドが含まれたメールアドレスもあなたが所有していることになります。
- john.smith@gmail.com
- jo.hn.sm.ith@gmail.com
- j.o.h.n.s.m.i.t.h@gmail.com
Solrによる検索環境を構築するにあたって、スキーマの設定ファイルを作るところは意外と面倒です。
その部分を試しに ChatGTP に手伝ってもらいました。
以下の内容で依頼しました。
Apache Solr で以下の文書のインデックスを作成します。デフォルトのスキーマ設定にスキーマAPIを使って必要な設定を追加するための JSON ファイルを作成してください。
インデックス対象の文書は以下の形式の JSON ファイルで与えられます。
[{“id”:”10″,”type”:”官公庁”,”area”:”住之江区”,”name”:”軽自動車検査協会大阪主管事務所”,”address”:”住之江区南港東3-4-62″,”address_p”:”34.6164938333333,135.438210722222″},
{“id”:”11″,”type”:”官公庁”,”area”:”住之江区”,”name”:”大阪陸運支局なにわ自動車検査登録事務所”,”address”:”住之江区南港東3-1-14″,”address_p”:”34.6190439722222,135.442191833333″}]
インデックス対象は、いつもの大阪の施設情報です。具体例として与えたのは2レコード分だけですが、以下のように適切なスキーマを作ってくれました。
以下は、Apache Solr でこの JSON ファイルをインデックスするためのスキーマ定義の例です。この例は、id、type、area、name、address、address_p の6つのフィールドをインデックスすることを想定しています。
{
"add-field": [
{
"name": "id",
"type": "string",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
},
{
"name": "type",
"type": "string",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
},
{
"name": "area",
"type": "string",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
},
{
"name": "name",
"type": "text_general",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
},
{
"name": "address",
"type": "text_general",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
},
{
"name": "address_p",
"type": "location_rpt",
"indexed": true,
"stored": true,
"required": true,
"multiValued": false
}
]
}
このスキーマ定義によって、以下のようにインデックスを作成することができます。
- Apache Solrの管理画面にアクセスします。
- 左側のメニューから「コアの作成」をクリックして、新しいコアを作成します。
- 新しいコアの名前を入力し、「コアを作成する」をクリックします。
- 新しいコアの管理画面に移動し、「スキーマ」をクリックします。
- 「スキーマ」のページで、「スキーマAPI」をクリックし、「スキーマ定義の追加」をクリックします。
- 上記のスキーマ定義をコピーして、「スキーマ定義の追加」のテキストボックスに貼り付けます。
- 「送信」をクリックしてスキーマを追加します。
- 左側のメニューから「ドキュメント」をクリックして、新しいドキュメントを追加します。
- 新しいドキュメントのJSON形式のデータを入力し、「追加」をクリックしてインデックスを作成します。
- インデックスが作成されたことを確認するために、左側のメニューから「クエリ」をクリックして、クエリを実行して結果を確認します。
短い文字列には string、 長めの文字列には text_general、緯度経度には location_rpt とデータの内容に合わせてフィールドタイプを選んでくれているように見えます。 address_pという名前がヒントになったかもしれないので hoge にして試してみましたが、やはり location_rpt になりました。
このようにインデックス作成までの準備の部分を AI に手伝ってもらえると、いろいろと楽になりそうです。
前回の記事では、認証器として指紋認証付きのスマートフォンを利用してパスキーによる認証を体験しました。その後、Google が販売する FIDO セキュリティキーである Titan Security Key を購入したので、そちらを使うパターンのパスキー認証を試してみました。
今回も WebAuthn.io のデモページを利用させてもらいます。
まず登録です。セキュリティキーをUSBポートに挿しておきます。
ユーザ名を入力して”Register”を押し、パスキーの作成方法として「USBセキュリティキー」を選択します。
セキュリティキーをタップします。
登録完了です。物理的に接続されている分、スマートフォンを利用する場合に比べてステップが少なくて済みます。
次に認証。
ユーザ名を入力して”Authenticate”を押し、セキュリティキーをタップします。
認証成功です。
ユーザ登録を実行したPC以外でも、セキュリティキーを挿しさえすれば、非常にスムーズにログインできます。
スマートフォンで認証を行う場合はセキュリティキーを NFC デバイスとして利用します。
ユーザ名を入力して”Authenticate”を押します。
セキュリティキー使用の確認画面が出るので「開始」を押します。
「NFCでセキュリティキーを使用する」を選択します。
セキュリティキーをスマートフォンのNFC読み取り箇所に当てます。
正しく読み取れたら認証完了。
PCでは認証器としてスマートフォンを使うよりもセキュリティキーを使う方が、全体的に手順が簡略に済みます。
ただ、スマートフォン自体で認証を実行するときにはスマートフォン自体の生体認証を使う方が楽なのは間違いないです。一つのアカウントで一つの認証器でしか登録できないということはないので、両方で登録しておいて状況に応じて使い分けるのが便利かなと思います。
こんにちは。開発担当のマットです。
今回の記事で、ウェブサービス等の開発者がパスワードを安全に保存するための塩かけ(ソルト)の概念を説明したいと思います。
大昔、ウェブサービスにアカウントを作成した際、そのウェブサービスが登録したユーザ名とパスワードをそのまま保存しました。
データベースを覗いてみると、各ユーザのユーザ名とパスワードはそのまま見れていました。
user_name | password |
田中 一郎 | 123456789 |
山田 太郎 | hogehoge |
鈴木 花子 | qwertyuiop |
村田 次郎 | hogehoge |
もちろん、サイトがハッキングされてしまった場合、全ユーザのパスワードが丸見えです。
これを使って、ログインすることもできますし、ユーザ様が別のウェブサイトで同じパスワードを利用している場合、そのウェブサイトにもログインされてしまうことは考えられます。
とても、不安全な方法でした。
こういう問題が明らかになった時、多くのウェブサービスがハッシングを使うようになりました。
ハッシングとは一方的の暗号関数です。
その関数にパスワードを渡したら、暗号された文字列が生成されます。
いくつかのハッシング・アルゴリズムは存在しますが、md5 というものを使ってみると、”hello” が “5d41402abc4b2a76b9719d911017c592” に変換されます。
特徴として、似たようなものを暗号化しても、その結果(ハッシュ)が全然違います。
例:
“bat” => 5f3f4681121b460e3304a1887f42f1c3
“cat” => d077f244def8a70e5ea758bd8352fcd8
“あいうえお” => 86deb27a32903da70a7b2348fcf36bc3
“あいうええ” => 5c6a3a46075a5617cd570ee1c583e528
パスワードを直接データベースに保存する代わりに、パスワードのハッシュを保存する時代になりました。
user_name | password |
田中 一郎 | 25f9e794323b453885f5181f1b624d0b |
山田 太郎 | 329435e5e66be809a656af105f42401e |
鈴木 花子 | 6eea9b7ef19179a06954edd0f6c05ceb |
村田 次郎 | 329435e5e66be809a656af105f42401e |
ユーザ様がログインする際、入力したパスワードを同じアルゴリズムでハッシングして、データベースで保存されているものと一致する場合のみ、正しいパスワードと言えます。
この方法で、データベースにパスワードを直接保存することなく、ウェブサービスを作ることはできるようになりました。
…ところで、ちょっとした問題はまだあります。見えますでしょうか?
上記の例で、山田 太郎さんと村田 次郎さんは同じパスワードを使いました。
同じパスワードを使っているため、ハッシュも当然同じです。
つまり、サービスがハッキングされてしまった場合、パスワードはバレませんが、「山田 太郎さんと村田 次郎さんは同じパスワードを使っています」というのがバレてしまいます。
もし、山田 太郎さんのパスワードが別の方法でバレてしまった場合、村田 次郎さんのパスワードもわかってしまいます。
あと、多くのユーザ様がいる場合、重複が多いパスワードを推測することも可能になります。
“password1” や “12345678” など、多くの人が使いそうなパスワードはあるので、重複数が多いユーザはこういうようなパスワードを使っていると言えますね。
調理する時、塩を少し加えるだけで味がグッと変わりますよね。
同じく、ハッシングをする時、パスワードだけではなく、「ちょっとした何か」を加えると、全く違う結果になります。
例として、2人のユーザが同じパスワード (“password123”)を設定するとします。
そのままハッシングすると、2人とも同じハッシュになりますが、ユーザAのパスワードに「abc」を付け加えてからハッシングして、ユーザBのパスワードに「xyz」を付け加えてからハッシングすると、2人とも全く違うハッシュになります。
この「ちょっとした何か」を「ソルト」と呼んでいます。
ソルトは乱数でも、ランダムな文字列でも大丈夫です。とにかく全てのユーザに違うソルトが振られたら問題ありません。
そうすると、仮に全員が同じ「password123」を設定したとしても、データベースに保存されるパスワードが全く違います。
user_name | salt | password |
田中 一郎 | PJTBCTwz | a021144f7dec828d515f372d6d239f5f |
山田 太郎 | 5g0VkWF1 | 19ead4c6deca667db146d9a1c478e4d6 |
鈴木 花子 | p9nfzkBT | 411fec4ff70554cded8b48ab9bc3b8c3 |
村田 次郎 | BoqWcL59 | 5487529bd4deb8003b6a46bbbaf03332 |
ユーザがログインする時、入力したパスワードにソルトを付け加えてハッシングすると、その結果が password として保存されている値と同じ場合、ログインをさせるという処理になります。
ご利用のウェブサービスが正しくソルト付けとハッシングをしているかどうかは判断しにくいですが、「パスワードを忘れました」などのリンクを押した場合、自分のパスワードがメールで送信されたら、安全に保管されていないと言えます。
パスワードを正しく取り扱っているウェブサービスはユーザのパスワードをわかる方法がないはずです。どこにも保存してはいけないデータとなります。
なので、ウェブサービスが自分のパスワードをメールで送信できる場合…アウトです。
ご注意ください。
こんにちは。開発担当のマットです。
僕はプログラミングが大好きです。パソコンに自由自在にコマンドを書いて、好きなものを作れることはとても面白くて、プログラマーになった理由です。
しかし、プログラムの書き方に気を付けないと、規模を拡大することに連れ、処理がカクカクと遅くなってしまうこともあります。
この記事にて、プログラマは常に気を付けなければならない Big O 記法を紹介したいと思います。
Big O 記法 (別名: オーダー記法、O-記法、ランダウの記号) はドイツの数論家であるポール・バッハマンによって1894年に、彼の著書『解析数論』(Analytische Zahlentheorie) の第二巻で初めて導入されました。これに触発されてエドムント・ランダウが1909年に発明しました。
「どういうもの?」かというと、何らかの関数(何らかの機能)の規模を大きくするに連れ、その関数の処理時間がどのように伸びるか、の表記と考えてもいいかもしれません。
ゲームの例で考えましょう・・・
特定のゲームではなく、たくさんのAIプレーヤが遊ぶ戦略ゲームとか、何でもいいです。
このゲームで、プレーヤーが順番に遊びます。
ゲームのメモリーに、プレイヤーの順番リストがあるとしましょう。
ゲームに4プレーヤーがいるとしましょう。
では、ゲームの一番目のプレーヤーを見つけるのに、どれぐらい時間がかかりますでしょうか?プログラムがしないといけない処理は:
・まず、プレーヤーのリストを見る。
・リストの頭のプレーヤを引き出す。
・終わり。
簡単な処理ですね。さて、プレイヤー数をなんと 10,000人にしたら、その処理がどうなるでしょう?
・まず、プレーヤーのリストを見る。
・リストの頭のプレーヤを引き出す。
・終わり。
変わりませんよね。Big O 記法では、こういう関数を O(1) と書きます。
O(1) とは、定数時間。関数に突っ込むデータの規模が大きくなっても、処理時間が変わりません。
プログラムを書く時(特に、大規模のデータを処理するプログラム)、O(1)の関数ばっかりでできることは一番望ましいです。
次、各プレーヤに100ポイントを与えましょう!
4人のプレイヤーがいる場合、
・まず、プレーヤー1に100ポイントを与える
・次、プレーヤー2に100ポイントを与える
・次、プレーヤー3に100ポイントを与える
・次、プレーヤー4に100ポイントを与える
・終わり。
簡単な処理ですが、10,000人プレーヤーがいるとしたら、その人数分の時間がかかりますよね。これは O(n) と書きます。
規模が大きくなるに連れ、その分遅くなります。データは2倍あるなら、処理は2倍遅い。
次、少し難しくなりますが、このゲームに「隠れ情報」があるとしましょう。
例えば、各プレーヤーの財産が自分にも、他人にも、見られないというルール。
もちろん見られませんが、賢いAIを作るには、自分と他プレーヤーの財産を推測する関数も作りたいですね。
・まず、プレーヤー1が自分の財産を推測する。
・次、プレーヤー1がプレーヤー2の財産を推測する。
・次、プレーヤー1がプレーヤー3の財産を推測する。
・次、プレーヤー1がプレーヤー4の財産を推測する。
・次、プレーヤー2がプレーヤー1の財産を推測する。
・次、プレーヤー2が自分の財産を推測する。
・次、プレーヤー2がプレーヤー3の財産を推測する。
・次、プレーヤー2がプレーヤー4の財産を推測する。
・次、プレーヤー3がプレーヤー1の財産を推測する。
・次、プレーヤー3がプレーヤー2の財産を推測する。
・次、プレーヤー3が自分の財産を推測する。
・次、プレーヤー3がプレーヤー4の財産を推測する。
・次、プレーヤー4がプレーヤー1の財産を推測する。
・次、プレーヤー4がプレーヤー2の財産を推測する。
・次、プレーヤー4がプレーヤー3の財産を推測する。
・次、プレーヤー4が自分の財産を推測する。
数えると、 4 プレーヤーで 16 ステップが必要です。
8プレーヤーだとしたら、64ステップが必要になります。
規模を2倍にすると、4倍の処理時間となりますね。
平方関係なので、O(n²) と書きます。
限りなく、他にもたくさんの表記があります。
O(n³) もありますし、 O((n-1)²)もあります。
O(log n)もありますし、恐ろしい O(n!) もあります。
それぞれのBig O 記法の表記の意味を暗記する必要はありませんが、プログラマーとして、何かの関数や機能やアルゴリズムを作るとき、無駄に時間が掛かるやり方でやっていないか、気を付けなければならないと思います。
この Big O 記法を常に頭にいれて開発をすると、より速やかで優れているコードは書けると思いますので、今後もこの記法を覚えてプログラミングをやっていきたいと思います。
皆様、Gmail使っていますか?
使っていますよね。使いましょう。
Gmailは今の時代なくてはならないほど便利なメールサービスです。
今回はGmailのちょっとした便利機能についてご紹介いたします。
現代においては、何をするにしてもメールアドレスを要求されることが多いです。
そんな時、1つのメールアドレスを使い回すのが一般的かと思います。
ただ、1つのメールアドレスを使い回すことでメールの整理がしにくかったり、個人情報が流出した場合にどこから漏れたのが把握できないといった事があります。
じゃあ複数のGmailを登録するの?
それはそれで有効だと思いますが、管理が複雑になったり手間がかかるので今回は別の方法をとります。
Gmailアドレスには、メールアドレスにピリオドが含まれていたとしても同じメールアドレスに届くという機能があります。
Gmailヘルプには以下のように記載されています。
Gmail アドレスでのピリオドの扱い
他のユーザーがあなたにメールを送信する際に、誤ってメールアドレスにピリオドを追加した場合でも、メールはあなたの受信トレイに届きます。たとえば、メールアドレスが「johnsmith@gmail.com」の場合、次のようにピリオドが含まれたメールアドレスもあなたが所有していることになります。
- john.smith@gmail.com
- jo.hn.sm.ith@gmail.com
- j.o.h.n.s.m.i.t.h@gmail.com
これをメールアドレスを要求された際に利用することで、この位置にピリオドがあるメールはどこで使っているメールアドレスだ、ということでフィルタリングし、整理に使うことができます。
また、迷惑メールが届いた場合には、あそこで使っているメールアドレスだからあそこから情報が流出したのか、という見当をつけることができます。
Gmailにはメールアドレスの@の前に+○○としても、同じメールアドレスに届く機能があります。
たとえば先程の「johnsmith@gmail.com」の場合、次のアドレスも所有していることになります。
※こちらはGmailの公式ヘルプページを見つけることができませんでした。
こちらの機能についてもフィルタリングに利用することができ、サービス名を入れることでよりわかりやすいものとなります。
ただ、こちらは場合によってはメールアドレスに+(プラス)が許可されておらず、利用できない場合があります。
どちらの機能も、とてもポピュラーで便利な機能となります。
今回は受信のみの説明で、Gmail側では何も設定が必要のないものとなりますが、Gmail側の設定を行うことで送信にも利用できるようになります。
需要があるようであれば、そちらも記事にしたいと思います。