要注意キーワード:みたいな感じ

要注意キーワード: みたいな感じ

想定される問題:

  • 類似させたい個所と、異なる結果にしたい個所が、正しく伝わらない可能性がある。
  • 良かった点、悪かった点が何なのか明確にならない可能性がある。

用例:

  1. トップページはアマゾンみたいな感じでお願いします。
  2. この前やったプレゼン、プロみたいな感じだったね。
  3. 素人みたいな感じのデザインで、どうかな?

キーワードが発生する要因:

  • 例を示しつつも、その通りではないということをほのめかしている。
  • 的確な表現が見つからない。対象となるものを全体的に評価しているが、詳細な点についての意図や評価基準を持っていない。
  • ネガティブな用例においては、湾曲表現、あるいは、意味をやや薄めた言い方であり、受け取り様によってはなんとでも解釈できる言い方をすることで、あつれきや問題視を避けようとしている。

会話でよく使われる「みたいな感じ」は、話のきっかけとして、大枠と方向性を示すには非常に有効である。しかしながら、「○○みたいな感じ」というのが最終的な目標や要望であるとすると、○○の何を継承し、なにを変更するのかという点は不明確なままになる。そのため、この表現が出た場合、具体的なポイントとして、何を意図しているのかを詳細に問いただす必要がある。

===========

…とまあ、パターンを考えながら、パターンのパターンを探っている、みたいな感じでw

擬態音は崩壊の前兆である

以下のメッセージは、今年の1/15にFacebookに書き込んだ内容です。パターンの勉強の一貫として、「書いてみる」ということをちょっとやってみているのですが、いろいろな意見をいただきました。これも、記録としてこっちにも書いておきます。

================================

プロジェクト進行や計画ミーティング等でのパターン:

◎擬態音は崩壊の前兆である

  • 例1:この部分はささっと終わらせて
  • 例2:ボタンを押すと、ポーンと出てくるのがいいね
  • 例3:これでバーンと儲かりますよ!

 

決めごとの中に擬態音が混在すると、そのゴールは人に寄って異なる解釈となる場合が多い。つまり、具体的な方針には成り得ないことが多く、後から問題が発生する場合が多い。あるいは、具体的になにをすべきか分かっていない、あるいは検討されていない場合のその場しのぎで発せられる場合もあり、対処すらできない場合もある。

バリエーション1:濁音>半濁音>それ以外、の順に不吉な予感は高まる。
バリエーション2:関西弁の擬態音は、ほとんど省略可能として無視できる。

解決策:
擬態音の部分を具体化するか、非機能要件として定義できれば、崩壊を免れることができる。擬態音が発生した段階で、その擬態音を具体的な要件、あるいは形容詞などで置き換えることを試みる。置き換えができないものは、要件ではないと判断し、検討を重ねる。
また、擬態音を省略した場合、意味が通じるかについて判定する。つまり、コミュニュケーションの手段としてより強調したり、印象づけるために使われている擬態音については要件と分離できるため、無視することも可能である。しかしながら、無視できるかどうかについては、さらにコミュニケーションを深める必要がある。

ここでBlogを再スタートします

最近までOS X Serverでブログをやっていましたが、OSのアップデートである意味うまくデータは移行できず、どうするか考えていたのですが、OS X Serverを離れてこういう手段を取る事にしました。ここは、NTC Hostingというところのサイトで、Moodleでのサービス提供用に確保したところですが、WordPressを数秒でレディにしてくれるというので、ここでWPで運用することにしました。古いブログは特に移行はしないつもりですが、OS X Serverのページはおそらく検索エンジンは取り出さないでしょうから、今後意味のありそうな情報は適時転送することにします。

ということで、どうしようか考えたのですが、「プロバイダでWord Press」です。Word Pressの人気と意味は良く分かっていますが、人が群がっているものを自分も食うのは好きではないので、ずっと避けていました。まあ、でも、どうでもいいことですので、手軽かつスピーディーであれば問題ないでしょう。はてなとか、アメーバとか、日本のみんなが使っているところっていうのもなんかなぁと思うし、わざわざマイナーなサービスを探すのもあほみたいですから、順当な線に落ち着きました。ということで、まずはバックアップの算段からやるかな(苦笑)。だけど、このWPって日本語化されていないってことですかねぇ…日本語のブラウザで見ているのにメッセージ全部英語です。まあ、いいんですが、海外のプロバイダだとこういうこともあるんですねえ。

ということで、全然不定期になると思いますが、更新したらFacebookに紹介するというオペレーションでやっていきたいと思います。

OME never die! と言いたいけれど…

<a href=”http://msyk.net/ome”>OME</a>を一生懸命やっていたのは、1999〜2004年くらいかな。ちょうど、<a href=”http://msyk.net/cserver/mdo.html”>MDOnline</a>の頃に重なります。その後も、だましだましOMEを使ってきました。相当だましたので、OS X Lionでも使えてはいますが…。ちょっとかなりきつくなってきました。それでも、never dieと言いたいのですが、かなり苦しいかも(苦笑)。

まず、「再開」の機能により、ウインドウの残り方が今ひとつよくないのか、落ちることしょっちゅうです。まあ、データを書き込んでいないし、所詮テキストファイルなので悪影響はまったくありませんが、あまりいい感じではなく、特に、command+Wでアプリが落ちるのはちょっと面倒です。コンパイルしなおそうとしているのですが、これがなかなかやっかいで、まだうまく行っていません。そこはだましだましなところですね。

そして、ついにというか、やっと気づいたというか、11月11日を境にiCloudのメールの受信ができなくなっていました。できないのをやっと気づいたというのは、iPadでもメールを読んでいるからです。fetchmailコマンドでme.comのメールってなんでだめなんだろうか? 認証のエラーが発生します。

仕方ないので、Mail.appでiCloudメールを受けるようにしました。

そこでふと考えたのは、Mail.appをfetchmail代わりに使うことです。メールソースをAppleScriptで書き出して、メールの整理はOME側でやればいいじゃん!ってことで、近々に取り組むつもりです。

電子メールというきわめてレガシーな仕組みが今だ、同じように残ると同時に混沌さは年々増す感じもします。昔から、電話をいちいち録音していないのと同じように、メールだって、しばらくすると「捨て」でいいとも思ったりもしますが、なぜ、テキストファイルで残したいのかというモチベーションを思い出し、もうひと頑張りしようと思います。つまり、OMEはメールの整理・ストレージに移行するということです。

さて、どうなることやら。

[IM]RSAを使って、JavaScriptで暗号化し、PHPで復号する

表題の通りの仕組みを、INTER-Mediatorに組み込もうとして、2日ほどもがきました。RSAつまり秘密鍵と公開鍵を使った暗号化をフレームワークに組み込み、クライアントで入力したパスワードを、暗号化してサーバに送るという仕組みを組み込んでいます。普通パスワードはハッシュだろうと思われるかもしれませんが、フレームワークが認証するパスワードではなく、パスワードをデータベースエンジンへのアクセスに使うべく、クライアントで入力したものをバックエンドまで安全に到達させるための暗号化なのです。

RSAやハッシュ関連のことは、ネイティブな開発ならOpenSSLを使えばおおむねOKなので、同じようにライブラリを集めれば楽勝だろうと思っていました。また、PHPにはopensslライブラリがあるので、まあ、なんとかなるだろうと思いました。要件としては、キーの指定を簡単にするということ。つまり、公開鍵と秘密鍵が1つもPEM形式で得られれば、それを設定ファイルに書き込むことでキーの指定ができるということです。もちろん、生成は「openssl rsagen 1024」みたいなコマンドで簡単に済ませたいわけです。

JavaScriptの世界では、Dave Shapiroさんが作っているライブラリがあり、後々のいくつかのライブラリの多くはこれを改良しています。DaveさんのはPEM形式でキーを与えられないので、Tom WoさんのCrypticoが作られたようで、さらに別の人が署名までできるようにしています。Crypticoでいろいろやっていたのですが、うまくいかない…というか、単純にこのライブラリの問題ではなく、PHPのライブラリとの組み合わせの問題があったのです。

それで、PHPの方はというと、openssl関連関数があるので大丈夫かと思っていたら、これがなかなかうまくいかいないのです。まず、PEMでキーを与えるのが原則とすれば、Crypticoを使ってクライアント側で暗号化するのが手軽です。それを、PHPのopensslの関数で復号するのがどうしてもうまくいかないのです。そのあたりのドキュメントが今ひとつ詳しく書いておらず、コメントには「マニュアルは正しくない…」などと書いてある始末で、あれこれやってもだめでした。

ただし、PHPのopensslの関数を使えば、PEMの鍵データから、RSAの本来の鍵というか、計算式に出てくる鍵の数値をそのまま得られる事がわかりました。さらに、RSA: Encrypting in JavaScript and Decrypting in PHPというドンピシャなものがあったのですが、それはDave Shapiroさんのライブラリを使っていて、RSAの本来の鍵を使う方法が記載されています。ところが、このサイトに書いてあるPHPのライブラリはpearにあるCrypt_RSAで、説明に使っているものはすでのメンテナンスがなされていません。それを使う手もありますが、メンテナンスされているライブラリの方がいいかと思い新しいサイトへのリンクを見ると、なんとこれが、以前このblogでも紹介したPHPだけで作られたSSHのライブラリを含むphpseclib:に移行していたのです。SSHのライブラリはきわめて順調に動いたので期待をして、こちらのRSAを使って復号しようとしました。しかしながら、どんなにこねくり回してもだめなのです。このライブラリのサポートのBBSにあるこの書き込みと同じ場所でエラーが出ているようです。Macだとだめで、debianだと動くようなことが書かれているのが気になるところですが、この方法でうまく流すには簡単には行きそうにありません。

Dave Shapiroさんのライブラリで暗号復号するのはできます。また、phpseclib:で暗号復号はできます。つまり、異なるライブラリをまたいでの暗号復号がうまくいかないのです。Dave Shapiroさんのライブラリで暗号化したものを、opensslコマンドで復号してみると、パディングに関するエラーが出て復号できません。データ形式の微妙な違いがあるのでしょうか? ドキュメンテーションの薄いライブラリや、あまりカスタマイズできないライブラリということで、これ以上手を下すことができず、ここで行き詰まってしまいました。

それで、改めてググって必死に探した結果、見つけたのがbi2phpというライブラリで、しかもMIT Licenseです。JavaScriptのライブラリは、Daveさんのものに独自に改良したものだそうです。それと互換でPHPのクラスを作ったというところでしょうか。いずれも、RSAの本来の鍵を指定するのですが、「データは全部HEX」というように、ある意味非常にわかりやすく、さくっとうまく行きました。

ということで、わかった事をまとめておきます。RSAの秘密鍵、公開鍵という仕組みはもういいとして、そこで使う鍵は、たとえば「openssl genrsa 1024」というコマンド入力で作られます。そのデータはPEMという1つのテキスト列であり、いわば、そこに秘密鍵と公開鍵などなど、RSA暗号処理に必要なデータがPKCSのルールに従ってパックされたものです。

$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus ...................++++++ ............++++++ e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQC/BlONnPUfSc95YmrcOUV0IbmeBZvibbAssetKBXAG0DGeKzc7        : 2MgfcIZ3C7lf0+yx3/RhXwJBAIYHkht7UPSpPeTvPzc4v89yBlkkGeN9xLbdONT3 uzINAQkGvVmDhNLYqxkgDysBUy/Q2f41DenUZJfEFLQBs5w= -----END RSA PRIVATE KEY-----

PHP側では、このPEM形式の文字列を使って、以下のプログラムで、RSAの計算に使うキーを求めることができます。$generatedPrivateKeyにはPEM形式のキーの文字列、圧縮アルゴリズムがAESの場合はパスフレーズを入れるので、その場合は$passPhraseに指定しますが、パスフレーズが設定されていない鍵は2つ目の引数は適当に無視します。

$res = openssl_pkey_get_private( $generatedPrivateKey, $passPhrase );
$keyArray = openssl_pkey_get_details($res);

この、$keyArrayの配列にいろいろなものが入っていて、公開鍵だけを取り出すには、$keyArray[‘key’]とします。

Daveさんのライブラリを使うには、鍵のオブジェクトを作成しますが、当然、自分で生成するのではなく、このPEMを鍵としてオブジェクトを初期化します。初期化関数部分は、次のように定義されています。biRSAKeyPairが鍵のクラス名と考えていいでしょう。

function biRSAKeyPair(encryptionExponent, decryptionExponent, modulus)

ここで、encryptionExponentは$keyArray[‘rsa’][‘e’]、decryptionExponentは$keyArray[‘rsa’][‘d’]、modulusは$keyArray[‘rsa’][‘n’]から得られます。生成した鍵からopensslのコマンドを使って出力(例えば、openssl rsa -text -in gen.key)した結果を見ながら、対応付けを確認しました。配列から得られた結果はバイナリなので、PHPの場合、bin2hex関数を使って16進文字列にして、JavaScript側の引数に指定をします。2次元目のeとdは、encrypt、decryptなんでしょうね。

なお、INTER-Mediatorでは、JavaScript側では暗号化しかしないので、2番目の引数は指定しません。というか、指定してクライアント側で見えたらいけません。なぜなら、$keyArray[‘rsa’][‘d’]は秘密鍵であり、暗号化には使わないからです。いずれにしても、JavaScriptのプログラムをサーバ側のPHPで生成してクライアントに送り込むという部分がこうした処理を組み合わせて作る事ができます。

bi2phpのPHP側のクラスは、JavaScriptとほぼ同様なプログラムでいいようになっており、サンプルのHTMLを見ればプログラムの作り方はすぐにわかると思います。非常に紆余曲折がありましたが、JavaScriptとPHPの双方で暗号復号をするには、bi2phpというライブラリでOKということです。ただし、PHPのopenssl関数を使って、PEMから鍵の値を得たりということは処理として必要になるということです。このライブラリをまとめたAndrey Ovcharenkoさんに感謝するともに、ライブラリをここまで育て上げたみなさんに感謝します。

消費税増税で忘れられていること

消費税が5%から8%、そして将来は10%になるという法案が政府によって進められています。現在、年間12兆円の消費税収入があるらしいのですが、いろいろな議論が巻き起こっているのも周知の通りです。その中でまったく議論が出てこないのが「免税業者」についての話です。

現在は、すべての取引(ただし非課税のものをのぞく)に消費税の徴収が義務とされているはずです。私は2005〜2008年は会社員だったのですが、その期間の前は、「あなたは免税業者ですか」と聞かれてから請求金額が決まるという会社が多かったことが思い出されます。免税業者なら5%付加しない金額で請求書を書き、その金額が払われてたのですが、会社員をやめてフリーになって改めて調べると、免税業者に対する支払いでも消費税を付加するのが必要という記述を税務署のサイトなんかで見つけました。世の中わかりやすくなったものです。会社員以前の消費税話もいろいろあるのですが、今現在の話をしましょう。

では、現在、免税業者になっている個人や法人はその付加された5%をどうしているかというと、単にその人や法人の収入になっています。免除されているので国に対して払う必要がなく、収入なわけです。つまり、借受消費税は単に収入としてあつかっていいことになっています。現在、免税業者としてメジャーなのは年間で1000万円以下の収入のある業者です。それから、会社設立してからの一定期間も免税業者です。零細企業の支援の側面もあるのかもしれませんが、比較的多いと思われるのが、サラリーマンをしながら副業でちょこっと儲けているような人も、その副業部分が免税業者扱いになっているのが多いのではないでしょうか。これは統計がないのでわかりませんが、会社員しながら1000万を超える売り上げがある人はかなりの強者であり、その方は副業でも課税業者になりますね。まあ、普通はそこまでかせげないでしょう。

2001年頃に、免税業者の基準が売り上げ3000万円から1000万円に引き下げられました。免税業者数は368万人から231万人になり、免税業者は全体の40%になるという数字が発表されています。それまでは消費税を払っていない業者の方が数で多いという結果だったのです。当時は「うちは株式会社ですから」みたいな理由で課税業者を名乗っていた人もいましたが、おかしな理屈であり、都市伝説としか言いようがなかったですね。まあ、それはいいでしょう。

私は、1000万円以下という免税業者という施策自体を再検討する必要があると考えます。税金の公平な負担という原則があるのなら、収入に関係なくルールに従って支払うべきです。消費税は、収益に正比例するきわめて公正な税金です。消費者にはあますところなく支払わせるのなら、業者も同様じゃないでしょうか。全業者の支払い義務があるとした上で、優遇措置を検討するべきです。

収入を500万円、そしてさらに中間の250万円を平均的な収益としたら、精算した支払い税額はその5%として12.5万円です。非課税業者が200万人としたら、2500億円となります。全体の税収12兆円の中でみれば少ないのですが、それでも2%程度の増収となります。もちろん、収入額の平均値はもっと少ないとも言えますが、でかくもなく、少なくもない規模ではないかと思います。ただ、徴収のための手間というか、経費が増えるとも言えるのですが、簡易的な計算方法を導入しつつ、オンライン化により、さほどの費用はかからないと思います。

大昔の3000万円のライン、1000万円のライン、いずれも「政治的な判断」とされていて、確固たる基準がありません。これを撤廃すると、必ず「零細企業を苦しめるのか」的な意見が出てきますが、苦しめているのではありません。本来、消費者が国に対して払ったと思っているお金を、自分のところにとどめないようにしましょうというだけのことです。本来の収入ではないものを「自分のもの」として扱うフィーリングが正しくありません。そして、少なくとも、サラリーマンの副収入、つまり生活の糧は本業の給料で得られている人にまで非課税を適用するという点は、過剰な優遇としか言いようがありません。

税の公平は絶対に守られていないといけないと思います。増税の話題で免税業者のことが出てこないことに、やっぱりどこか「選挙対策」が見え隠れしている気がします。

「気付き」という言葉について考えてみた

最近というか、ここ4、5年前から「気付き」という言葉がよく使われます。古い人間として、やや違和感があり、自分ではあまり使わない言葉ですが、やっぱり気持ち悪いと思う人もいるようです。

当然ながら、気付くは動詞、気付きは名詞です。しかしながら、気付きは「気付いた事」という以上に、自分自身がその事柄を所有している意識が強い単語と考えます。つまり、気付いた上でその背景を理解し、その事柄を別のことにも活かせるという意味を示すために使われているのではないでしょうか。しかしながら、気付いて、理解して、解釈してということもみんな動詞です。動詞って単なるプロセス的にとらえられることもよくあります。「早く起きるのは大変です」「起きるのは当たり前だろう」、つまり、起きて会社に行くのは当然というプロセスの中の動作が「早く起きる」ことなのです。一方「早起きは大変です」となるとどうでしょう。やっぱり「当たり前だろう」と思うかもしれませんが、「早く起きること」自体が成果になっているニュアンスが若干あります。うがった見方をすれば、「早起きして遅刻しないで出社できたという成果があった」という心理があるのではないでしょうか。

つまり、何かが起これば「気付く」のは当たり前だし、そういう状況になったら誰でもできるだろう、やるだろうという考えがあります。一方「気付き」というのは、その人が気付き理解したという成果を強調していることなのです。何でも成果を求められる昨今、イメージとして成果っぽい言葉が頻繁に使われるのはよくわかります。

しかしながら、この「気付き」は自分の成果だけでなく、自分が所属する組織に対する貢献を、暗黙に示す言葉でもあると考えます。お店に注文したとき、商品がないとき、「お取り寄せましょうか」と聞かれますが、「お取り置きしましょうか」という言い方もよく言われます。前者は、お客の注文だから仕入れるのは当然というニュアンスもありますが、後者はお店として顧客の要望に応えましたという成果の強調が感じられます。名詞化することで、自分の成果となり、組織の成果となる。そうなれば、言葉は自然に根付き、となるわけです。

さらに、動詞は続きを求めます。「お客様のお言葉に気付きました」「で、何を気付いたの?それでどうしたの?」となります。ところが「お客様のお言葉に気付きがありました」となると、もちろん、それはどうなのと聞きたくなりますが、何となく完結感漂う言い方となり、あまり突っ込めない雰囲気を作っています。よく、「悟る」と「悟り」が引き合いにだされますが、「悟り」と言ってしまえばそれ以上突っ込めません。「気付き」と言ってしまう事で、ある種の遮断、つまり言葉のやり取りの遮断が発生します。何かを報告するときになるべく上司に突っ込まれないようにしたいという気持ちが「気付き」という言葉を引き出すのかもしれません。

気付きという言葉に違和感があるとしたら、そのときのコンテキスト(文脈)において、成果を暗黙的に強調しているからだと考えました。その上で、深堀を暗黙に否認する感覚を聞いた人にもたらします。本来は、気付くことによって、他のことに応用できるわけですが、気付きだけを強調すると、本当に応用しているのかという疑問も湧きます。そして、応用できないのなら、ほんとに気付いているのかという疑問にもつながります。そして、その確認を遮断するのです。少なくとも「気付き」は悪い言葉ではありませんが、その結果、何ができるのか、何ができたのかを同時に伝えることで、違和感はなくなるのではないでしょうか。

JavaScriptのeventではまる

キーコードを取るkeyCodeや、シフトキーを押しているかどうかを確かめるshiftKeyというプロパティが「event」で使えることになっている。そこで、

document.onkeydown = function(e) { .. }

とすれば、常にキーを押したことを拾えるが、この場合は仮引数eがイベントを参照しており、e.keyCodeでキーコードが拾える。

ところが、次のように、onclickに関数を書いた場合、ブラウザ間の非互換性が発生する。

function clickThis(target) { … }
:
<div onclick=”clickThis(this)”></div>

clickThis関数内で「event.keyCode」と書いて動いてると思っていたら、Firefoxのみうまく動かなかった。つまり、eventというキーワードで、直前のイベントを取得するのはFirefoxではできなかったということである。Safariではできた。

しかしながら、以下のようにすると、Firefoxでも稼働した。関数clickThis内部では、ev.keyCodeなどによってイベントのプロパティに参照する。

function clickThis( target, ev ) { … }
:
<div onclick=”clickThis( this, event)”></div>

つまり、Firefoxでは、「event」によって、直前のイベントを参照できるのはローカルな範囲だけということになる。他のブラウザで、「event」という記述が使えるのは「window.event」というウインドウに直前のイベントを参照できるプロパティが存在しているからである。Firefoxにはそういうプロパティは存在しないが、JavaScriptの規約では存在しないので正しいらしい。

[IM]INTER-Mediatorの認証フレームワーク(2)

少し前に書いた記事「INTER-Mediatorの認証フレームワーク」でのプロトコルでは、中間者攻撃に弱いのが分かったので、最初に1回やりとりを増やしました。

cd573

こうすれば、中間者が得られるデータは、un、ch、h(ch, h(pw))となります。しかしながら、正しいリクエストでは、h(ch, h(pw))の計算におけるh(pw)つまりパスワードにハッシュをかけたデータが必ず必要になります。中間者はそれを持っていないので、正しいリクエストを生成できません。(当然ですが、ハッシュなので、h(ch, h(pw))からその計算の元になっているh(pw)は求められないという前提があります)

また、チャレンジは毎回異なる(確率的に同一である可能性は0とみなせる)とすれば、毎回チャレンジの値が変わり、「以前と同じチャレンジが生成されるまで待つ」という手段もとれなくなります。また、毎回チャレンジが変わることで、同じ通信内容でも生成したデータが異なることになり、過去のデータをため込むことでの一致を見つける手法もほとんど役に立たないと思われます。

これで、クライアントとサーバの間の通信経路のセキュリティはとりあえずクリアできたとします。

アプリケーションの実行する上では、クライアントのJavaScriptはある意味、プログラムを勝手に実行されて変数の値などを取り出されたり設定できる可能性があります。その状態で懸念されるのは、他人への成り済ましです。自分のアカウントでログインをした後、javascript:…でユーザ名の変数を書き換えて、アクセスが成立すると問題です。特にその方法で他人に成り済ますのは重大なセキュリティの問題になります。

上記の方法では、仮にユーザ名を変えることができても、チャレンジとユーザは対応関係があるため、ユーザ名の変更をしてしまった後では必ず認証エラーが出るはずです。

開発者が意図したテーブル以外にアクセスできるか…ですが、データベースのアカウントはサーバから移動しないので(ただし、デバッグモードで見える事もある)クライアントで参照はできない。つまり、データベースの直接続は無理です。リクエストのテーブル名を変更する事もできません。定義ファイルに記述したテーブルとそれへのアクセスしかできないので、たとえば、一般には見せていないユーザ管理テーブルを参照することも不可能です。

さて、また、少し塩漬けします(笑)。

[IM]INTER-Mediatorの認証フレームワーク

INTER-Mediatorはだいぶんと実用的になってきました。そろそろ、先のアーキテクチャを考えはじめています。認証のフレームワークをどうするか、いろいろ考えています。要は、AJAXでの認証となると、単にHTTPでの処理と同じという情報しか得られませんでした。それでもいいのですが、Webアプリケーションでの苦労をもう一度行うことになります。認証は確かにできるのですけど、その後、アクセス権の管理をアプリケーションに組み込まないといけません。たとえば、ユーザごとに参照できるレコードが決まっている場合、認証結果からクエリのパラメータを調整するなどの処理が必要になります。下手をすると、ユーザ名をうまく切り替えたら他人になってしまえるようなものになってしまいかねません。

つまり、認証とアクセス制御をフレームワークで処理をすることによって、アプリケーション作成の上で、安全確実に認証をすることを考えたいと思いました。

とは言え、独自にプロトコルを組むというのも大変な話です。ここで、AWSのやり方をヒントにして、ハッシュをリクエストに入れて認証をするという方式を利用してみることにします。

前提は、データベースがあって、ユーザ、ハッシュしたパスワード、チャレンジ、チャレンジの発行タイムスタンプを持つテーブルを利用するとします。これらはフィールド名は決め打ちにしてしまうつもりですが、他のフィールドは自由に作成できます。その上で、以下のようなシーケンスを考えてみました。h( ) はハッシュを求める関数のつもりです。48623

現在、テーブルは自由に利用できますが、たとえば “security” という属性を作り、そこにフィールド名を記述すると、そのフィールド名に、ユーザ名と同じデータしか取り出さないようにするという仕組みにしたいと思います。たとえば、personテーブルがあれば、

“name”=>”person”,
“security”=>”accessibleusername”,…

のように定義ファイルを作ります。WHERE句で、accessibleusername = ユーザ名、という条件を常に付ければいいかと思います。なお、”security” 属性をたとえば、”__im_authonly” にすると、認証が通ればすべてのデータを参照できるといったような仕組みも入れておこうかと思っています。

あと、ユーザデータベースの保護についても考えないといけませんね。まあ、でも、定義ファイルにあるテーブルしか処理できないという仕組みを徹底させればいいのかなと思ったりします。何か穴があれば、ぜひともご指摘ください。