[kyasbal]
GAEでサーバーの方を実装中。
だけど、いろいろ難しい。
とりあえず今やっていることは、アカウント関係の実装。
どんなデータがあればいいのかとか考えつつも、セキュリテイのことも考えつつ・・・(この手のことは初心者)
GAEを使う上での、slim3っていうDB操作ライブラリの使い勝手の良さはすごい。
本当に楽だ。
GAEの管理ページにもとから標準装備の、DBビューワーはちょっと貧弱なので、管理ページもどきを新しく作ることで、ちょっと便利になった。だけど、結果的にあんまりもとからあるのと変わらないという始末。
将来的には、僕ら管理者用のアカウント管理ページとか必要だろうし、いいんじゃないかなと思うけど、今は特に作っても仕方ないな。
基本的には、クライアント側の動作で全て行うので、GAEでユーザーがブラウザを介して見るようなページは作成しない。プロジェクトが進んだら、プロジェクトのサイト作るかもね。でも、開発中の広報は、チームのredmineとJenkinsで十分だろうし、これもまだまだ先だろう。
OpenIDなんていうのも、見てみると、案外仕組みは単純だったりする。
さて、ここで今僕が一つ疑問に思っていて、更に悩んでいることがある。
GAEでユーザーがログインしているということを、どうやってサーバーがわは認識しているのだろうか。
セッション等Cookieを利用した技術であれば、クライアント側からの利用が難しくなる。C#のWebRequestクラスだっけか?ああいうので利用できるかわからないからね。
そうなれば、僕の貧弱なセキュリテイ知識で作られたCookieを一切使用しないサーバーを使うことになる。
いずれにしても、解決すべき難題は多いのだ。
OAuthについてもそうだ、この前かずと話して考えてたのだが、OAuthっていうのは、ホストアプリケーションへのユーザーの操作をゲストアプリケーションに委任するその許可を行うシステムのはずだ。
コンシューマーキーとか、わかってしまえば簡単に偽装が可能なはず。。。
それに、そういったアプリケーションのなりすまし防止用の技術でもなかったはず。
初期の計画では、クライアント側もOAuthで認証するっていう感じになっていた。
これは僕の思い込みかもしれないのだが、本末転倒じゃないのか?
たとえば、「zillionはzillionへのアクセスを要求しています。許可していますか?」などとユーザーに問いかける事になってしまうのではないだろうか。
なんとださいことか。これはおかしいはずなわけで、OAuthのコンセプトについて全く理解していなかった僕ではあったが、まだまだ実装というか活用?はまだまだ先だ。そもそも知識レベルでの解決すべき課題が大きいというのは問題だ。
さて、かずのような花形の部分を作っているわけではないので、特にスクリーンショットとか貼れないので、なんか寂しいと思います。。。
ソースなども、セキュリテイ上の観点からSVNの非公開レポジトリにあげている次第なのです。
こんな飾り気のない文章。。。読んでくれて本当にありがとね。
あと、忍者ブログの編集のFlash変わったね。綺麗になったと思う。
特に新しい機能はなさそうだけど・・・
[3回]
PR