Re: cookie認証方法

2006-09-03 スレッド表示 hayakawa

木村さんへ

bodyです。

ご教授どうもありがとうございます。
当初の疑問は解決しました。

本日、Cookie実装のテストも完了し、
別のWebServiceライブラリまでも動作を確認できました。

このたびは、ありがとうございました。


 To: bodyさんへ
 
  木村です。
 
  例えば、ロードバランシングによるサーバ分散への対応を考えています。
  サーバより受け取ったCookieを使い続けることで、分散環境においても
  特定サーバにのみ向かうよう仕向けるわけです。
  (複数メソッドの実行で1オペレーション完了となるようなWebService
  です)
 
  上記例は、セッション管理が必要となるごく一般的な事例だと思います。
 
  この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか?
 
  そうではありません。
  WebサービスのCookie値は、『業務ロジックとして意味を持たないIDのみに
 限定すべきであって、Bodyさんの元々の質問にあったようにCookieに複数の
 値を格納しようとしたり、その格納値に業務的な意味を持たせるような使い
 方は、Webサービス的ではない』という意味です。前述のロードバランシング
 の例も、乱数などのユニークなセッションIDがCookie値に格納されるだけで
 実現可能な訳です。
 
  また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待
  するべきではないと考えてよいのでしょうか?
  (例:Client axis / Server .Net)
  (例:Client .Net / Server axis)とかです。
 
  恐らく、かなり古いバージョンのランタイムでなければ、期待とおりに動作
 すると思います。しかし、各種仕様としては、Cookieによるセッション管理が
 必須項目でない以上、全てのクロスプラットフォームの相互接続性を保証する
 のは難しいとは思います。安心するためには、利用するランタイムを決定して
 自ら動作検証する必要があります。
 
 宜しくお願いします。
 ---
 Toshi [EMAIL PROTECTED]
 
 On Wed, 30 Aug 2006, hayakawa wrote:
 
 
  bodyです。
 
  木村さんへ
 
  返答ありがとうございます。
  WS-Iにそういった記載がありますね。
  その旨は理解しているつもりです。
 
   一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
  の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
  はすべきではない、という事になります。Webサービスでのセッション
  管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
  クライアント間で送受信することにより、連続したWebサービス通信で
  あることを示す、というハンドリングを指します。
 
  例えば、ロードバランシングによるサーバ分散への対応を考えています。
  サーバより受け取ったCookieを使い続けることで、分散環境においても特定サー
  バにのみ向かうよう仕向けるわけです。
  (複数メソッドの実行で1オペレーション完了となるようなWebServiceです)
 
  この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか?
 
 
  また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待する
  べきではないと考えてよいのでしょうか?
  (例:Client axis / Server .Net)
  (例:Client .Net / Server axis)とかです。
 
 
  -- 
  hayakawa [EMAIL PROTECTED]
  To: bodyさん
 
   木村です。
 
   まず、「通常のWebブラウジング」と「Webサービス」でのCookieの
  利用方法には違いがあります。Webブラウザでの動作や仕組みについて
  はご理解頂いているという前提として、「Webサービス」では
 
  ・Cookieを使ったセッション管理を試みても良いが、それが確実に
   機能する保証はない
  ・Webサービスの正常動作のために、クライアントのCookie対応を
   必須とすべきではない
  ・Cookieで転送される値が、クライアントにとって意味のある値を
   利用すべきではない
 
  という考えがあります。これは、Webサービスの根本的な考え方として
  意味のあるデータはSOAPメッセージの中でやり取りすべきであって、
  特定のトランスポートプロトコル(HTTPなど)に依存すべきではない、
  という思想が強く影響しています。
 
   Cookieは、HTTPプロトコルに蜜に依存している他、SOAPメッセージ
  の外側でデータ交換する仕組みであることから言って、Webサービス界
  では「異端」と言っても良いかも知れません。しかし、現実世界では
  Cookieを利用したセッション管理が最も普及していて、確実な手法で
  あるのも事実です。このため、AxisではCookieを利用したセッション
  管理に対応しました。
 
   セッション管理は、サーバ側とクライアント側双方が対応する必要
  がありますが、Axisでは以下の変更が必要です。
 
  ・サーバ側
   WSDD内のSessionスコープパラメタにより、スコープを設定
 
  ・クライアント側
   「service.setMaintainSession(true);」によりCookieを受付ける
 
  [EMAIL PROTECTED]
  をご理解いただけるものと思います。
 
   一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
  の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
  はすべきではない、という事になります。Webサービスでのセッション
  管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
  クライアント間で送受信することにより、連続したWebサービス通信で
  あることを示す、というハンドリングを指します。
 
  以上でご理解頂けたでしょうか?
  ---
  Toshi [EMAIL PROTECTED]
 
  On Mon, 28 Aug 2006, hayakawa wrote:
 
 
  木村さん
 
  bodyです。レスありがとうございます。
  #とりあえずMLが機能していて助かりました。
 
   下記本文中で「Cookie認証」という言葉が用いられている
  のですが、何を意図しているのかよく分かりません。
  言葉足らずですみません。
  Cookieを使ったセッションの管理です。
 
  @ITサイトからの引用ですが、
  -
  セッションを利用できるようにするには、Webブラウザが持っている
  機能をWebサービス・クライアントにおいても実現することです。
  いちいち記述することは大変面倒ですが、Axisには便利なAPIが用意
  されているため、大変容易にセッションを利用することができます。
 
  Axisには「setMaintainSession()」メソッドが用意されています。
  このメソッドはServiceインスタンスに対して実行することで、
  Cookieを扱えるようにしてくれるものです。利用方法は、次のように
  Webサービス・クライアントプログラムを変更するだけです。
  -
  とあります。
 
  その回答として、
  service.setMaintainSession(true);
  をクライアントにて記述すればよい、との記載例なのですが、
 
  例えば、
  ・1サーバに対し1Cookieの保持なのか
  ・Cookieの容量はどのくらいまで大丈夫なのか
  などの疑問があります。
 
  このように色々懸念材料があるにも関わらず、
  setterひとつで簡単に実装できてしまうの?ということです。
 
  とりあえず前提として、Cookieでのセッション管理は可能であると
  いう認識でよいのでしょうか?
 
  環境は、
 
  ◆Client
  axis1.1
  J2SE1.4
 
  ◆Server
  WebSphere 5.1 or 6
 
  で行っています。
  #現状Cookieセッション管理無しでWebServiceは動作しています。
  #今手元にコードがないので、用意しておきます。
 
  よろしくお願いします。
 
  --
  hayakawa [EMAIL PROTECTED]
 
  To: bodyさん
 
   はじめまして。
   木村と申します。
 
   下記本文中で「Cookie認証」という言葉が用いられている
  のですが、何を意図しているのかよく分かりません。
 
   具体的にどのようなことを実現したいのかにつてもう少し
  詳しく教えていただくことはできますでしょうか?
 
  よろしくお願いします。
  ---
  Toshi [EMAIL PROTECTED]
 
  On Sat, 26 Aug 2006, hayakawa wrote:
 
  はじめまして。bodyと申します。
 
  axis1.1を用いたWebサービスにおいて、Cookie認証の情報を探しています。
 
  http://www.atmarkit.co.jp/fjava/rensai2/wbsrvic05/wbsrvic05_3.html
  上記URLにおいて、axisのセッションについて書かれていますが、
  このようにクライアントに、
 
  service.setMaintainSession(true);
 
  のコードを埋め込むだけで、認証が行われるのでしょうか?
  (ClientにCookieを受け取ったり、維持するようなハンドリングは不要なのか?)
 
  また、これはサーバクライアント共にaxisを用いた場合にのみ保障されるもので、
  例えサーバ側からCookieが発行されていたとしても、サーバがaxis以外のエンジ
  ンを使用している場合には動作しないものなのでしょうか?
 
 
  参考情報ありましたら、ご提供ください。
 
  --
  [EMAIL PROTECTED]
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL 

Re: cookie認証方法

2006-08-30 スレッド表示 Toshiyuki Kimura

To: bodyさんへ

 木村です。


例えば、ロードバランシングによるサーバ分散への対応を考えています。
サーバより受け取ったCookieを使い続けることで、分散環境においても
特定サーバにのみ向かうよう仕向けるわけです。
(複数メソッドの実行で1オペレーション完了となるようなWebService
です)


 上記例は、セッション管理が必要となるごく一般的な事例だと思います。


この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか?


 そうではありません。
 WebサービスのCookie値は、『業務ロジックとして意味を持たないIDのみに
限定すべきであって、Bodyさんの元々の質問にあったようにCookieに複数の
値を格納しようとしたり、その格納値に業務的な意味を持たせるような使い
方は、Webサービス的ではない』という意味です。前述のロードバランシング
の例も、乱数などのユニークなセッションIDがCookie値に格納されるだけで
実現可能な訳です。


また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待
するべきではないと考えてよいのでしょうか?
(例:Client axis / Server .Net)
(例:Client .Net / Server axis)とかです。


 恐らく、かなり古いバージョンのランタイムでなければ、期待とおりに動作
すると思います。しかし、各種仕様としては、Cookieによるセッション管理が
必須項目でない以上、全てのクロスプラットフォームの相互接続性を保証する
のは難しいとは思います。安心するためには、利用するランタイムを決定して
自ら動作検証する必要があります。

宜しくお願いします。
---
Toshi [EMAIL PROTECTED]

On Wed, 30 Aug 2006, hayakawa wrote:



bodyです。

木村さんへ

返答ありがとうございます。
WS-Iにそういった記載がありますね。
その旨は理解しているつもりです。


 一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
はすべきではない、という事になります。Webサービスでのセッション
管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
クライアント間で送受信することにより、連続したWebサービス通信で
あることを示す、というハンドリングを指します。


例えば、ロードバランシングによるサーバ分散への対応を考えています。
サーバより受け取ったCookieを使い続けることで、分散環境においても特定サー
バにのみ向かうよう仕向けるわけです。
(複数メソッドの実行で1オペレーション完了となるようなWebServiceです)

この場合「特別な意味を持つ」ので、やはりすべきではないのでしょうか?


また、axis間以外を考えた場合、Cookieによるセッション管理の動作は期待する
べきではないと考えてよいのでしょうか?
(例:Client axis / Server .Net)
(例:Client .Net / Server axis)とかです。


--
hayakawa [EMAIL PROTECTED]

To: bodyさん

 木村です。

 まず、「通常のWebブラウジング」と「Webサービス」でのCookieの
利用方法には違いがあります。Webブラウザでの動作や仕組みについて
はご理解頂いているという前提として、「Webサービス」では

・Cookieを使ったセッション管理を試みても良いが、それが確実に
 機能する保証はない
・Webサービスの正常動作のために、クライアントのCookie対応を
 必須とすべきではない
・Cookieで転送される値が、クライアントにとって意味のある値を
 利用すべきではない

という考えがあります。これは、Webサービスの根本的な考え方として
意味のあるデータはSOAPメッセージの中でやり取りすべきであって、
特定のトランスポートプロトコル(HTTPなど)に依存すべきではない、
という思想が強く影響しています。

 Cookieは、HTTPプロトコルに蜜に依存している他、SOAPメッセージ
の外側でデータ交換する仕組みであることから言って、Webサービス界
では「異端」と言っても良いかも知れません。しかし、現実世界では
Cookieを利用したセッション管理が最も普及していて、確実な手法で
あるのも事実です。このため、AxisではCookieを利用したセッション
管理に対応しました。

 セッション管理は、サーバ側とクライアント側双方が対応する必要
がありますが、Axisでは以下の変更が必要です。

・サーバ側
 WSDD内のSessionスコープパラメタにより、スコープを設定

・クライアント側
 「service.setMaintainSession(true);」によりCookieを受付ける

[EMAIL PROTECTED]
をご理解いただけるものと思います。

 一番bodyさんが知りたい点は、WebブラウザでのCookieのように複数
の意味ある値をWebサービスで送受信する方法だと思うのですが、それ
はすべきではない、という事になります。Webサービスでのセッション
管理とは、(特別な意味を持たない乱数的な)ユニークなIDをサーバと
クライアント間で送受信することにより、連続したWebサービス通信で
あることを示す、というハンドリングを指します。

以上でご理解頂けたでしょうか?
---
Toshi [EMAIL PROTECTED]

On Mon, 28 Aug 2006, hayakawa wrote:



木村さん

bodyです。レスありがとうございます。
#とりあえずMLが機能していて助かりました。


 下記本文中で「Cookie認証」という言葉が用いられている
のですが、何を意図しているのかよく分かりません。

言葉足らずですみません。
Cookieを使ったセッションの管理です。

@ITサイトからの引用ですが、
-
セッションを利用できるようにするには、Webブラウザが持っている
機能をWebサービス・クライアントにおいても実現することです。
いちいち記述することは大変面倒ですが、Axisには便利なAPIが用意
されているため、大変容易にセッションを利用することができます。

Axisには「setMaintainSession()」メソッドが用意されています。
このメソッドはServiceインスタンスに対して実行することで、
Cookieを扱えるようにしてくれるものです。利用方法は、次のように
Webサービス・クライアントプログラムを変更するだけです。
-
とあります。

その回答として、

service.setMaintainSession(true);

をクライアントにて記述すればよい、との記載例なのですが、

例えば、
・1サーバに対し1Cookieの保持なのか
・Cookieの容量はどのくらいまで大丈夫なのか
などの疑問があります。

このように色々懸念材料があるにも関わらず、
setterひとつで簡単に実装できてしまうの?ということです。

とりあえず前提として、Cookieでのセッション管理は可能であると
いう認識でよいのでしょうか?

環境は、

◆Client
axis1.1
J2SE1.4

◆Server
WebSphere 5.1 or 6

で行っています。
#現状Cookieセッション管理無しでWebServiceは動作しています。
#今手元にコードがないので、用意しておきます。

よろしくお願いします。

--
hayakawa [EMAIL PROTECTED]


To: bodyさん

 はじめまして。
 木村と申します。

 下記本文中で「Cookie認証」という言葉が用いられている
のですが、何を意図しているのかよく分かりません。

 具体的にどのようなことを実現したいのかにつてもう少し
詳しく教えていただくことはできますでしょうか?

よろしくお願いします。
---
Toshi [EMAIL PROTECTED]

On Sat, 26 Aug 2006, hayakawa wrote:


はじめまして。bodyと申します。

axis1.1を用いたWebサービスにおいて、Cookie認証の情報を探しています。

http://www.atmarkit.co.jp/fjava/rensai2/wbsrvic05/wbsrvic05_3.html
上記URLにおいて、axisのセッションについて書かれていますが、
このようにクライアントに、

service.setMaintainSession(true);

のコードを埋め込むだけで、認証が行われるのでしょうか?
(ClientにCookieを受け取ったり、維持するようなハンドリングは不要なのか?)

また、これはサーバクライアント共にaxisを用いた場合にのみ保障されるもので、
例えサーバ側からCookieが発行されていたとしても、サーバがaxis以外のエンジ
ンを使用している場合には動作しないものなのでしょうか?


参考情報ありましたら、ご提供ください。

--
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: 

Re: cookie認証方法

2006-08-28 スレッド表示 Toshiyuki Kimura

To: bodyさん

 はじめまして。
 木村と申します。

 下記本文中で「Cookie認証」という言葉が用いられている
のですが、何を意図しているのかよく分かりません。

 具体的にどのようなことを実現したいのかにつてもう少し
詳しく教えていただくことはできますでしょうか?

よろしくお願いします。
---
Toshi [EMAIL PROTECTED]

On Sat, 26 Aug 2006, hayakawa wrote:


はじめまして。bodyと申します。

axis1.1を用いたWebサービスにおいて、Cookie認証の情報を探しています。

http://www.atmarkit.co.jp/fjava/rensai2/wbsrvic05/wbsrvic05_3.html
上記URLにおいて、axisのセッションについて書かれていますが、
このようにクライアントに、

service.setMaintainSession(true);

のコードを埋め込むだけで、認証が行われるのでしょうか?
(ClientにCookieを受け取ったり、維持するようなハンドリングは不要なのか?)

また、これはサーバクライアント共にaxisを用いた場合にのみ保障されるもので、
例えサーバ側からCookieが発行されていたとしても、サーバがaxis以外のエンジ
ンを使用している場合には動作しないものなのでしょうか?


参考情報ありましたら、ご提供ください。

--
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]