まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:url

Tips 的な小ネタです。

Node.js + Express によるウェブアプリケーションコードの中で、何らかの URL への GET リクエスト(POST とかでもいいですが、処理内容は GET の時と同じなので GET で考えることにします)を受けて処理している時の、アクセス時のフル URL をサーバー側で知る方法です。 なお、ここでの「フル URL 」とは、プロトコル+ホスト名+(デフォルトと異なる場合は)ポート番号+アクセスパス+実行時のURLパラメータ のこととします。

この値はクライアント側の JavaScript を使えば windows.location オブジェクトを参照することで取得できます。ただこちらはあまり意味がないというか、アクセスしたユーザーは自分のブラウザのアドレス欄を見れば URL を確認できるのでわざわざ別途必要になるケースが珍しいはずです。このクライアントサイドでの話ではなく、サーバーサイドの処理内で知る方法、という意味です。

結論としては以下のようなコードで取得することが可能です:
//.  app.js
var express = require( 'express' ),
    app = express();

app.get( '/*', function( req, res ){
  res.contentType( 'text/plain; charset=utf-8' );
  var url = req.protocol + '://' + req.get( 'host' ) + req.originalUrl;
  res.write( url );
  res.end();
});

var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );

まずルーティングのパス定義部分を '/*' としています。これによってルートパス以下のすべてのパスへの GET リクエストをこのハンドラが受け持つ、と宣言します。

肝心のフル URL ですが、このハンドラ実行時のパラメーター: req(リクエストオブジェクト)を使って、以下のように求めることができます:
 var url = req.protocol + '://' + req.get( 'host' ) + req.originalUrl;

req.protocol にはプロトコル("http" または "https")、req.get( 'host' ) でポート番号まで含めたアクセス時のホスト名、そして req.originalUrl にはアクセス時のフルパスが URL パラメータまで含めた形で取得できます。これらをつなぎ合わせることでアクセス時のフル URL が取得できるので、これをレスポンスで返す、という処理をしています。

試しに実行していくつかの URL パターンでアクセスしてみた所、以下のようにいずれも期待通りの結果になりました:
(http://localhost:8080/)
2021062301


(http://localhost:8080/abc/hello?x=100)
2021062302


(http://localhost:8080/abc/hello?x=100&y=200)
2021062303


1つの環境で複数のサーバー名を持って稼働するサーバーの場合に、「何というホスト名でアクセスされているのか」をサーバー側からも知ることができる、という情報でした。

なおこのアプリケーションのソースコードはこちらで公開しています:
https://github.com/dotnsf/access_url


どれだけ需要があるかわかりませんが、docker イメージ(dotnsf/access-url)の形で以下からも公開しています:
https://hub.docker.com/r/dotnsf/access_url


利用可能な Kubernetes クラスタ環境(と接続設定などが済んだ kubectl コマンド)があれば、以下の手順でコマンドを実行することで Deployment と(spec.type = "NodePort" の) Service を作成できます:
$ git clone https://github.com/dotnsf/access_url

$ cd access_url

$ kubectl -f yaml/app_deployment.yaml

IBM Cloud の無料版 IKS(IBM Kubernetes Services) で、上記コマンドを実行して作成したアプリケーションにアクセスした時の様子が以下になります。アクセスした URL が正しくサーバーサイドで取得できている様子が確認できます:
2021062401

 
最後に余談を。上述のクライアントサイド JavaScript による(window.location オブジェクトを用いた)取得方法との取得できる情報の違いについて補足します。

クライアントサイドで取得する場合、サーバーサイドで取得できない情報が1つ取得できます。それが「ハッシュ」と呼ばれる情報で例えば、
 http://xxx.xxx.xxx.xxx/abc/hello?x=1&y=2#here
という URL アドレスの最後の "#here" 部分の情報です。

この情報はクライアントサイドであれば window.location.search を参照することで取得することが可能ですが、サーバーサイドでは取得する方法がありません。ただハッシュ情報はクライアントサイドで(HTML 内の特定位置を参照するなど)利用するためのものであって、サーバーサイドで生成する情報としてはハッシュによる差異はありません。要はサーバーサイドでは意味のない情報であるためサーバー側では取得できなくなっている、ものと思われます。



(注 このブログを書いた時点では 2021/02/12 だった更新期限は 2021/05/25 に変更されました)


IBM Watson サービスのエンドポイント URL が更新され、2021年2月12日5月26日に旧URLが廃止される予定です:
IBM Watsonサービスのネットワーク分離機能拡張のためのIAMの更新


IBM Watson の各種サービス API を(以前から)使っていて、そのエンドポイント URL のホスト部分が *.watsonplatform.net というパターンになっている場合にアプリケーションが正しく動作しなくなるなどの影響を受けます。その場合は月の旧URL廃止前に後述の作業を行って、新しい URL に更新する必要があります。

以下、Watson NLC(Natural Language Classifier) を例に対応手順を含めて個人でまとめたので紹介します。NLC 以外のサービスでも概ね同様ですので参考にしてください。また詳しくは後述のリンク先も参照ください。


【現在使っている Watson API のエンドポイント URL を確認】
まず今回の作業は例えば Watson Assistant の画面を使って作業しているだけなど、外部アプリケーションから API を使って呼び出したりしていない場合は関係ありません。apiKey を指定してプログラミングで Watson API を外部から呼び出す形で利用しているケースが対象となります。

現在 Watson API を使ってアプリケーションを動かしている場合、まずはその API のエンドポイントが旧 URL を使っているのか新 URL を使っているのかを確認します(新 URL であれば後述の作業は不要です)。

例えば Watson NLC を使ったアプリケーションであれば、IBM Cloud にログインし、リソース画面のサービス一覧から利用している該当サービス(Watson NLC サービス)を選択します:
2020103001


選択したサービスの概要が表示される画面内に API Key と URL が表示されています(※)。この URL という部分に着目してください:
2020103002


上図の例では
  https://gateway-tok.watsonplatform.net/natural-language-classifier/api
と表示されている部分です。ここがこのように watsonplatform.net という文字を含んでいる場合は旧 URL を利用しています。一方、ここが api.*****.*****.watson.cloud.ibm.com というパターンになっている場合は新 URL を使っています。

※API Key と URL は「サービス資格情報」メニューからも確認できます。

ここで新 URL を使っていることが確認できた場合は後述の作業は不要です。旧 URL を使っている場合は続けて対処が必要です。


【変更先の Watson API 新エンドポイント URL を確認】
上述の作業で旧 URL を使っているアプリケーションは利用エンドポイント URL を新 URL に変更する必要があります。

まず新しい URL を確認するために新しいサービス資格情報を作成する必要があります。上述の作業に続けて画面左のメニューから「サービス資格情報(Service credentials)」を選択し、新しく資格情報を追加して作成します(その際に現在使っている資格情報と同じロールを指定して作成します):
2020103003


追加された資格情報の名前の左側にある小さな矢印をクリックして展開します:
2020103004


Watson サービスの種類によっても異なりますが、概ね以下のような JSON フォーマットの情報が含まれた内容になっています(一部 ***** でマスクしています):
{
  "apikey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "iam_apikey_description": "Auto-generated for key *********************",
  "iam_apikey_name": "Service credentials-1",
  "iam_role_crn": "crn:v1:bluemix:public:iam::::serviceRole:Manager",
  "iam_serviceid_crn": "crn:v1:bluemix:public:iam-identity::********************::serviceid:ServiceId-*************************",
  "url": "https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/*************"
}

この JSON の中の url の値(上図では https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/************* )が新 URL です(実際の文字列パターンは使っている IBM Watson サービスの種類やロケーションによって異なります。また最後の ***** でマスクされている部分はインスタンス ID という個別の文字列となります)。アプリケーション内の旧 URL が使われている部分をこの新 URL に変更する必要があります。 また同時に旧アプリケーションで使われている apiKey も新しく作成したもの(上図の apikey で表示されている値 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX )に書き換える必要があります。


【変更作業】 
ここまでの作業で変更が必要な箇所と、変更後の値がわかりました。アプリケーションのソースコードを編集し、旧 URL (上述例では https://gateway-tok.watsonplatform.net/natural-language-classifier/api)が使われている部分を新 URL (上述例では https://api.jp-tok.natural-language-classifier.watson.cloud.ibm.com/instances/*************)に、また古い apiKey が使われている部分を新しい apiKey の値(上述例では XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)に、それぞれ書き直して保存し、新しいコードで動作確認をしてください。

なお、NLC のように学習が必要な API も再学習の必要はありません。学習済みのデータへそのまま問い合わせが利用できるはずです。


以上、個人でまとめたものですが、背景や詳細な情報はソリューションブログや IBM Cloud Document に記載されています。以下情報も参考にしてください:
IBM Watsonサービスのネットワーク分離機能拡張のためのIAMの更新
Updating endpoint URLs from watsonplatform.net(英語)

サブジェクトが少しわかりにくいと思ったので最初にやりたいことを補足しておきます。

ウェブサービスを公開する際に Basic 認証と呼ばれる認証機能を有効にすることがあります。アクセス時にユーザーIDとパスワードが聞かれ、正しい組み合わせを入力しないと先に進めなくなる、というものです。会員制サービスや、正式公開前のサービスを限られた人だけで使いたい場合、グーグル等の検索エンジンクローラーに見つからない状態で運用したい場合などによく使われます:
thumb_basic


今回やりたかったのは、この Basic 認証を例えば以下の条件で実現するような Node.js アプリケーションを作ることです:
・パス /hello 以下にアクセスした際に Basic 認証が必要
・/hello にアクセスするには URL パラメータ id が必要(つまり GET /hello だけではエラーとなり、GET /hello?id=XXX というフォーマットでアクセスする必要がある)
/hello?id=XXX の時と /hello?id=YYY の時とでは Basic 認証のユーザーIDやパスワードが異なる


最後のが今回の肝となる条件です。パラメータ id の値ごとに Basic 認証のユーザーIDやパスワードが変わり(データベース等に格納されているものを id をキーに取り出して比較するイメージ)、これを Node.js + Express 環境でどのように実現するか、というのが挑戦内容です。


やりたいことが明確になったところで、改めて Node.js + Express 環境で Basic 認証をかける方法をググってみると、basic-auth-connect モジュールを使う方法がメジャーな方法の1つとして見つかります。これは簡単にいうと以下のような感じで Basic 認証をかけるものことができるものです:
var express = require( 'express' ),
    basicAuth = require( 'basic-auth-connect' ),
    app = express();

app.all( '/hello*', basicAuth( function( user, pass ){
  return ( 'username' === user && 'password' === pass );
}));

  :
  :

app.get( '/hello', function( req, res ){
  res.contentType( 'application/json; charset=utf-8' );
  res.write( JSON.stringify( { status: true }, 2, null ) );
  res.end();
});

  :
  :

GET /hello リクエストに対しては単に { status: true } という JSON を返すだけの定義がされていますが、その前に Basic 認証を有効にする部分が記述されています。この例では(/hello に何らかの URL パラメータが付属する場合も含めた) /hello* というパスに GET リクエストが行われた場合に Basic 認証が必要になり、ユーザーID 'username' 、パスワード 'password' が入力された場合のみ true(認証成功)で実際の GET /hello の処理が行われ、それ以外の場合は false(認証失敗)という扱いとなって再度入力が求められたり、何度か間違えると認証エラー扱いとなる、というものです。とても便利で、よく使っています。


さて、今回は上述の条件で Basic 認証を有効にする必要があり、少し異なる処理が必要です。正しいユーザーIDとパスワードは URL パラメータ id によって変わるのですが、この URL パラメータは req オブジェクから取り出す必要があり、今の形のままでは(認証判断時に req オブジェクトが取得できないので)取得が難しそうです。自分もこの basic-auth-connect モジュールを使う前提で実装を考えていたので詰まってしまいました。。

結論としては basic-auth-connect モジュールを使うことを諦め、自分で認証判断してエラー時にエラーコードを返す、という地味な処理に切り替えて実装できました:
var express = require( 'express' ),
    //basicAuth = require( 'basic-auth-connect' ),  //. basic-auth-connect は使わない
    app = express();

//. パラメータ id 毎に必要なユーザーIDとパスワード(本当はデータベース等から取得するイメージ)
var db = {
  "000" : { user: 'a', pass: 'x' },
  "001" : { user: 'b', pass: 'y' },
  "002" : { user: 'c', pass: 'z' }
};

/* URL パラメータ毎に認証情報を変えたい */
app.use( function( req, res, next ){
  //. hello* へのリクエスト時かどうかを判断
  var originalUrl = req.originalUrl;
  if( originalUrl.startsWith( '/hello' ) ){
    //. URL パラメータ ID を取り出す
    var id = req.query.id;
    //. 指定された ID のユーザー ID とパスワードが存在しているかどうかを調べる
    if( db[id] ){
      //. ヘッダから入力されたユーザーIDとパスワードを取り出す
      var b64auth = ( req.headers.authorization || '' ).split( ' ' )[1] || '';
      var [ user, pass ] = Buffer.from( b64auth, 'base64' ).toString().split( ':' );

      //. 入力内容が正しい場合のみ next() を返して本来の処理へ
      if( db[id].user == user && db[id].pass == pass ){
        return next();
      }else{
        //. 入力内容が間違っていた場合は認証エラー扱いとする
        res.set( 'WWW-Authenticate', 'Basic realm="MyApp"' );
        res.status(401).send( 'Authentication required.' );
      }
    }else{
      //. 指定された ID が存在していなかった場合も認証エラー扱いとする
      res.set( 'WWW-Authenticate', 'Basic realm="MyApp"' );
      res.status(401).send( 'Authentication required.' );
    }
  }else{
    return next();
  }
});

  :
  :

app.get( '/hello', function( req, res ){
  res.contentType( 'application/json; charset=utf-8' );
  res.write( JSON.stringify( { status: true }, 2, null ) );
  res.end();
});

  :
  :


赤字部分が今回作成した処理です。req オブジェクトからリクエスト先のパスや Basic 認証で指定された情報を取り出して正しい情報かどうかを判断し、正しい場合は本来の処理へ、間違っていた場合は HTTP の認証エラー結果を返すような内容を記述しています。basic-auth-connect モジュールを使うとこのあたりの細かな記述をする必要がなかったのですが、自分で判断する場合はこのあたりも自分の責任範囲で用意する必要があります。

上述の例では URL パラメータ id は "000", "001", "002" のいずれかである必要があり、それぞれの場合の Basic 認証情報(ユーザーID : パスワード)はそれぞれ "a":"x", "b":"y", "c":"z" としています。この正しい組み合わせが指定された場合のみ GET /hello が実行されて結果が返される、という処理が実行されるようになります。


(参照)
https://stackoverflow.com/questions/23616371/basic-http-authentication-with-node-and-express-4


facebook に URL を含めて投稿すると、そこは自動的にリンクになり、クリックすると指定された URL ページを開くことができます。ここまでは当たり前の話:
2020080206


2020080207


このリンク先の URL は正確には元の URL とは少し異なります。というのは(おそらく追跡目的で)元の URL に fbclid=XXXXXXXX というパラメータが付与されたURL がリンク先になります(XXXXXXXX 部分はその時によって異なるランダムな文字列です)。このパラメータはリンク先ではほとんどのケースで無視されるので実質的には何の違いも生じずに期待通りのページが開きます:
2020080208


さて、問題はこの facebook の仕様が期待通りの結果にならないケースがあるということです。その典型がウェブ上に公開されたノーツの各種ヘルプデータベースのページです。例えば bcom.com 様が公開している Lotus Domino Designer 8.5 のデザイナーヘルプは以下の URL で開きます:
https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameSet

2020080209



※勘のいい人はこの時点で気づいているかもしれませんが、↑実はこの URL は少し特殊なフォーマットになっています。"?" のあとに URL パラメータとして "OpenFrameSet" が付与されています。が、一般的には URL パラメータは "key=value" という形になっているもので、この URL は key だけが指定された形になっています。とはいえ、これで正しく動くんですけど。。


さて、問題は上記のようなおかしな URL を facebook に貼ったときのリンクの挙動です。仕様的には fbclid=XXXXXXXX というパラメータが追加され・・・るはずなんですが、元の URL が少しおかしなフォーマットになっているせいか期待通りの形(https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameSet&fbclid=XXXXXXXX)になってくれません。OpenFrameSet の直前の "?" がなぜか "!" に変換されて、https://www.bcom.co.jp/help/help85_designer.nsf/Main!OpenFrameSet?fbclid=XXXXXXXX という URL が facebook からリンクされます。そしてこのリンク先を開くとエラーとなってしまうのでした:
2020080201


さて普通にヘルプのページを facebook に貼っただけではリンク先がエラーになってしまう事実がわかりました。ではそこまで理解した上で該当の URL を facebook に正しく貼るにはどのようにすればいいでしょうか?

実は単純な解決方法があります。もともとのおかしな URL は key=value の key 部分だけが指定されているものだったので、無理やり value 部分を足してフォーマットしては矛盾のない形する方法で解決できそうでした。具体的には https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameset=1 という URL を指定して facebook に貼る、という方法です。

こうすると facebook からのリンク先は https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameset=1&fbclid=XXXXXXXX という矛盾のないフォーマットになり、この URL であれば問題なく開くことができるようでした:
2020080202



ノーツの各種ヘルプファイル以外にこのようなフォーマットの URL を使うケースがあるのか、また facebook 以外でこのような(パラメータ自動付与による)不都合が生じるサービスがあるのかどうかもよくわかっていないのですが、おそらくここで紹介したのと同様の方法で回避できると思っています。

ウェブブラウザの検索履歴機能が有効になっていると、アドレスバーに一文字入力しただけで過去の履歴から参照ページの候補を出してくれます:
2017022101
 ↑ アドレスバーに "b" とだけ入力した時の画面。僕の第一候補は IBM Bluemix です!


これ、当然アルファベット毎に候補が変わります。また人によっても(細かなことを言うとブラウザによっても)結果は異なってくるわけです。

で、自分の場合の各アルファベット文字ごとに出てくる第一候補のサイトはどんな感じになるのかを面白そうなので調べてみました。なお 'L' の第一候補は localhost だったのですが、結果としてつまらなかったので排除しています。また http と https の混在は http で統一しています。その結果は以下の通りでした:

#URL説明
ahttp://analytics.google.com/Google Analytics
bhttp://bluemix.net/IBM Bluemix トップページ
chttp://console.ng.bluemix.net/IBM Bluemix コンソールページ
dhttp://dotnsf.blog.jp/まだプログラマーですが何か(個人ブログ)
ehttp://eclipse.org/Eclipse
fhttp://facebook.com/facebook
ghttp://github.com/dotnsf/GitHub
hhttp://h********.mybluemix.net/IBM Bluemix 上に作りかけのサービスサイト
ihttp://info.mybluemix.net/業務用ブログ
jhttp://juge.me/所有ドメインである juge.me の Tumblr サイト
khttp://kuku.lu/PGO サーチ(ポケモンGo)
lhttp://livedoor.blogcms.jp/livedoor Blog
mhttp://manholemap.juge.me/マンホールマップ
nhttp://nikkansports.com/日刊スポーツ
ohttp://openntf.org/OpenNTF.org
phttp://product.rakuten.co.jp/楽天商品価格ナビ
qhttp://qiita.com/キータ
rhttp://rakuten.co.jp/楽天市場
shttp://status.ng.bluemix.net/IBM Bluemix の稼働ステータス確認ページ
thttp://tweetdeck.twitter.com/TweetDeck(Twitter クライアント)
uhttp://uken.or.jp/IBM ユーザー研究会
vhttp://vm-171qzx1tim.sova.bz/wp.sova.jp 内に個人的実験目的で作った WordPress サイト
whttp://watson-api-explorer.mybluemix.net/IBM Watson の API Explorer
xhttp://www.play-asia.com/ゲームやゲーム機の情報サイト PLAY-ASIA.com(XBox などのキーワードでアクセスが多かったと思われる)
yhttp://youtube.com/YouTube
zhttp://japan.zdnet.com/article/35094997/ZDNet 内の IBM Bluemix 記事


2点ほど補足すると、"H" のサイトはいま開発途中のもので、まだ URL をお見せしたくないので伏せ字にさせていただきました。また "X" と "Z" は厳密には頭文字がこれらで始まるサイトではないのですが、他に候補がなかったのか、これらのページが第一候補になっていたので、そのまま記載しています。


結果を見た感想としては「マジメだなあ(笑)」という感じ。業務や自分の運営サービス、およびその関連サイトが多くなっています。あと O とか U とか V とか Z あたりはそんなに頻繁に使っている印象もないサイトなのですが、おそらく他の候補が弱すぎるのと、一時期何回もアクセスしていた時期が昔あったのでその影響もあるんだと思います。

1つ気になったのは T 。ここは自分が開発&運用しているツイートマッパー http://tweetsmapper.juge.me/ になってほしいところだったけど、実際によく使っているのは TweetDeck でした。ツイッター関連という意味では同様のサービスですが、やっぱり自分でも使わないとね。。



 

このページのトップヘ