Jenkinsを使っています

最近プロジェクトにjenkins を導入した。

以前のプロジェクトでも自動ビルドとデプロイはやっていたけど、自分でスクリプト組んでcronで夜間に実行していたので、予定外のビルドやデプロイは僕しかできなかった。

当時使用していたアプリケーションサーバはWebsphareで、コマンドからdデプロイするにはJython (JavaベースのPython)という恐ろしげな(笑)言語でスクリプトを書く必要があった。

今回、新しいプロジェクトで開発を行うにあたっては、Webベースのビルドツールで、誰でも1-Clickでデプロイまでできるようにしようと考えていた。

ちょうど「Jenkinsではじめるビルド職人入門」という電子本が無料で配布されていた(いまは1,000円だそうです)ので、それを片手(?)に雛形プロジェクトをつくり、自動ビルドと、ローカルのTomcatにデプロイをできるようにした。
また、「ビルド職人入門」で紹介されていた内容をもとに、Javadocの生成、自動テスト、コードインスペクション(CheckstyleFindBugs)も実行されるようにした。ありがたや。

Vista/Winows7のログイン画面カスタマイズ

指紋認証バイス搭載のPCなどでは、指紋認証によるログオンを実現するために、よくメーカー独自のログイン画面が用意されている。
WindowsXPまでは、カスタムログイン画面を作成するためにはGINAという技術を使っていた。だが、Vista以降はCredential Provider(資格情報プロバイダ)というCOMコンポーネントを作成することになる。(ICredentialProviderを実装)


CredentialProviderの実装サンプルは、microsoftのサイトからダウンロードできる。
http://www.microsoft.com/downloads/details.aspx?FamilyID=B1B3CBD1-2D3A-4FAC-982F-289F4F4B9300&displaylang=en

また、以下には数少ない日本語の情報がある
Windows Vista 用の資格情報プロバイダを使用したカスタム ログイン機能の作成」
http://msdn.microsoft.com/ja-jp/magazine/cc163489.aspx


作成したコンポーネントを、レジストリに登録することで、カスタムログイン用のパネル(資格情報プロバイダ)が追加表示されるようになる。
ただし通常、セーフモードではデフォルトの資格情報プロバイダしか表示されない。


さて、指紋認証バイスのように、「パスワード」「指紋認証バイス」の「いずれか」で認証する場合は、サンプルにあるSampleCredentialProviderをベースに作成し、追加の資格情報プロバイダをレジストリに追加すればよい。


しかし、セキュリティ向上のために、たとえば「パスワード」「スマートカード」の「両方」が揃わないと認証OKにしないような要件の場合は、既存のパスワード資格情報プロバイダをラップして機能拡張する必要がある。サンプルでは、SampleWrapExistingCredentialProviderというのが、既存のパスワード資格情報プロバイダを拡張するサンプルだ。


また、それだけでは既存のパスワード入力パネルも表示されてしまって意味がないので、既存の資格情報プロバイダを非表示にする必要がある。
そのためにはCredential Providerと同じ要領で、Credential Provider FilterというCOMコンポーネントを別途作成してレジストリに登録する必要がある(ICredentialProviderFilterを実装)。Filterとあるとおり、どの資格情報プロバイダを表示するかを制御できる。


ただし、Filterの実装がうまくできていないと全ての資格情報パネルが表示されなくなってしまってログイン不能になるので注意が必要だ。そのような場合、セーフモードでもログイン不能になってしまうようだ。
#私もFilterのテストを仮想環境で行っていたが、2回くらいログインできなくなってバックアップから書き戻す羽目になった。

ActiveXをつくる(3)

ActiveXをつくる(2) - きょうのできごころ@はてなのつづき。

ActiveXをページに貼るためには、ページにObjectタグを記述する。


CLSIDの部分には、前回INFファイルに記述したclsIdと同じものを記述する。CODEBASEには、前回作成したCABファイルのパスと、バージョン番号を記述する(デフォルトは「1,0,0,1」。区切り文字がカンマである点に注意)。

また、ActiveX Control Padというツールを使用すると、上記のようなHTMLのテンプレートを作成してくれる。
http://msdn.microsoft.com/en-us/library/ms968493.aspx

ActiveXをつくる(2)

前回のつづき。

ActiveXを作るのには、前回挙げた開発ツールを含め、下記が必要。

  • Visual C/C++ 2008 Standard以上
  • 署名のための電子証明書(テストするだけなら必須ではないけど、インターネットに公開して使用するためにはほぼ必須)
  • Microsoft Cabinet SDK*1

前回、作成したコントロール(*.ocx)をWebページに貼り付けて自動的に登録されるようにするにはINFファイルが必要になる。

INFファイルのサンプルは以下のとおり。clsIdの部分は、作成したソースコードに記述されているのでそのまま記載する。

[version]
; version signature (same for both NT and Win95) do not remove
signature="$CHICAGO$"
AdvancedINF=2.0


[Add.Code]
sampleCtrl.ocx=sampleCtrl.ocx


[Deployment]
InstallScope=machine|user


[sampleCtrl.ocx]
file-win32-x86=thiscab
clsid={4CBBC676-507F-11D0-B98B-000000000000}
FileVersion=1,0,0,1
RegisterServer=yes
RedirectToHKCU=Yes

なお、IE8より、管理者以外でもインストール可能なActiveX(Non-admin ActiveX)を作成することができるようになっている。*2

「InstallScope=machine|user」の部分は、従来のActiveXとNon-admin ActiveXのいずれでも使用できるようにするための記述。
また、「RedirectToHKCU=Yes」はレジストリHKLM(HKEY_LOCAL_MACHINE)への書き込みをHKCU(HKEY_CURRENT_USER)にリダイレクトする。Non-admin ActiveXの場合に必要。


次に、ActiveXコントロールとINFファイルをまとめてキャビネットファイル(*.cab)形式にする。

Cabファイルを作成するには、Cabinet SDKに含まれるCABARCコマンドを使用する。なお、「-s 6144」の部分は、あとで署名を追加する場合のみ必要になる。

CABARC -s 6144 n Sample.CAB SampleCtrl.ocx SampleCtrl.inf

つづく。

ActiveXをつくる(1)

仕事でActiveXコントロールを作ることになった。しかも対象はWindows7のInternet Explorer8(IE8)。
Windows用のプログラミングすら、10年ぶりくらいなので色々な調査を行って作ったので、調査過程のメモをここに書いておく。


まず、ここで言うActiveXコントロールはWebページ上に貼り付けるものを言っている。代表的な例は、Windows Updateで使われているアレ。Windowsアプリに組み込むコントロールも基本的には同じはずだけど。


開発には、今であればVisual C/C++(Visual Studio 2008 Standard以上)が必要。ためしに作ってみるだけであれば、Microsoftから試用版がダウンロードできるのでこれを使用することで作れる。

ツール名 バージョン
Visual Basic 6.0
Visual C/C++ .NET,2005,2008(Express以外)


Visual C/C++ Express版は、CLI(.NET)アプリケーションしか作成できないのでだめ。
Visual Basic 6.0でもActiveXコントロールが作成できたが、現在販売されているVBでは作ることは出来ない。


コントロールの作成方法には、ATLを使う方法とMFCを使う方法の2種類がある。MFCのほうがウィザードが用意されており簡単そうなのでこちらを選んだ。基本的にはプロジェクトの作成時に、「MFC ActiveX コントロール」を選ぶと、雛形を作成してくれる。


コントロールをページに貼る方法についてはまたこんど。

Weblogicに複数アプリケーションをデプロイ

ひとつのアプリケーションサーバに、複数のアプリケーションをデプロイする場合、セッションの管理方法によっては注意が必要だ。
例えばWeblogicではデフォルトでセッション管理にcookieを使用する。デフォルトのcookieの名称は「JSESSIONID」になっているが、これは複数アプリケーションをひとつのサーバにデプロイした際でも、全てのアプリケーションで同じ名称が使用される。


この状態だと、例えばアプリケーションがそれぞれの認証機構にcookieを使用している場合、アプリケーションAでログインした状態で、別のアプリケーションBにログインすると、アプリケーションAの認証情報はcookieが上書きされることにより消えてしまい、再度アプリケーションAにログインしなおす必要がある。


その他、アプリケーションAでセッションに格納した情報が、アプリケーションBの画面を開いたことによりセッションIDが更新されてしまい、アプリケーションAから見えなくなってしまうなどの障害が起こりうる。


これを防ぐためには、cookieの名称(もしくはパス)を、一つのサーバに同居するアプリケーション毎に使い分ける必要がある。
ロードバランサなどを使用し、物理的なサーバは異なっていてもブラウザから同一サーバに見える場合も同様だ。

Weblogicの場合、cookieの設定はweblogic.xmlファイルに記述する。

たとえばこんな感じ。

 
  APP_A_SESSIONID
  /Application_A/
 

プロキシ自動構成スクリプト

以前、自動構成されたプロキシを調べる、というエントリを書いたが、Windowsに限って言えば、レジストリにキャッシュされた自動構成スクリプトの場所を調べることができる。

HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Internet Settings\AutoConfigURL

レジストリエディタで上記のレジストリ・エントリを参照すると、自動構成スクリプト(PACファイル)のURLがわかる。
PACファイルを取得しエディタなどで開くと、下記のようなJavaScriptファイルになっているはず。

function FindProxyForURL(url,host){
if (isInNet(host,"192.168.0.0","255.255.0.0"))
return "DIRECT";
else
return "PROXY 192.168.0.10:8080; DIRECT";
}

上記であれば、192.168.0.10がプロキシのIPアドレスだ。