本連載はこの回をもって最終回となります。最後に取り上げるのは，リダイレクトを駆使した外部サイトとのやり取りです。

これまでの記事では，Wicket内部の世界についてのみ取り上げてきました。しかし現代のWebアプリケーションは外部のサイトとうまく連携することが重要になってきています。外部サイトと情報をやりとりするための基本的な手法がURLです。

最終回では「URL」という文字情報をWicketがどのように解釈し，Wicketの世界へと変化させているのかを取り扱います。第8回までと比べて，ずっと地道で，オブジェクト抽象化が弱い部分に触れます。

地道なプログラムですが，「⁠WicketがURLをどのように解釈しているか」を知れば，プログラムできる範囲は大きく広がります。

それでは，OAuth認証手続きを通じて，WicketとURLの関係を見ていきましょう。

外部サイトとの連携の要はURL

Webアプリケーション間の連携に使われる方法はいくつかありますが，Webの基本ともいうべき「URL」を利用した方法は，おそらく広く使われているものです。

Twitterのような，外部サイトとの連携を考慮したWebアプリケーションは，外部サイトが利用できる機能をURLとして公開しています。ある機能を利用したければ，決められたURLに対して決められたリクエストパラメータを付けてアクセスするのです。TwitterはURLとパラメータが適切であれば，該当する機能を実行して結果を返してくれます。

Twitterの機能はすべてURLを介したAPIとして提供されている

Twitterはさまざまな機能をURLを介して提供しています。サンプルプログラムではtwitter4jを利用していたため，Javaのメソッド呼び出しだけでTwitterのさまざまな機能を利用できました。実は，これらの機能はすべて，Twitter APIとしてURLを介して提供されているものです。twitter4jはメソッド呼び出しをURLアクセスに変換してくれているのです。

URLを利用した認証仕様「OAuth」

Twitterが提供するさまざまなAPIの1つに「認証」があります。Twitterは2種類の認証APIをサポートしています。1つは，TwitterのユーザIDとパスワードを使って認証を行う方法です。

しかし，ユーザIDとパスワードを使った認証方式には問題があります。サンプルアプリケーションを，多くのユーザが利用できるWebアプリケーションとして公開した場合を考えてください。ユーザがアプリケーションを使うには，Twitterではなく，あなたのWebアプリケーションに対してTwitterのユーザIDとパスワードを提供しなければいけません。

もちろんあなたは別に他人のパスワードを盗む意図はないでしょうが，ユーザからみればリスクであることに違いはありません。そこで，ユーザにはあくまでTwitterにおいて認証を行ってもらい，あなたのアプリケーションがTwitterから「たしかにこのユーザはTwitterユーザで，あなたがアクセスすることをユーザが許可しました」という情報を受け取る仕組みが必要となりました。OAuthが実現するのは，そのような認証の仕組みです。

OAuthはTwitter独自の機能ではなく，多くのWebアプリケーションが利用している，ユーザ認証の「仕様」です。「⁠認証」という，どのWebアプリケーションでも必要となる機能に，共通のインタフェースを定めるためのものです。Webアプリケーションが仕様に則って機能を提供することではじめて，認証が行えます。

今回使用しているライブラリtwitter4jは，Twitterが提供するOAuth認証機能もサポートしています。そのためJavaのメソッド呼び出しを利用して認証を行うことができます。

この記事ではOAuth自体については取り扱いません。OAuthについてはgihyo.jpでも「ゼロから学ぶOAuth」という記事が公開されています。是非一度目を通してみてください。

OAuth認証のためのアプリケーション登録

これ以降は，twitter4jを使ったTwitterでのOAuth認証に的を絞って説明をしていきます。

OAuthでは，認証サービス提供側（Twitter）とあなたのアプリケーションとの間での連携方法は明確に定められています。twitter4jを使ったOAuth認証では，ConsumerKey, ConsumerSecret，RequestToken，PINコード，AccessTokenの5つの情報を組み合わせて，ユーザの詐称を防ぎつつ認証を行います。

ConsumerKey, ConsumerSecretの取得

Twitterとやりとりするためには，まずはあなたのアプリケーションがTwitterの知らない謎のプログラムではなく，Twitterに登録されたアプリケーションであることを検証する必要があります。そのために使うのが，ConsumerKeyとConsumerSecretです。Twitterサイトとやり取りを行うためには，TwitterからConsumerKey，ConsumerSecretを発行してもらう必要があります。

発行と言っても，難しいことはありません。Twitterの，外部アプリケーション登録用ページに行って，必要事項を記述するだけです。登録ページは次のURLです。

• http://twitter.com/oauth_clients

Twitter画面下部にある「API」リンクをクリックし，さらに「OAuth FAQ」リンクへアクセスすることでも，上記URLのリンクを見つけることができます。

登録ページで入力した項目の大部分は，あなたのアプリケーションがユーザアカウントにアクセスすることをユーザが許可するための認証画面と，ユーザの認証済みアプリケーション一覧に表示されるものです。この内容を見て，ユーザはあなたのアプリケーションに接続許可を与えるかどうかを判断するのです。ユーザが許可を与えてくれさえすれば，あとは自由に，さもユーザがログインしたかのように，Twitterから情報を取得することができます。

ユーザが許可したアプリケーションは，Twitterの「設定」画面にある「Connections」タブで一覧することができます。

また，ユーザはいつでもあなたのアプリケーションへの許可をConnections画面から取り消すことができます。

登録するアプリケーションは別に本格的なアプリケーションである必要はなく，テスト的なものでもかまいません。登録はあとで解除することもできます。今回のプログラムを試すためにも，一度登録してみることをお勧めします。

登録が完了すると，http://twitter.com/oauth_clientsに，登録したばかりのアプリケーション・アイコンが表示されます。アイコンをクリックすると，あなたのアプリケーション専用のConsumerKey, ConsumerSecretが掲載されたページが表示されます。あなたのアプリケーション専用のキーがTwitterによって発行されたのです。この2つの値を使うことで，あなたのアプリケーションがTwitterに登録されたものであることを証明できます。

アプリケーションへのキー情報登録

取得したConsumerKeyとConsumerSecretは，作成中のアプリケーション専用のものです。これら2つのキーは一度発行すればそのまま使い続けることができますが，一旦解除して再発行することもできます。変化する可能性があるものですので，アプリケーション・プログラム内部に直接埋め込むのは得策ではありません。今回は，web.xmlの<init-param>要素を利用して，アプリケーションからいつでも取り出せるようにプログラムしました。2つのキー情報はどこにあってもかまいませんが，認証処理時に必要となりますので，取得しやすい場所がいいでしょう。

<filter>
  <filter-name>wicket.wicket-sample</filter-name>
  <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
  <init-param>
    <param-name>applicationClassName</param-name>
    <param-value>jp.gihyo.wicket.WicketApplication</param-value>
  </init-param>
  <init-param>
    <param-name>twitter-consumer-key</param-name>
    <param-value>あなたのConsumerKey</param-value>
  </init-param>
  <init-param>
    <param-name>twitter-consumer-secret</param-name>
    <param-value>あなたのConsumerSecret</param-value>
  </init-param>
</filter>

サンプルアプリケーションでは，web.xmlの<init-param>要素には「あなたのConsumerKey」「⁠あなたのConsumerSecret」という値を登録しています。取得した2つの値で置き換えてください。