URLConnectionのクッキーについて

890 views
Skip to first unread message

Tomoyuki Inagaki

unread,
Jun 24, 2010, 5:24:18 PM6/24/10
to Google-App-Engine-Japan
稲垣と申します。はじめまして。

GAE/JでURLConnectionを使用してあるサイトから情報を取得したいのですが、そのサイトはログイン認証つきのサイトのため、クッキーを
利用できなければ正常にアクセスできません。

ローカル環境で動作させた場合には期待通りの動作をするのですが、サーバにアップするとクッキーが無効になっているような動作になります。

URLConnectionまたはURLFetchサービスでクッキーを利用することはできないのでしょうか?

ご教示願います。よろしくお願いいたします。

Atsushi Kojo

unread,
Jun 25, 2010, 1:54:36 AM6/25/10
to google-app-engine-japan
対象のサイトはログイン後に強制的にリダイレクトするサイトではないでしょうか?

私は強制リダイレクトされるログイン認証付サイトから情報を得るアプリを動かしていますが
リダイレクトを拒否しないとクッキーを管理する間がないのでログインしていない状態になります。

HttpURLConnectionならsetInstanceFollowRedirects(false)で拒否できるんじゃないでしょうか?
(私はPythonで書いていますので確証はありません)
ただ、ローカル環境でうまくいくということなので外しているかもしれません。
あくまで参考までに。

ちなみにクッキーの管理はいろいろライブラリあるようですが私はクッキー文字列を直に扱っています。


2010年6月25日6:24 Tomoyuki Inagaki <tomo...@gol.com>:

> --
> このメールは Google グループのグループ「Google-App-Engine-Japan」の登録者に送られています。
> このグループに投稿するには、google-app-...@googlegroups.com にメールを送信してください。
> このグループから退会するには、google-app-engine...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/google-app-engine-japan?hl=ja からこのグループにアクセスしてください。
>
>

Yasuhiro Takagi

unread,
Jun 25, 2010, 9:17:32 AM6/25/10
to google-app-...@googlegroups.com
高城と申します。はじめまして。

状況から察するに、私も同じ状況になりました。
ローカルではOK,デプロイするとNG、という状況です。

どうやら、稲垣さんの予想のようにサーバではリダイレクトの際には
クッキーがリセット?されているようです。
(たしか5回までリダイレクトOKと書かれていたと思うのですが
 クッキーは対象外?)

私はしょうがないので、リダイレクトを自分で実装することで回避しました。

私の使用方法はたぶん稲垣さんのやりたいことと異なる(私は
proxy的な使い方をしていた)と思いますので、ひょっとしたら
外しているかもしれませんが、下記に代替案を書いてみます。

(Kojoさんが書かれているように)リダイレクトをしない状態にして
まずページを読み込みます。
ページの読み込み結果のレスポンスコードを調べて HTTP_MOVED_TEMPなら
Locationヘッダでリダイレクト先を取得、クッキーを取得、
次のアクセスのために設定した上でそのリダイレクト先を読み込む、
というのではいかがでしょう。
(わかりにくい表現でごめんなさい)

リダイレクトを一こま一こま自分で進めるイメージです。

参考になれば幸いです。

※これって、仕様なんでしょうか?バグなんでしょうか?
 賢人の方のご意見ございましたら、ぜひぜひ。


2010年6月25日6:24 Tomoyuki Inagaki <tomo...@gol.com>:
稲垣と申します。はじめまして。

Takashi MATSUO

unread,
Jun 25, 2010, 4:28:40 PM6/25/10
to google-app-...@googlegroups.com
松尾です。

Java 版のドキュメントには記述が見当たりませんでしたが、Python 版のドキュメント
http://code.google.com/intl/en/appengine/docs/python/urlfetch/fetchfunction.html

には、Warning として Redirect を自動処理した場合にはクッキーがセットされないと書いてありますね。
是非はともかく仕様なのではないでしょうか。

--
Takashi Matsuo
matsuo....@gmail.com
Kay's daddy

2010/6/25 Yasuhiro Takagi <tsu...@gmail.com>:

Tomoyuki Inagaki

unread,
Jun 25, 2010, 9:28:43 PM6/25/10
to Google-App-Engine-Japan
こんにちは。稲垣です。

Kojoさん、高城さん、松尾さん、ご返信ありがとうございます。

まず、リダイレクトを無効にして自身でリダイレクトを実装するだけでは
結果は変わりませんでした。ローカルではOKで、デプロイするとNGです。


該当サイトの正常なシーケンスとしては以下のとおりです。

1. ログインページのGET時のレスポンスでSet-Cookieされる。
2. ログインPOST時にクッキーを送信
3. 302リダイレクト応答を受信
4. リダイレクト先も同じホストなので同じクッキーを送信
5. リダイレクト先のページ受信

ローカルではWireSharkで確認したところ、クッキーのハンドリングは自動
的にされているようで、自前でクッキーヘッダーの取得・設定を行う必要は
ないように見えます。

デプロイ先でレスポンスヘッダーをログに吐き出して確認してみたところ、
上記3.のフェーズでリダイレクト応答を受信せずに、1.のログインページが
返って来ています。しかもSet-Cookieヘッダー付きで。

ですので、GAE/JのURLConnectionではデプロイ先ではクッキーのハンドリング
は自動的にはされないのかなと推測しました。(URLFetchサービスはまだ試し
ていませんが、同じかな?)


高城さんはクッキーのハンドリングも自前で実装されているのでしょうか?

Yasuhiro Takagi

unread,
Jun 26, 2010, 12:48:02 AM6/26/10
to google-app-...@googlegroups.com
高城です。

そうですか、うまくいきませんでしたか・・・

一点確認です。
”正常なシーケンス”はご自分で実装されたものですか?

もしそうではないとすると3.と4.の間で自前で
クッキーをセットすればうまく行くのではないかと。
(3.でのリダイレクト応答の飛び先にクッキーを再度セット
 してアクセスする)

これでダメなら私にはお手上げそうです。
ごめんなさい。

===
私は、稲垣さんと異なる目的(アクセス方法)ではありましたが、
クッキーは自前で処理しました。

※私の場合はちょっと変態的?な使い方ですので、
 詳細は割愛させてください(結構説明しづらいので)


2010年6月26日10:28 Tomoyuki Inagaki <tomo...@gol.com>:

--

Tomoyuki Inagaki

unread,
Jun 26, 2010, 1:22:16 AM6/26/10
to Google-App-Engine-Japan
稲垣です。こんにちは。

”正常なシーケンス”は自分で実装したものではなく、
ローカル環境でURLConnectionが自動的に処理しているものを
WireShark上で確認したものです。

で、NG時には1.と3.の間でクッキーが消失している(たぶん、
2.でクッキーを送っていないんだと思います。)ので、
リダイレクトは関係なく、デプロイ環境上ではそもそも
Java版ではクッキーに対応できていないのではないかと推測
しています。

高城さんはJava版でうまく行っているのでしょうか?
それともPython版でしょうか?

Java版でクッキーの必要なサイトからの情報取得に成功して
いる方って、いらっしゃいますでしょうか?

その場合、やはりクッキーは自前で処理しているのでしょうか?

すみません。質問ばかりで。m(__)m

P.S.
高城さんの”変態的?な使い方”って何だか気になる。。。(^^;

Yasuhiro Takagi

unread,
Jun 26, 2010, 2:04:50 AM6/26/10
to google-app-...@googlegroups.com
高城です。

私もJavaです。

もう一点確認です。
ローカルでの正常なシーケンスでは
1.、2.でそれぞれurlconnectionを使われていますか?

では下記実装ではいかがでしょうか。

0. setInstanceFollowRedirects(false) で
 自動リダイレクトはoffに。
1. ログインページのGET時のレスポンスでSet-Cookieされる。
 →ここでレスポンスから
  getHeaderField("Set-Cookie")で明示的にcookieをもらう。
2. ログインPOST時にクッキーを送信
   →POSTの際にaddRequestProperty("Cookie", クッキーの中味)を
  行って、自分でPOST
3. 302リダイレクト応答を受信
 →ここで自動リダイレクトをオフにしているので、
  リダイレクト応答が帰ってきた状態でgetHeaderField("Location")を
  つかってリダイレクト先を得る。
   (ここでさらにcookieをもらってたとしたらさらにそいつも
 もらう。ってこれはあり得るのかな?)
4. リダイレクト先も同じホストなので同じクッキーを送信
 →3で得たリダイレクト先をurlconnectionにセットして、
  さっきもらったcookieの中味をaddRequestPropertyで再度
  セット。
  (3.でさらにcookieをもらってたらそいつもセット)
5. リダイレクト先のページ受信
 →これでうまくいかないかなぁ。いや、行ってくれ…(→自分)

コードのイメージをお知らせできればよいのですが、
変態的使い方&汚い実装のおかげで
お見せできるようなものでもなく・・・

===
変態的、というのは
携帯でしかアクセスできないサイトへのproxyを
作ったのです。
そのproxyの接続先でリダイレクトが入ったとき、
GAEがcookieを忘れる、という状態に
陥りました。
このときはGAEでのリダイレクトをさせずに、
アクセスしたPCにクッキー付きでリダイレクトをさせて
乗り切りました。 
で、GAEがもらったクッキーをアクセスしたPCにさらに
喰わせる、ということをしました。

※分かりにくい説明ですね・・・。ごめんなさい。



2010年6月26日14:22 Tomoyuki Inagaki <tomo...@gol.com>:

--

Atsushi Kojo

unread,
Jun 26, 2010, 2:05:48 AM6/26/10
to google-app-...@googlegroups.com
前回挨拶なしで申し訳有りませんでした。
古城と言います。宜しくお願いします。

私の場合は強制リダイレクトを無効にして
2のログインPOST後に受け取るクッキーを3でセットしています。
普通ログイン前と後でクッキー内容は変わるのでそうしないと意味がないと思います。

あと憶測ですがJavaかPythonかは関係ない気がします。
ご存知の通りデプロイ後はGAEがHTTPクライアントになるので
GAEがクッキーを保持する仕組みを持っていない限り無理だと思だと思います。

自分の場合はそう解釈したので自前でクッキーを上記のように処理しました。
あくまで個人的な理解です。認識違いなどあったら申し訳ありません。

2010年6月26日14:22 Tomoyuki Inagaki <tomo...@gol.com>:

Joe

unread,
Jun 26, 2010, 2:11:39 AM6/26/10
to Google-App-Engine-Japan
1分の差で被ってしまいました(苦笑)すいません。
私の実装も高城さんのイメージそのまんまです。
私の場合3で更に貰ったクッキーを返したりなんかもしちゃってます。
処理に無駄はあるかもしれませんが確実にログイン後のページにアクセスできます。
> 2010年6月26日14:22 Tomoyuki Inagaki <tomot...@gol.com>:
>
>
>
> > 稲垣です。こんにちは。
>
> > ”正常なシーケンス”は自分で実装したものではなく、
> > ローカル環境でURLConnectionが自動的に処理しているものを
> > WireShark上で確認したものです。
>
> > で、NG時には1.と3.の間でクッキーが消失している(たぶん、
> > 2.でクッキーを送っていないんだと思います。)ので、
> > リダイレクトは関係なく、デプロイ環境上ではそもそも
> > Java版ではクッキーに対応できていないのではないかと推測
> > しています。
>
> > 高城さんはJava版でうまく行っているのでしょうか?
> > それともPython版でしょうか?
>
> > Java版でクッキーの必要なサイトからの情報取得に成功して
> > いる方って、いらっしゃいますでしょうか?
>
> > その場合、やはりクッキーは自前で処理しているのでしょうか?
>
> > すみません。質問ばかりで。m(__)m
>
> > P.S.
> > 高城さんの”変態的?な使い方”って何だか気になる。。。(^^;
>
> > --
> > このメールは Google グループのグループ「Google-App-Engine-Japan」の登録者に送られています。
> > このグループに投稿するには、google-app-...@googlegroups.com にメールを送信してください。
> > このグループから退会するには、google-app-engine...@googlegroups.com<google- app-engine-japan%2Bunsu...@googlegroups.com>にメールを送信してください。
> > 詳細については、http://groups.google.com/group/google-app-engine-japan?hl=jaからこのグループにアクセスしてください。

Tomoyuki Inagaki

unread,
Jun 26, 2010, 3:54:40 AM6/26/10
to Google-App-Engine-Japan
高城さん、こんにちは。

ありがとうございます。

教えて頂いたように自前でクッキーを取得・設定することで、
デプロイ先の環境でも正常に情報を取得することができるよう
になりました。

と、思ったら、うまく行ったり、行かなかったり。。。

うまく行くケースと、駄目なケースで何が違うのか調査中です。

たぶん、これはGAEがどうのこうのという問題ではなく、該当
サイトとのシーケンスの問題のような気がします。

何はともあれ、少し光が見えてきました。

ありがとうございました。

Tomoyuki Inagaki

unread,
Jun 26, 2010, 4:05:37 AM6/26/10
to Google-App-Engine-Japan
古城さん、こんにちは。稲垣です。

>あと憶測ですがJavaかPythonかは関係ない気がします。

私はPython版のことをよく知らないのですが、色んなサイトを検索して
回った結果、「Pythonではリダイレクト時にクッキーがリセットされる
けど、リダイレクトされなければクッキーは自動的にハンドリングされ
る」という動作をするのかなと思ったのですが、外してますでしょうか?

私が動作検証した限りではJava版では「リダイレクトされなくてもクッキー
は自動的にはハンドリングされない(ローカル環境では自動ハンドリング
される)」という動作に見えます。

たぶん、GAEのAPIはPython版とJava版では動作は異なるのではないかと
思っているのですが。。。

私も、あくまで個人的な理解であり、認識違いなどがありましたら
申し訳ありません。

Atsushi Kojo

unread,
Jun 26, 2010, 4:47:22 AM6/26/10
to google-app-...@googlegroups.com
古城です。

> 私はPython版のことをよく知らないのですが、色んなサイトを検索して
> 回った結果、「Pythonではリダイレクト時にクッキーがリセットされる
> けど、リダイレクトされなければクッキーは自動的にハンドリングされ
> る」という動作をするのかなと思ったのですが、外してますでしょうか?

そうなんですか。
私がハマった当時調査した結果と実際に試した結果Pythonのクッキーを
ハンドリングを使用した場合、一切うまくいかなかったので
GAEがクッキーを保持できない仕様なのだと諦めてました。
ちょうど稲垣さんがJava版に対して思われてるのと同じ解釈だと思います。

もしかしたら私がクッキーに関して根本的に勘違いしているかもしれません。
私の勘違いなら私にも嬉しいことなのでどなたかGAEでJavaやPythonの
クッキーハンドリングライブラリを使用した例があったら教えていただきたいです。
宜しくお願いします。


2010年6月26日17:05 Tomoyuki Inagaki <tomo...@gol.com>:

Yasuhiro Takagi

unread,
Jun 26, 2010, 10:55:37 PM6/26/10
to google-app-...@googlegroups.com
高城です。

少しよい方向にいったようですが、
まだ完全解決、ではないとのこと。

うまく解決されることを祈っております。

ローカルとデプロイ後の動きが
異なるときはあせりますよね。


2010年6月26日16:54 Tomoyuki Inagaki <tomo...@gol.com>:

--
Reply all
Reply to author
Forward
0 new messages