Gmailにつなぐための実証コードを書いてみる - にっちもさっちも行かない編 [プログラミング]
書いてみるっつても、今回も下記のコードをパクるので、実質コピペ＆手直し程度。
http://x68000.q-e-d.net/~68user/net/ssl-1.html
ここに載っているのは、HTTPSなのだが、HTTPをラップしてるだけだと思うので、同様にPOP3をラップしてあげればいいだけなのでしょう。
Xcodeでやると、逆に面倒くさくなりそうなので、gccでやりたいと思います。その前に、OpenSSLをMacPortsで入れないとね。はじめに、元ネタのコンパイルが通るようにしてみる。
sudo port install openssl
gcc https-client.c -o https-client
このままだと、ライブラリにパスが通らないみたい。そりゃそうだ。ええと、
ってやると、
ld: warning: in /opt/local/lib/libssl.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
って出てきてしまう。ファイルはサポートされてないファイルフォーマット（i386でリンクされているのではない）らしい。いまいち意味が分からない。
portでgccの最新安定板で入れてみる。Macのgccは色々手が入っちゃってるから、なるべくオリジナルなgccを使った方が、イレギュラーな知識を知らなくて済む。gcc45はやたらコンパイルに時間がかかる。
を、しつこく色々パラメータ変えてたら、コンパイル通っちゃった。
i386じゃなかったら、64bitでしょと、適当にパラメータの正式な与え方も、ろくすっぽ調べずに入れたら通った。まぁ動くかどうか分からないけど、コンパイルが通ったのはうれしい。
ありゃ、まだgccのコンパイル終わんないよ。めちゃくちゃCPUリソース食いまくりなんですけど。放っておけば終わるのでしょうが、CPUが遅いと何をするにも問題が発生しそう。それにコンパイラのコンパイルなんて途中でやめたら問題が起きそうな気がするしなぁ。30分くらい休みの時間にします。やれやれ（と、ノルウェイの森のワタナベトオルみたいにつぶやいてみる）。
うわ、食事終えたのにまだやってるよ…。どんだけの事やってるんだか。こういうときはコンパイル済みのリポジトリの有り難みがよく分かります。ちょっと野暮用で外に行く事にする。にしても、jc1っていうコマンドだけで200%近くいっちゃってるよ。とりあえず、XcodeとWiresharkを閉じてメモリを空かせないと、帰ってきても終わらなさそう。ここまで高負荷なのは不憫な感じすらする。ちょっと前はCore2Duoってのは、それなりに速かったんだけどなぁ。
ええと、3k円ドブに捨ててきたら終わってたので、上記のリンクのソースが適当なSSLが使われているページをGETしてみようと思う。このままだと、変なURLだから、埋め込み文字列をhttps://encrypted.google.com/に変えてみる。あ、引数で入れれば大丈夫な仕組みになってたわ。あと、googleのページもβ版だし、やっぱり本格運用しているところにします。
というか、検索結果なんて、どうでもいい気がするんだけどね。極秘に探したいページなんて普通に考えるとないし、極秘だったらGoogleにすら見せたくないはずだしね（Googleだからこそ、か？）。Gmailでメールの中身をGoogleが思う様クローリングかけてるから、何を今更って気もするけどね。
char *host = "www.so-net.ne.jp";
char *path = "/webmail/pc/login/auth.do";
./https-clientで実行。をぉ、実行したそばから、なんか文字化けした。その後は全然文字化けせずに、普通にHTMLが戻ってきましたよん。元々のソースの文字コードを調べてみたら、EUCでした。そりゃぁ文字化けもするよな、昨今のUNIXってみんなUTF-8なんだろうし。
曲がりなりにも、用は足せたので、元ネタの検証は良しとします。httpsの試験じゃないし深入りしない。
先のhttpsのコードを元にして、文字コードをUTF-8に変換して、Gmailにつなげるようにする。ソースは後ほど上げるけど、主に変えた部分は下記。
・つなぎ先はpop.gmail.com
・SSLv23_client_method()じゃなくて、TLSv1_client_method()を使った。
・HTTPみたいに、一回のみのやり取りじゃないので、POP3の対話的な受け答えにする。
・POP3を単にSSLでラップしていると思って話を進める。
送るコマンドは
USER ユーザ名\r\n
PASS パスワード\r\n
list\r\n
quit\r\n
って感じで、まんまPOP3で。独自拡張してたら怒る。結局、printf()デバッグをしたんだけど、怒らざるを得ない結果でした。
うぁ、ダメダメだ。ログイン的な事もできてない。POP3とは異なるプロトコルになってる。手間かけさせんなよな、Googleさんよぉ。IPの後ろのホニャホニャ書いてあるのを使わなくちゃいけないとか、そういうのかもね。なんだかGpopとか言ってるけど、面倒くさくてたまらないな。既存のレイヤに影響を与えない仕組みがTLSなのに、わざわざ変えちゃダメだろ、これ。
類推でできる次元じゃなくなったので、ググってどうにかする（はじめからそうしろよ）。っていうか、きちんとしたRFCのプロトコルとかじゃなかったら怒るよ、本気で。本気と書いてマジで。どっちかというと、自虐と書いてマゾか？ 無駄な独自規格ってMicrosoftと何も変わらないじゃん。
ググってて気がついた。もしかしたら、サーバ認証とかが必要？
元のhttpsなソースのサイトの次のページで、
http://x68000.q-e-d.net/~68user/net/ssl-2.html
＞前項のクライアント https-client.c は、不完全です。
って書いてある〜。root CAの証明書とかが必要らしい。上のページからダウンロードしてきたけど、期限が切れてるなぁ。さてどうやって手に入れるかな？ 普通にブラウザのキャッシュとかに置いてありそう。というか、それを使ったやり方がいまいち分からない。新しいソースを読んで、分からないところをググって、理解するしかないか。
次にあったページとの差分を見つつ、必要そうなところを加えていく。なんて原始的なんだろう。本来なら、プロトコル仕様を見て、ほぼスクラッチでやらなくてはならないところが、以前動作確認されているであろうコードがあるだけマシかもしれない。というか、なかったらやろうと思わないよ、正直。
証明書だけでどうにかなるならいいけど、GoogleがPOPをいじってる可能性は大きいので、そこのところも勘案して進んでいこう。なんか打開できそうなので、今回はここで終わり。疲れた。
あー、プロトコルとか調べるのマジ勘弁。仕事じゃなかったらやりたくない作業。まだ3GPPみたいに出所がはっきり分かってればいいけど、ってやっぱRFCか、こういうのは。英語読みたくないなぁ。機械翻訳はもっと読みたくない。中途半端に時間かければ読めるから、また問題なんだよな。それに全く辞書なしで読めるほどテクニカルタームに精通しているわけじゃないし、普通の受験英語もほぼ忘れてるしね（特に語彙）。
http://x68000.q-e-d.net/~68user/net/ssl-1.html
ここに載っているのは、HTTPSなのだが、HTTPをラップしてるだけだと思うので、同様にPOP3をラップしてあげればいいだけなのでしょう。
Xcodeでやると、逆に面倒くさくなりそうなので、gccでやりたいと思います。その前に、OpenSSLをMacPortsで入れないとね。はじめに、元ネタのコンパイルが通るようにしてみる。
sudo port install openssl
gcc https-client.c -o https-client
このままだと、ライブラリにパスが通らないみたい。そりゃそうだ。ええと、
gcc -L/opt/local/lib -I/opt/local/include -lssl -o https-client https-client.c
ってやると、
ld: warning: in /opt/local/lib/libssl.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
って出てきてしまう。ファイルはサポートされてないファイルフォーマット（i386でリンクされているのではない）らしい。いまいち意味が分からない。
portでgccの最新安定板で入れてみる。Macのgccは色々手が入っちゃってるから、なるべくオリジナルなgccを使った方が、イレギュラーな知識を知らなくて済む。gcc45はやたらコンパイルに時間がかかる。
を、しつこく色々パラメータ変えてたら、コンパイル通っちゃった。
gcc -L/opt/local/lib -I/opt/local/include -lssl -lcrypto -arch x86_64 -o https-client https-client.c
i386じゃなかったら、64bitでしょと、適当にパラメータの正式な与え方も、ろくすっぽ調べずに入れたら通った。まぁ動くかどうか分からないけど、コンパイルが通ったのはうれしい。
ありゃ、まだgccのコンパイル終わんないよ。めちゃくちゃCPUリソース食いまくりなんですけど。放っておけば終わるのでしょうが、CPUが遅いと何をするにも問題が発生しそう。それにコンパイラのコンパイルなんて途中でやめたら問題が起きそうな気がするしなぁ。30分くらい休みの時間にします。やれやれ（と、ノルウェイの森のワタナベトオルみたいにつぶやいてみる）。
うわ、食事終えたのにまだやってるよ…。どんだけの事やってるんだか。こういうときはコンパイル済みのリポジトリの有り難みがよく分かります。ちょっと野暮用で外に行く事にする。にしても、jc1っていうコマンドだけで200%近くいっちゃってるよ。とりあえず、XcodeとWiresharkを閉じてメモリを空かせないと、帰ってきても終わらなさそう。ここまで高負荷なのは不憫な感じすらする。ちょっと前はCore2Duoってのは、それなりに速かったんだけどなぁ。
ええと、3k円ドブに捨ててきたら終わってたので、上記のリンクのソースが適当なSSLが使われているページをGETしてみようと思う。このままだと、変なURLだから、埋め込み文字列をhttps://encrypted.google.com/に変えてみる。あ、引数で入れれば大丈夫な仕組みになってたわ。あと、googleのページもβ版だし、やっぱり本格運用しているところにします。
というか、検索結果なんて、どうでもいい気がするんだけどね。極秘に探したいページなんて普通に考えるとないし、極秘だったらGoogleにすら見せたくないはずだしね（Googleだからこそ、か？）。Gmailでメールの中身をGoogleが思う様クローリングかけてるから、何を今更って気もするけどね。
char *host = "www.so-net.ne.jp";
char *path = "/webmail/pc/login/auth.do";
./https-clientで実行。をぉ、実行したそばから、なんか文字化けした。その後は全然文字化けせずに、普通にHTMLが戻ってきましたよん。元々のソースの文字コードを調べてみたら、EUCでした。そりゃぁ文字化けもするよな、昨今のUNIXってみんなUTF-8なんだろうし。
曲がりなりにも、用は足せたので、元ネタの検証は良しとします。httpsの試験じゃないし深入りしない。
先のhttpsのコードを元にして、文字コードをUTF-8に変換して、Gmailにつなげるようにする。ソースは後ほど上げるけど、主に変えた部分は下記。
・つなぎ先はpop.gmail.com
・SSLv23_client_method()じゃなくて、TLSv1_client_method()を使った。
・HTTPみたいに、一回のみのやり取りじゃないので、POP3の対話的な受け答えにする。
・POP3を単にSSLでラップしていると思って話を進める。
送るコマンドは
USER ユーザ名\r\n
PASS パスワード\r\n
list\r\n
quit\r\n
って感じで、まんまPOP3で。独自拡張してたら怒る。結局、printf()デバッグをしたんだけど、怒らざるを得ない結果でした。
----- クライアントからのリクエスト ----- USER ユーザ名 ----- サーバからのレスポンス ----- +OK Gpop ready for requests from 121.108.24.224 k5pf4998ほにゃほにゃ +OK Gpop ready for requests from 121.108.24.224 k5pf4998ほにゃほにゃ +OK send PASS for requests from 121.108.24.224 k5pf4998ほにゃほにゃ +OK send PASS +OK send PASS ----- クライアントからのリクエスト ----- PASS パスワード名 ----- サーバからのレスポンス ----- +OK send PASS ----- クライアントからのリクエスト ----- list ----- サーバからのレスポンス ----- +OK send PASS ----- クライアントからのリクエスト ----- quit ----- サーバからのレスポンス ----- +OK send PASS
うぁ、ダメダメだ。ログイン的な事もできてない。POP3とは異なるプロトコルになってる。手間かけさせんなよな、Googleさんよぉ。IPの後ろのホニャホニャ書いてあるのを使わなくちゃいけないとか、そういうのかもね。なんだかGpopとか言ってるけど、面倒くさくてたまらないな。既存のレイヤに影響を与えない仕組みがTLSなのに、わざわざ変えちゃダメだろ、これ。
類推でできる次元じゃなくなったので、ググってどうにかする（はじめからそうしろよ）。っていうか、きちんとしたRFCのプロトコルとかじゃなかったら怒るよ、本気で。本気と書いてマジで。どっちかというと、自虐と書いてマゾか？ 無駄な独自規格ってMicrosoftと何も変わらないじゃん。
ググってて気がついた。もしかしたら、サーバ認証とかが必要？
元のhttpsなソースのサイトの次のページで、
http://x68000.q-e-d.net/~68user/net/ssl-2.html
＞前項のクライアント https-client.c は、不完全です。
って書いてある〜。root CAの証明書とかが必要らしい。上のページからダウンロードしてきたけど、期限が切れてるなぁ。さてどうやって手に入れるかな？ 普通にブラウザのキャッシュとかに置いてありそう。というか、それを使ったやり方がいまいち分からない。新しいソースを読んで、分からないところをググって、理解するしかないか。
次にあったページとの差分を見つつ、必要そうなところを加えていく。なんて原始的なんだろう。本来なら、プロトコル仕様を見て、ほぼスクラッチでやらなくてはならないところが、以前動作確認されているであろうコードがあるだけマシかもしれない。というか、なかったらやろうと思わないよ、正直。
証明書だけでどうにかなるならいいけど、GoogleがPOPをいじってる可能性は大きいので、そこのところも勘案して進んでいこう。なんか打開できそうなので、今回はここで終わり。疲れた。
あー、プロトコルとか調べるのマジ勘弁。仕事じゃなかったらやりたくない作業。まだ3GPPみたいに出所がはっきり分かってればいいけど、ってやっぱRFCか、こういうのは。英語読みたくないなぁ。機械翻訳はもっと読みたくない。中途半端に時間かければ読めるから、また問題なんだよな。それに全く辞書なしで読めるほどテクニカルタームに精通しているわけじゃないし、普通の受験英語もほぼ忘れてるしね（特に語彙）。
コメント 0