*/}これを、移行する方法は、こんなかんじ。メンバ関数に持ってくる・必要に応じて、グローバル変数とかを使ってた部分をクラス変数に変更するなど、修正する・他から呼ぶときは、普段のクラスの呼び出しと同じ。;クラス部分はこんなかんじ。}}呼び出す本体をまとめるとこう。すべて書いてあるので、わからなくなったら目を通すといいと思います。この移行によって、大幅に処理の追加や変更をする場所は(基本的に)ありません。クラス化することによって、全部クラスに集約できるので、グローバル変数で扱うことがなくて、楽になりました。はてな5.2.9と5.2.10がだめくさい。update-channels」を実行するにも、パーミッションの関係で不可。自前でPEAR入れる以外の解決策が(当面は)ありませんでしたので、やることにしました。(※サポートに言えば多分やってくれるとは思うけど)さくらでpearインストール覚書を参考にちょちょいとやってみました。古いのか、一部読み替える必要があります。まではこのままでOK。ちなみに私は.cshrcにこう書いた。pearとしたときに、/home/〜/bin/pearと出ればOKです。11.の前に、update-channelをするのですが、そのままだとエラーになるんで、config変えます。XML_Parserこれで問題なくいくようです。(1)TweettwitterでOAuthを使う方法(その2:前回の続き〜APIにアクセスしてみる)前回のおはなし。twitterでOAuthを使う方法(その1:認証まで)認証までの手順を説明しました。前回の説明で、署名に関して説明不足の点がありました。・GETメソッドのquery_stringすべてを、「&」で結んだあとに、一括してurlencodeします。これら3つに関して、『全部を』アルファベット順にソートしてから、&でつなげます。三者間に優先順位・区別はなく、すべてを通してのソートです。・GETのquery_string「d=24&f=33&h=66」こういうふうに与えられてる場合、a=60&b=11&c=30&d=24&e=50&f=33&g=40&h=66というふうになります。面倒なんで、コードで書くとこんなかんじです。stringに埋める・POSTの送信データに埋めるの3つの方法があります。twitterの場合、残念ながら(リバースプロキシの関係?)、リクエストヘッダに埋める方法には対応しておりません(503エラーがかえってきます。ついでに、くじらさんが拝めます)。従って、GET/POSTの(フォーム)データに埋めるしかありません。与えるパラメータは以下の通りです。・APIに与えるパラメータ署名の作成ですが、例によって、署名以外のデータを対象にします。つないだものを使います。リクエストを投げる先は、これまで通りのAPIのURIです。○あと、気がついたこと。認証の許可と解除を繰り返したせいかはわかりませんが。気のせいか、updateのAPIがやたら不安定です。Authorized』を返してきます。署名が一致しないようで。(0)TweettwitterでOAuthを使う方法(その1:認証まで)OAuthって結構難しいと思われてるようですが、難しいというよりは、『ややこしい』です(苦笑)そんなわけで。手順毎に順番に説明をしようと思います。説明の図(手書きでごめんなさい)追加しました。provider)・・・サービスを提供しているところ。この場合、twitter。・ユーザ(user)・・・サービスプロバイダに登録していて、そのサービスを利用している人。・コンシューマ(consumer)・・・サービスを提供しているところに、ユーザにかわって、そのサービスに対してアクセスする第三者。サードパーティ、とでも言うべきでしょうか。要は、この記事を見て「何か作ってみたい」という、あなたです。Token/Secretの取得まずは、アプリケーションの登録作業です。ある程度かたちになってからのほうが望ましいですが、ぶっちゃけ適当でかまいません(笑)OAuthの仕様書では、この取得に関するプロトコルは定めておりません。サービスプロバイダとコンシューマの間で直接やりとりしてね、ってことです。»」とあるので、こいつをクリック!と行けば、登録画面に行けます。くじらさんが出ますが、そのときはリロードしてください。登録に必要な項目は以下の通りです。・・・アプリケーションのアイコンです。アイコンはわりと重要です。・・・アプリケーション名称です。・・・アプリケーションについての説明。長く書けないので簡潔に。アプリケーションのサイト。説明してるサイト、もしくはホームを書きます。自分の名前(ニックネーム)でいいでしょう。作ってる組織のウェブサイト。twitterやってるなら、プロフィールのweb欄と同じで大丈夫。・・・アプリケーションの種類です。・Cient・・・クライアントアプリケーション。・Browser・・・ブラウザベースで使用する場合。webアプリの場合はこちらでOKです。login・・・twitterのidを認証に使用する場合はチェック※twitterのidを使って自分のサービスで認証しないときは、チェックする必要はありません。登録すると、以下の情報がもらえます。)これからが、実際の「ユーザによる認証」のプロセスとなります。●ステップ1:ユーザから、サービスプロバイダへのアクセスを「許可したい」と、コンシューマにリクエストが来るあなたが提供しているサービスに対して、twitterのOAuthを使ってアクセス許可を出したい、というリクエストがきます。(6.1)はい、ここからが本番です。token」を投げます。必要な、固有の情報は以下のとおりです。)※署名に関してはややこしいので、あとで説明します。tokenを投げます。コンシューマキーと署名の情報が合致した場合、サービスプロバイダは以下の情報を返します。OKだった場合これが「true」になるなお、そもそも失敗した場合、HTTPプロトコルの「401」がかえってきますので、成功の可否はこちらで見るべきです。無事に情報がかえってきた場合、コンシューマ(つまり、あなた)は、ユーザに対して、サービスプロバイダの認証用URIに行くように指示(リダイレクト)してください。http://twitter.com/authorize引数には、さきほど返してきた「oauth_token」を入れます。oauth_tokenに「hogehoge1234」とついていた場合、http://twitter.com/authorize?oauth_token=hogehoge1234というURI、となります。これにより、サービスプロバイダ(この場合、twitter)の認証画面へ飛びます。(6.2)認証画面に行くと、「このアプリケーションへの使用許可を出しますか?」という画面になります。ユーザはここで「Accept(許可する)」を選択します。すると、サービスプロバイダはユーザに対して、ステップ2でサービスプロバイダに与えた「oauth_callback」へ、行くように指示します(リダイレクト)。このとき、以下のパラメータを付与します。(6.3)callbackされたリソースは、oauth_token/oauth_verifierを使って、ステップ2のユーザが「本当にリクエストしてきた」ということを証明するため、もう一度、サービスプロバイダへアクセスします。)※署名に関してはややこしいので、あとで説明します。存在することを忘れないでください。このリクエストを投げると、ユーザからのリクエストが正式なものとして扱われ、以下の情報がかえってきます。・・・『正式の』アクセストークン秘密鍵コンシューマは、この2つの情報を保持して、当該ユーザの情報とリンクさせて、サービスプロバイダへのアクセスに使用します。これで、すべての認証プロセスは終了です。厄介な部分がここだと思います。署名の対象となる文字列とりあえず、単刀直入にこんなかんじになります。(?以降は含まない)・リクエストに絡む情報すべて(※1)この3つを「&」で結びます。・GETメソッドのquery_stringすべてを、「&」で結んだあとに、一括してurlencodeします。3つ目の情報においては・「&」「=」はurlencodeの対象になるので、signature_base_stringの中には「&」が2個だけ存在します。)で、処理したあと、base64エンコーディングします(改行コード等は取り除く)これで、署名は完成です。何か間違いがありましたら、気軽にご指摘いただければな、と思います。入れ・・・られなかった!先日、交換しまして。Storeでしたが、すぐに交換していただけました。)・・・そして、無事、入りました。インストールにおいて、特に難しいところはなく。エラーで起動失敗、動作せず。FLV2iTunesが動かない以外は問題なく使えております。Mobile」を選択し、右下の「詳細...」。