codesign を version 1 から version 2 にコマンドで更新する方法

2014年８月４日、アップルから突然メールがきた。codesignの仕様がMac OS 10.9.5以降はversion 2のものでないと認証されなくなり、これまでの codesign version 1の製品では、アプリケーション起動時に「認証していないアプリ」として警告がでるようなる。

codesign version 2にするには、Mac OS 10.9 以降の xcode で build しなおせば，自動的に version １から version 2 に切り替わる。

しかし、古いアプリケーション（たとえばPPCにも対応しているアプリ）などは Mac OS X 10.7 の xcode 3でないと build できない。Mac OS 10.9 の環境ではbuild できないのだ。

MacApp Store を経由しないで直接配布している Developer ID アプリの場合は、 Mac OS X 10.7 の xcode 3 で build した アプリケーション（たとえば foo.app ）を以下のように  Mac OS X 10.9 上のコンソールからコマンドで version 2に変更できる。

$ codesign --verbose --force --sign "Developer ID Application: your company" --deep foo.app 

終了したら、以下のコマンドで version 2 になっているかどうか、確認できる。

$ codesign　-dv foo.app
[......]
Sealed Resources version=2 rules=xx files=xx
[......]

また以下のコマンドで GateKeeper が受け付けてくれるかどうか、チェックできる。

$ spctl -a -t exec -vv foo.app
foo.app: accepted
source=Developer ID

では、MacApp Store で配布する製品の場合は、どうしたらいいのだろか。MacApp Store で配布する製品でも、いろいろな理由で Mac OS X 10.9 の xcode で build できない場合がある。

うーむ。やっぱりその場合は、で Mac OS X 10.9 の xcode で buildできるようにソースコードを修正するしかないのか？

AppleScript や Automator の CodeSign

Mac OS X 10.8 (Mountain Lion)からは、Appleから認証されたDeveloper IDのCode Sign のないアプリケーションをダウンロードするとデフォルトの状態では起動できない。

通常、Developer IDのCode Signは、Xcode のbuild 時に付加される。


ところで、AppleScript のアプリケーションや Automatorのワークフローも Developer IDのCode Sign がついていないと同じように起動できない。

ところが、これらのアプリケーションの作成には Xcode は使わない。AppleScript のアプリケーションは AppleScript Editor で、Automatorのワークフローは Automator.app で作成する。

では、どうやってAppleScript や Automator に CodeSigin を付加するのか。以下のようにすると Xcodeを使わず codesign コマンドを使って直接アプリケーションに CodeSign を付加することができる。

AppleScript アプリケーション

1) CodeSignのためには、アプリケーションパッケージ内の info.plist のなかに Bundle Identifier が定義されていなければならない。AppleScriptアプリケーションには一般にBundle Identifierが定義されていないので、以下のようなBundle Identifierを追加する。

           <key>CFBundleIdentifier</key>

            <string>jp.co.yourCompany.applescript.foo</string>

Bundle Identifierの追加はテキストエディタとかplistエディタを使う。なお、Mountain LionのAppleScriptエディタには新たにBundle Identifierの編集機能が追加されているので、この機能を使っても行える。

2) アプリケーションパッケージ内のmain.scpt を chmod コマンドで書き込み禁止にする。

$ chmod a-w foo.app/Contents/Resources/Scripts/main.scpt

3 ) codesign コマンドで CodeSign を書き込む。

$ codesign --sign 'Developer ID Application: YourCompany.' 
-i jp.co.yourCompany.applescript.foo -f foo.app 

4 )うまく CodeSign が付加されたかどうかは以下のコマンドで確認できる。

$ codesign --display -vvv foo.app

Automator ワークフロー

1) Bundle Identifier の修正。Automator のワークフローのパッケージ内の info.plist には、すでに Bundle Identifier が備わっているので、それを希望の文字列、たとえば

jp.co.yourCompany.automator.foo

に書き換える。

２） codesign コマンドで CodeSign を書き込む。

$ codesign --sign 'Developer ID Application: YourCompany.' 
-i jp.co.yourCompany. automator.foo -f foo.app 

３）うまく CodeSign が付加されたかどうかは以下のコマンドで確認できる。

$ codesign --display -vvv foo.app

Xcode 3.2.6 と Gate Keeper

Mac OS X 10.8 (Mountain Lion)では、ダウンロードされた不正なアプリからシステムを防御するため Gate Keeper という機能が新設された。デフォルトのシステム設定では、Appleから認証されたCode Sign (Mac Developer ID)が付加されていないアプリをダウンロードし起動しようとすると、以下のようアラートが出て起動することができない。

というわけで、Mac OS X 10.8 からはデベロッパーは自分の製品を「Mac Developer ID」で Code Sign しないといけなくなった。


まず、Mac Developer ID をAppleから発行してもらう。Mac Developer ID をどうやって発行してもらうかは、この投稿の本題ではない。Mac Developer IDをまだもっていないひとは以下のページを参照して取得してください。
Developer Certificate Utility - Mac Developer Program - Support - Apple Developer

無事、Mac Developer ID が取得できたら　Xcodeで目的の製品をbuildするときに、buildオプション CodeSign にMac Developer ID :Application を指定しbuildすればよい（詳しくは以下を参照）。
Tools Workflow Guide for Mac: Distributing Outside the Mac App Store

以上でめでたく Mac Developer ID でCode Sign された製品ができる（はずな）わけである。（だったら、なんでわざわざこんな投稿をする必要があるのか。）


それがどっこい、そうではないのだ。

Mac Developer ID で Code Sign をするときは、

Xcode 4.3 でないといけないのだ！！

Xcode 4.2 とか Xcode 3.2. でbuild してしまうと、付加される Code Sign の内容が異なり、Mac OS X 10.5あるいは Mac OS 10.6 で動作させたときMac Developer ID がシステムに正しく認識されないという問題が生じる。
Mac Developer ID が認識されなくとも、もともと、Mac OS X 10.5/10.6 では Gate Keeper が動作していないので問題ないではないか思うかもしれないが、そうではない。

たとえば KeyChain に登録されているベーシック認証のページを開こうとすると、初めて開くときだけ 開くかどうか許可ダイアログで聞いてくるが、２回目以降は許可ダイアログなしに直接開くことができる。


Xcode3.2.6やXcode4.2 で Developer ID のCodeSign でbuild したアプリでは、システムに正しく認証されていないので、ベーシック認証のページを開こうとすると、毎回、許可ダイアログが表示されてしまうのだ。このようなアプリのもとでは KeyChain が正しく動作しないのだ。


では、実際に Xcode4.3でbuildされた場合と、Xcode3.2でbuildされたときで、Mac Developer ID のCode Signのどこが違うのか、ターミナルから コマンド「codesign -d -r-」で直接みてみよう。


Xcode3.2.6 でビルドされた foo.app では
$ codesign -d -r- foo.app 
Executable= foo.app/Contents/MacOS/foo
library => identifier "com.apple.Cocoa" and anchor apple or identifier "com.apple.Carbon"  <--  略 --> and anchor apple or identifier "com.apple.Foundation" and anchor apple
# designated => identifier "jp.co.artman21.foo" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = F8FSQZCDV7


緑の字の部分[ designated record ]は、ルート証明書「anchor apple generic」と中間証明書「certificate 1[field.1.2.840.113635.100.6.2.6] 」そして自分のDeveloper IDの証明書「certificate leaf[field.1.2.840.113635.100.6.1.13]が存在しなければならず、Developer IDのの値はF8FSQZCDV7 であると指定している。
ところが、なんと中間証明書 certificate1[field.1.2.840.113635.100.6.2.6]は、Mac OS 10.5/10.6 ではシステムに実装されていないだ。これが foo.app がシステムに正しく認証されない原因だ。

一方、Xcode 4.3 でビルドされた bar.app では

$ codesign -d -r- bar.app  
Executable= foo.app/Contents/MacOS/bar
library => identifier "com.apple.Cocoa" and anchor apple or identifier "com.apple.Carbon"  <--  略 --> and anchor apple or identifier "com.apple.Foundation" and anchor apple
designated => anchor apple generic and identifier "jp.co.artman21.bar" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = F8FSQZCDV7)

緑の字の部分[ designated record ] の内容が Xcode3.2.6 の場合とちがって、中間証明書が「(certificate leaf[field.1.2.840.113635.100.6.1.9] または certificate 1[field.1.2.840.113635.100.6.2.6] 」のどちらかとなっている。中間証明書 のどちらかが存在すればエラーにならない。すなわち、bar.app はMac OS 10.5/10.6 でもシステムに正しく認証される。

でも、Xcode 4.3 に移行できない
ときはどうすればいいのだ 

新製品はともかく、昔からある製品は、過去のしがらみがあって、Mac OS X 10.4 もサポートしなければいけなかったり、ppc もサポートしななればいけなかったりで、Xcode 4.3 に移行できない場合も多い。

そんなときは、とりあえず Xcode 3.2.6 でbuild して、CodeSign の[ designated record ]の部分だけ、以下のように Xcode4.3 の[ designated record ]に入れ替えるとうまくいく。

まず、Xcode4.3 でbuild した bar.appの[ designated record ]をもとに foo.app の[ designated record ]を以下のように作成しファイル「fooDR.txt」として保存する。

designated => anchor apple generic and identifier "jp.co.artman21.foo" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = F8FSQZCDV7)

そして、ターミナルから以下のコマンドで

$ codesign -r fooDR.txt -s "Developer ID Application: Artman21 Inc." -f foo.app

foo.app: replacing existing signature

うまくかきかわったかどうかは、

$ codesign -d -r- foo.app 

で調べられる。

ー　以上　ー

＜謝辞＞ 今回の投稿の作成にあたっては、BRadikoの作者 bui さんからいろいろ貴重な示唆をいただきました。また、Daniel Jalkut さんの Red Seater Blog の投稿 Developer ID Gotcha も非常に参考になりました。

Tweet 読み上げスクリプト つぶやき Kyoko

Twitterタイムラインに届いた新着ツイートをリアルタイムにKyokoの声でつぶやきます。

以下からダウンロードできます。

http://idisk.mac.com/satoshi-Public/TsubuyakiKyoko.zip

<<動作環境>>

Mac OS X 10.7 以上、Twitter.app が必要です。

システム環境設定「スピーチ＞テキスト読み上げ」で日本語音声読み上げの"Kyoko"、英語は"Alex"をあらかじめオンにしてください。

<<特徴>>

日本語のtweetは"Kyoko"で、英語は"Alex"で読み上げます。

tweet中のURLやハッシュタグは除外して読み上げます。

AppleScripエディタで「つぶやき Kyoko」のソースリストを参照できます。

<<修正履歴>>

12.03.05 いくつかのバグを修正し、アプリケーション名を「つぶやき Kyoko」に変更。

12.02.11 ツイート末のにあるハッシュタグやアドレスの最後の１文字を発音してしまうバグを修正。

12.02.10 Twiittererを公開

<<制作/著作>>

松本慧　satoshi@mac.com  Twitter:@cometheart http://cometheart.blogspot.com/

ソースリスト

property enableF : true

property intervalSec : 1

property lastUpdate : 0

on run

set intervalSec to 1

tell application "Twitter" to activate

delay 3

set enableF to true

end run

on idle

if enableF = true then

set enableF to false

idleMain() of me

set enableF to true

end if

return intervalSec

end idle

on idleMain()

tell application "Twitter"

set ca to count of every account

if (ca is greater than 0) then

tell account 1

repeat

set ht to a reference to home timeline

--set mt to a reference to mentions timeline

set now to last update of ht

if now is not lastUpdate then

set lastUpdate to now

set n to name of ht

set ss to a reference to (every status of home timeline)

set s to a reference to item 1 of ss

set t to full name of author of s

smartSay(t) of me

set t to text of s

set t to filter(t) of me

smartSay(t) of me

else

exit repeat

end if

end repeat

end tell

end if

end tell

end idleMain

on smartSay(s)

set len to length of s

set i to 1

repeat while (i ≤ len)

if character i of s > "z" then

say s using "Kyoko"

return

end if

set i to i + 1

end repeat

say s using "Alex"

return

end smartSay

on filter(s)

set len to length of s

set t to ""

set i to 1

repeat while (i ≤ len)

if i < len - 6 then

set substring to (characters i thru (i + 6) of s) as string

else

set substring to ""

end if

--display dialog text of substring

if substring is "http://" then

set i to i + 6

repeat while (i ≤ len)

if character i of s > "z" then exit repeat

set i to i + 1

end repeat

else if character i of s is "#" or character i of s is "@" then

set i to i + 1

repeat while (i ≤ len)

if character i of s > "z" then exit repeat

set i to i + 1

end repeat

else if character i of s is "…" then

set i to i + 1

else

set t to t & character i of s

set i to i + 1

end if

end repeat

return t

end filter

突然 Lionの起動が不安定になった...

半月くらいまえにLionをクリーンインストールして、徐々にいろいろなソフトをインストールしながら使っていた。

ところが、今朝そのLionの起動が、突如不安的に。。。

１）オートログインすると、Finderが「予期せぬ原因で終了」していまう。もう一度トライすると起動できるときもある。
２）オートログインをオフにしてログインウインドウを表示するようにして起動したら、ログインウインドウまではたどりつくが、パスワードを入力しようとすると、最初の一文字目で落ちてしまったり、入力できても、真っ白なスクリーンが現れてから、再度丸いプログレスインディケータのスクリーンに切り替わって、ログインウインドウがまた現れたりする。
３）２回目のログインウインドウが表示されてから、再度パスワードを入力すると、なぜか、だいたい起動できる。
４）クラッシュログのライブラリを覗いたら、何度もトライしたので以下のようなクラッシュレポートがいっぱいたまっていた。

SystemUIServer_2011-12-12-110203_matsumoto-satoshi-no-Mac-Pro.crash
TISwitcher_2011-12-12-110203_matsumoto-satoshi-no-Mac-Pro.crash
fontworker_2011-12-12-110202_matsumoto-satoshi-no-Mac-Pro.crash
Finder_2011-12-12-110153_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-110142_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-110131_matsumoto-satoshi-no-Mac-Pro.crash
fontworker_2011-12-12-110121_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-110121_matsumoto-satoshi-no-Mac-Pro.crash
UserNotificationCenter_2011-12-12-110121_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-110111_matsumoto-satoshi-no-Mac-Pro.crash
Dock_2011-12-12-110100_matsumoto-satoshi-no-Mac-Pro.crash
Finder_2011-12-12-110100_matsumoto-satoshi-no-Mac-Pro.crash
mdworker_2011-12-12-110100_matsumoto-satoshi-no-Mac-Pro.crash
SystemUIServer_2011-12-12-110100_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-110100_matsumoto-satoshi-no-Mac-Pro.crash
fontworker_2011-12-12-102335_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-102325_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-102315_matsumoto-satoshi-no-Mac-Pro.crash
Dock_2011-12-12-102314_matsumoto-satoshi-no-Mac-Pro.crash
Finder_2011-12-12-102314_matsumoto-satoshi-no-Mac-Pro.crash
SystemUIServer_2011-12-12-102314_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-102314_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-101723_matsumoto-satoshi-no-Mac-Pro.crash
Dock_2011-12-12-101713_matsumoto-satoshi-no-Mac-Pro.crash
Finder_2011-12-12-101713_matsumoto-satoshi-no-Mac-Pro.crash
SystemUIServer_2011-12-12-101713_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-101713_matsumoto-satoshi-no-Mac-Pro.crash
talagent_2011-12-12-101713-1_matsumoto-satoshi-no-Mac-Pro.crash
LCCDaemon_2011-12-12-100125_matsumoto-satoshi-no-Mac-Pro.crash

talagentというのがあるが、再起動で前回動作していたアプリを自動立ち上げる resume 機能と関係しているらしい。Lion: What is Talagent? - MacRumors Forums

５)別volumeのSnow Leopardからは全く問題なく立ち上がるので、ハードウェアの原因ではないようだ。また、Lionのドライブを検証してみても異常は見つからなかった。

６）ドライバ関係に問題あるかもしれないとおもい、先日インストールした Logicoolのコントロールセンター　lcc351j　をアンインストール。これがいちばん臭い。最初に落ちているのがこの LCCDaemon だ。しかし、現象は改善しない。アンインストーラーに問題があってアンインストールできていない可能性もあるか。

７）結局 Lionを再インストールすることに。オプションキーを押しながらMacの電源を入れて、起動ディスクの選択スクリーンから、"Recovery HD"を選択。Lionの再インストールを選択。「インターネットにつながっていないと」とおこられる。メニューバー右のWi-Fiアイコンを選択し、Wi-Fiのパスワードを入力し、無事、約１時間かかって Lionのインストールが完了。

８）Lionの再インストールで問題は解決したようだ。 Lionの"Recovery HD"を初めて体験した。とりあえず、めでたし。めでたし。かな。

Airtel SIM カードで「インド、どこでも iPhone4S」

せっかく Sim Free の iPhone4S をもっているので、インドで SIM カードを購入し、インターネット共有を ON にして、インドのどこからでも Mac からインターネットにアクセスできるようしよう。 インドの田舎でも使えるように、キャリアは携帯電話利用者数は国内1位の Airtel を選択。

（注意）Softbank の iPhone4S は SIM ロックがかかっているので Softbank 以外の SIM は使えません。超高い定額海外ローミングで我慢するか、脱獄して SIM ロックを解除する必要があります。

1）日本での準備：あらかじめ出発前に SIM カードを購入するときに必要な以下の書類を揃える。

   パスポートの写真のページのコピー

   パスポートのインドのビザのページのコピー

   パスポートサイズの写真１枚

2）インドに到着したら以下の情報も購入に必要になる。

滞在先のホテルの住所、電話番号、部屋番号

3）携帯ショップへ行き上記の書類を提出し SIM カードを購入する

今回は チェンナイの Spencer Plaza というショッピングセンター3F にある携帯 Shop で購入。店の対応も基本的に親切だった。最初 こちらの働いている会社の証明書が必要などと言われたが、上記の1)2)の書類で購入できることが店のひとにも解って購入できた。でも、それがわかるまでいろいろ問い合わせしていたので、30分くらいかかった。

4）Airtel の SIM を20ドルをだして購入した。以下がそのときのレシート。金額はルピーで表示されている。今回はリチャージ分の250ルピーが追加されている。追加しなければ15ドルくらいか。SIM カードのカット代185ルピー（350円くらい）がちょっと高いかも。

5） 店のひとにセットするしてもらうまえに、iPhone の言語環境を　設定＞一般＞言語環境で「英語」にしておく。

6) 店のひとに日本で使っていた日本通信の SIM から Airtel の SIM に入れ替えてもらう。（帰ったときに、成田で日本通信の SIM に戻すために、SIM を取り出すためのピンを持参することをおすすめする）

7) 以上でとりあえず音声通話は可能になる。電話番号「*123#」にかけると以下のように現在のチャージ残量を参照できる。なおアカウント情報は「*121#」で確認できる。

2012年1月6日まで99ルピー、2014年8月18日まで181.24ルピーとある。250ルピー追加したはずなのに、181.24ルピーしか表示されなかったので店の人に文句を言ったら、そうゆうものらしい（納得は行かなかったが）。また、リチャージの追加分が表示されるのには 開通してから30分くらいかかった。

8）データ通信のためにまず、Phone の 「設定＞一般＞リセット＞ネットワーク設定をリセット」でネットワーク設定をリセット。

9) APNナンバーをセットしようとして「設定＞一般＞ネットワーク＞モバイル通信ネットワーク」をひらこうとしたが「モバイル通信ネットワーク」の項目がない！！　うーむ。店の人に聞いてみても iPhone4S ははじめてなのでよくわからないという。これでは肝心のデータ通信ができないではないか！！

10) 店のひとが Airtel のサポートに問い合わせたが解決せず。あとで、サポートから返事が iPhone に SNS で送られてくるということで、とりあえずそれを待つことに。

11) とりあえず店からでて、いろいろ試しているうちに、突然データ通信ができるようになった。とうやら、iPhone4S の Airtel の場合は APN 番号は自動的にセットされてユーザーが入力する必要がないようだ。

データ通信でできるようになるまで２時間くらい待つことが必要らしい。

12）以上で、インドで iPhone4S で Airtel の SIM を使ってデータ通信が無事できようになった。めでたし、めでたし。

<<注意>> 店のひとによると、AirtelのプリペイドSIMは、今回2014年8月16日までの期限があるものの、６ヶ月に１回はアクセスしないと契約がクリアされて使えなくなってしまうらしい。アクセスは日本からでもいいので、最低半年に１回はこのSIMを使ってどこかにアクセスする必要がある。「*123#」とか「*121#」へ電話をかけるといいかも。

Xcode 3.2.6 インストール 顛末記

Snow Leopard, Xcode 3.2.5 で正規表現のライブラリ OgreKit を更新しようと思って、OgreKit最新版をダウンロード。

 OgreKit：http://web.me.com/oasis/ogrekit/About.html 

トラブル１： buildエラー 

buildしようとしたら以下のエラーを先頭に500以上ものエラーメッセージの嵐にみまわれた。

 error: can't exec '/usr/bin/make' (No such file or directory) 

たしかにそのpathにはmakeは存在しない。
どうも以前XcodeをインストールしたときにUnix Toolをインストールしなかったのが原因らしい。

トラブル２：iTunesが原因でインストールが完了できない 

そこで、 Xcode 3.2.5を再インストールしようと思ったが、Xcode3.2.6もでているので、Xcode3.2.6をインストールすることにした。

インストーラがもうすぐ終了というところで、以下のメッセージがでた。

quit iTunes 

しかしiTunesを止めても上記のメッセージはでたままで先にすすまない。
しかたなく、cmd+option+ESCでインストーラを強制終了。

システムを再起動し、こんどは iTunesが動いていないのを確認してインストーラを起動。ところが、iTunesが動いていないのに、またおなじ

quit iTunes 

のアラート。うーむ。Googleで調べたら iTunes Helperというプログラムがバックグランドで動作していることが原因らしいことがわかり、

ユーティリティ＞アクティビティモニタ

で、 iTunes Helperを強制終了したらインストールが完了した。

トラブル３：Xcodeが起動しない。 

さて、Xcodeを起動すると、こんどは以下のエラーでXcodeが強制終了してしまう。

Exception caught: Couldn't load plug-in 'com.apple.Xcode.iPhoneSupport' 

うーむ。

googleで同じようなトラブルを探すと iTunes を再インストールすると直るらしい。 そこで、Apple のページから iTunes 10.5をダウンロードして iTunes を再インストール。

 http://www.apple.com/jp/itunes/download/

 iTunes をインストール後、マシンを再起動し、おそるおそる Xcodeを起動。
今度は Xcode が無事起動し、目的のOgreKitも正常にbuildできた。 

めでたし、めでたし。

Leopard の日本語 Help メニュー

Leopard からは、Spotlight メニューのようにヘルプメニューに直接文字列を入力して検索できるようになりました。

プログラムの開発側からは、メニューバーに Help というタイトルを作れば自動的にシステムで検索メニューを付加してくれます。日本語の場合は「ヘルプ」というメニューがあるばそこに検索メニューが付加されます。

ところが拙作のソフトで、英語モードでは問題ないが、日本語モードのときにどうしても検索メニューが表示されないという症状にぶつかってしまいました。

約半日の試行錯誤の結果、以下のことが判明しました。

・メインメニューの「ヘルプ」の後になにか（例えばプラグインなど）のメニューを追加すると検索メニューが消えてしまう。
・この現象は、日本語モードときにおき、英語モードのときは発生しない。

というわけで、Leopardではへプルメニューの後にメニューを追加してはいけません。

また、Leopardでは、メニューアイテムに任意のNSViewをセットすることができるようになりましたが、残念ながらNSTextFieldやNSTextViewなどのキーボードイベントが必要なViewは動作しません。

ところが、Helpメニューのなかでは、キーボードイベントを受けてとることができ、NSTextFieldやNSTextView　などのメニューアイテムも正しく動作します。

lighttpd/RubyOnRails の SSL化

RubyOnRailsでは、Webサーバーとして動作が高速なlighttpd（ライティ）がよく使われる。

lighttpdはSSLもサポートしているのだが、SSL化のためのキチンとした資料が見つからずSSL化ではまってしまったがなんとかできた。(^^)


そこで、SSL化の手順をまとめてみた。

・SSL化するサイト
http//shop.sample.co.jp → https//shop.sample.co.jp


・SSL認証
費用がやすいグローバルサイン社をつかうことに

・RubyOnRailsのアプリケーションディレクトリ
~/jstore

参考URL Generate a CSR for an SSL Certificate for Lighttpd


-------------------------------
グローバルサイン社の以下のページを参照しなならCSRを生成する
-------------------------------

グローバルサイン社 CSRの生成



1) ssl関係のファイルの格納ディレクトリ~/jstore/ssl の作成



$ cd jstore
$ mkdir ssl



2) 秘密鍵ファイル shop.sample.co.jp.key を生成する

$ openssl genrsa -out shop.sample.co.jp.key 1024
Generating RSA private key, 1024 bit long modulus
........................++++++
..............++++++
e is 65537 (0x10001)

3) 生成された秘密鍵ファイルのpermissionを変更

$ chmod 600 shop.sample.co.jp.key


4) CSR shop.sample.co.jp.csr を生成する

$ openssl req -new -key shop.sample.co.jp.key -out shop.sample.co.jp.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Kanagawa
Locality Name (eg, city) []:Yokohama
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Sample Inc
Organizational Unit Name (eg, section) []:-
Common Name (eg, YOUR name) []:shop.sample.co.jp
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


-----------------
Country Name 国を示す2文字のISO略語です。 JP
State or Province Name 組織が置かれている都道府県です。 Kanagawa
Locality Name 組織が置かれている市区町村です。 Fujisawa
Organization Name 組織の名称です。 Sample Inc
Organization Unit Name 組織での部署名です。
※指定がない場合は - （ハイフン）を入力してください。 -
Common Name ウェブサーバのFQDNです。shop.sample.co.jp
Email Addres 入力不要です。
※指定がない場合は項目自体を作成しないでください。 -
A challenge password 入力不要です。 -
An optional company name 入力不要です。 -
------------------


以下の内容のCSRファイル shop.sample.co.jp.csr が生成される

$ cat shop.sample.co.jp.csr
-----BEGIN CERTIFICATE REQUEST-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE REQUEST-----


5) グローバルサイン社にサーバー証明書を申請する

https://system.globalsign.com/direct/directdvhigh.do

上記を開き購入するする証明書を指定し「注文する」ボタンを押す

次に企業情報の入力画面で自社の企業情報を入力

最後に上記のCSRを所定フィールドにCOPY&PASTEして申請する。
CSRは、破線の行も含めてコピーすること。


申請して数分くらいでグローバルサイン社からサーバー証明書のある
URLがメールで送られてくる。

-----BEGIN CERTIFICATE-----
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzz
-----END CERTIFICATE-----


6) 上記の内容を shop.sample.co.jp.crt ファイルとして保存する。

7) shop.sample.co.jp.key と　shop.sample.co.jp.crt　とを合体
して、shop.sample.co.jp.pem ファイルを作成する。


$ cat shop.sample.co.jp.key shop.sample.co.jp.crt > shop.sample.co.jp.pem
$ chmod 600 shop.sample.co.jp.pem



8) lighttpd のデフォルトインストールでは、ssl に非対応なのでインストールし直す。

lighttpd を　オプション--with-opensslをつけて再コンパイル


$ cd ~/src/lighttpd-1.4.15
$ ./configure --prefix=/usr/local --with-pcre=/usr/local --with-openssl
$ make
$ sudo make install


9) lighttpd.conf にsslのためのパラメータを指定

以下の4行を ~/jstore/config/lighttpd.conf に追加する

#### SSL engine
ssl.engine = "enable"
ssl.pemfile = CWD + "/ssl/shop.sample.co.jp.pem"
ssl.ca-file = CWD + "/ssl/dvcacert.cer"


ファイル dvcacert.cer は、グローバルサインからダウンロードした中間CA証明書
中間CA証明書のダウンロード先はグローバルサイン社からのメールに表示されている。

この中間証明書がないと「認証局不明」の警告がでてしまう。

10) lighttpd を起動し、完了！！

覚書：jstoreの開発経緯

ようやくシェアウエア・ライセンスキーの即時発行システム jstore が完成した。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
これまでのシステム
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

レンタルサーバー付属のショッピングカート(Perl)をベースに2001年に作成
ショッピングカートからの注文データ（CSV形式）を、オフラインでデーリーに回収し、ユーザー管理データベース(FileMaker)へ取り込み、登録コードを計算しユーザーへ登録メールを発送。取り込み/メール発送部分はアップルスクリプトで自動化。支払い方法はクレジットカードと銀行振込をサポート。クレジットカードの認証/代金回収はZEUS社を利用（手数料約５％+）。ZEUS社が英語ページ・海外クレジットカードに対応していないので、海外からの注文には、Kagi.comを利用（手数料10%+)

問題点

１）オフラインの登録コード処理のため、登録コードの発送が１日遅れになってしまう。
２）連休、年末年始、夏季休暇のときは発送が休日明けになってしまい、その間の売り上げがダウン。
３）国内売り上げと海外売り上げが異なった処理方法になり煩雑。

いまどき登録コードを即時発行できないシステムは、ユーザーからの苦情が多く、もう限界に達していた。。。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
新システムを模索
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

kagi.com や esellerate を使えば登録キーの即時発効は可能だが
・ユーザーへのメールが日本語に対応していない
・手数料が高すぎる 10%超
・即時発効の登録コード生成ルーチンを先方へ渡してしまうのは不安
・macsbなどのメーリングリスト書き込みをみると、kagi.com離れが進んでいる(?)

国内にはベクターがあるが
・英語に対応していない
・手数料がさらに高い 15%!!
・なんとなくダサイ　(^^;

そんななかで今年からPayPalが完全日本語化された。
PayPalを使えば
・海外と国内の売り上げを統一して扱える
・手数料も 3.4% + $0.30 と安い
・cgiインターフェースもあるので登録キーの即時発効もできそう。

2007年6月末、登録キー即時発効システム PotionStore の存在をmacsbで知る。
http://www.potionfactory.com/potionstore


ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
PotionStore 概略
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

・KagiやEsellerateなどのサービスを使わない、Mac OS X デベロッパーための登録キー即時発行システム
・Open source で、Ruby On Rails アプリケーション
・PayPal か Google Checkout にマーチャントアカウントがあれば簡単に自分の登録キー発行システムを構築できる

主な特長
・PayPal Website Payments Proをサポート
・PayPal Express Checkout support（PayPalアカウントなしでの支払い）をサポート
・Google Checkout をサポート
・Admin(管理者）インターフェースもサポート
・クーポンの生成と受け入れをサポート
・ライセンスキー問い合わせをサポート

ライセンス

Creative Commons Attribution-Share Alike 3.0 License.
http://creativecommons.org/licenses/by-sa/3.0/deed.ja

あなたは以下の条件に従う場合に限り、自由に
　　作品を複製、頒布、展示、実演することができます。
　　二次的著作物を作成することができます。
あなたの従うべき条件は以下の通りです。
　　表示. 原著作者のクレジットを表示しなければなりません。
　　継承 二次的著作物は配布するときは同じ条件で配布しなければなりません。

システム構成

・言語: Ruby
・フレームワーク: Ruby On Rails
・Security: 要SSL
・データベース: PostgreSQL


Ruby On RailsとSSLが利用できるサーバーであれば、レンタルサーバーでも動作可能。
PotionStoreのページで、導入した人の書き込みをみると４日間ほどで稼働したとのこと。

ーーーーーーーーーーーーーーーーーーーーーー

で、PotionStoreをダウンロードして実際に試してみた。

Unixコマンドにうとく、PostgreSQLも初めて、Rubyも初めて、Ruby On Rails も初めてという状態。

まずは、システムのインストールから。。。

OSXにRuby on Rails環境をインストールする方法
http://d.hatena.ne.jp/dtocos/20060304

PostgreSQL のインストール
PostgreX PostgreSQL Easy Installer for Mac OS X
http://www.magic3.org/postgrex/


ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
PotionStore は 日本で使えるのか？
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

実際にPotionStoreをインストールして以下のことがわかった。

１）PotionStoreで利用してる支払いシステム PayPal WebPayment Pro、Google Checkout が日本ではサポートされていない。
２）Webページやメールのバイリンガル（英語、日本語）化が必要

というわけで、そのまま（configファイル、ライセンス生成ファイルの修正だけ）では、とても使えないということが判った。

２）はなんとかなるとしても、とくに１）はプログラムの構造そのものの変更が必要になり致命的。(^^;

日本のPayPalでサポートしている API は、WebPayment Proでなく、それより古いタイプのWebPayment Standard。


PayPal がサポートしてる支払いシステム一覧
https://www.paypal.com/us/cgi-bin/webscr?cmd=_merchant-outside

・WebPayment Standard
・WebPayment Pro
・Email Payment


ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
WebPayment Pro
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
https://www.paypal.com/us/cgi-bin/webscr?cmd=_wp-pro-overview-outside

・米国でのみサポート
・マーチャントページで顧客の氏名、住所、クレジットカードの情報を取得し、それらの情報をPayPalのWebサービスに送信、決済を依頼する。Webサービスから正常リターンなら、登録コードを顧客に開示しメールを送る。
・WebPayment Standardに比べてプログラムが単純化できる。
・顧客にはPayPalのページは一切表示されないので、顧客にとってもシンプルで判りやすいインターフェースになる。
・クレジットカード情報をマーチャント側で行うので、SSLが絶対に必要、かつそのクレジットカード情報の取り扱いには細心の注意が必要。


ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
WebPayment Standard
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
https://www.paypal.com/us/cgi-bin/webscr?cmd=_wp-standard-overview-outside

・米国以外(日本）でも利用可能
・PayPalのWebページのなかで決裁する必要があり、マーチャントページからPayPal ページへリンクし、PayPal内で決済が終わったら、マーチャントページへまた戻る形になる。
・決済がマーチャントページだけで終わらないので、顧客にとっても複雑なインターフェースになってしまう。
・マーチャントページのなかでクレジットカード情報を扱わないのでマーチャントとしては気が楽。SSLも絶対必要ではない。
・PDT(Payment Data Transfer)と IPN(Instant Payment Notify)の２種類のAPI がサポートされている。
・PDTと IPN の２つのインターフェースを実装する必要があり、プログラムとしては複雑になる。

PDT(Payment Data Transfer)

PDT の主要機能は、買い手が支払い完了時に自Paypalのサイトから自サイトに自動的にリダイレクトされた時に、支払い取引の詳細を表示することです。つまり、Paypalと自サイトの処理は同期型です。（ここがポイント！）なので、PDTによってコールバックされる情報を元にバックエンドと統合を行うことが可能になります。

[参考] PHPでWebPayment Standardを利用したときの解説
http://blog.katsuma.tv/2007/06/paypal_pdt_ipn_intro.html


PayPalサイトで決済が正常終了すればこちらのサイトにリターンされ、Thank you ページを表示し登録キーを開示、登録キーお知らせメールを発送する。

しかし、顧客がPayPal内で支払いを完了したと同時にWebブラウザを終了してしまうと、Thank you ページの表示が行われなくなってしまう。結果として、支払いが発生しても登録キーが顧客に渡らなくなってしまう。

それを防ぐために、次のIPNとの併用が必要。

IPN(Instant Payment Notify)

IPNは、PDTと（ほぼ）同じデータがPaypalから自サイトにPOSTされますが、そのタイミングは支払いが終了したとき、また支払い状態が「Pending」の場合において決済されたとき、失敗したとき、拒否されたときにも別の通知を受け取ることになります。つまり、コールバックされるタイミングはWebのフローとは非同期に行われます。（これがPDTと違う大きなポイント！）PDTとは独立してWebフローとは非同期に自サイトへPOSTされてきます。

IPN では、顧客がPayPal内で支払いが完了すれば自動的にマーチャント側へ通知されるので、顧客がWebブラウザを閉じてしまっても問題ない。

jstore（今回作成したPotionStoreの日本語版）では、PDTとIPNの両方をサポートし、さきに発生したほうのイベントで登録キー生成、送信、DB更新を行うようにした。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
jstore (PotionStoreの日本語版）について
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

アートマン２１のjstoreのアドレス
https://support.artman21.co.jp:8080/

オリジナル（英語版）からの変更・追加

・WebPayment Standard (PDT & IPN)をサポート
・銀行振込み（国内のみ）をサポート
・日本語と英語の２言語をサポート
・製品価格を円とドルの2種類をサポート
・アップグレードの際の登録キーチェックをサポート


今後の予定

・９月中旬から実際の運用を開始
・数ヶ月実績をみて、問題なければ年末あたりにOpenSourceとして公開するかも

PayPalの日本語処理のバグ

PayPalのWebPayment Proを利用したオンラインショップのプログラムを Ruby On Railsで開発した。

PayPalは今年の初めに日本語化されたが、まだ日本語まわりでいろいろなバグがある。そのなかで一番重大と思う「全角ハイフン」のバグについて報告します。このバグについてはすでにPayPalに報告済みでPayPalでは現在（2007年9月12日現在）対応作業中です。

日本語入力でエラーがでるようなときは、このバグを疑ってみてください。

バグの要約：

PayPalで、全角ハイフン「−」（unicode: 0x2212, shiftJIS: 0x7c81）を入力すると、日本語でないとしてエラーメッセージが表示され受付けてもらえない。

再現方法：

PayPalにログインして、個人設定＞アカウント情報＞住所 を選択。
「追加」ボタンで、以下のような全角ハイフン「−」を含む住所の登録をこころみる。

住所１行目：南藤沢１６−１１

すると以下のようなエラーメッセージが表示される

このフィールドに使用できない文字が入力されています。現在利用できる文字タイプは次のとおりです。ヨーロッパ言語、中国語、韓国語、日本語、タイ語。もう一度実行してください。

問題点：

マーチャントのページのショッピングカートから
http://www.paypal.com/cgi-bin/webscr
へ住所も含めてPOSTしたときに、その住所に全角ハイフン「−」が含まれていると
PayPalの画面が表示されたときにエラーメッセージが表示される。
顧客には、そのエラーがなんのことかわからないので、ほとんどの顧客はそこで
取引をキャンセルしてしまい、マーチャントにとっては重大な機会損失が生じる。

全角ハイフン「−」は、何丁目何番などを省略して表示するときによくつかわれる文字なので、エラーになるのは絶対にまずい！！！

ぜんぜんコンピュータと関係ないが。。。

安倍首相の鼻の下にちょびヒゲを描くと、ヒットラーにそっくりだ。

猪瀬直樹に詰めりの服を着せてヘアースタイルをちょっと変えると、金正日にそっくりだ。

postgresのアダプタも忘れずに！！

localhost の Ruby on Railsのプログラムを、外部（paypal)とのやりとりの部分を開発をするため 、global address をもつ本番サーバーに移設することにした。

本番サーバーに、ruby、ruby on rails、postgres などを順番にインストールして、データベースのテーブルを作成するために
rake db:migrate
を実行した。しかーし、
no such file : postgres
というエラーでdb:migrateがエラーになってします。postgres はちゃんとインストールされ コマンド　psql も動作しているのになんでなんだろう！？

小一時間悩んで気がついた。

データベースアダプタをインストールするのを忘れてた！！！

Ruby版アダプタは
sudo gem install postgres-pr

C版アダプタは
sudo gem install ruby-postgres

でインストールできる。

なお、OS Xでの postgres のインストールは以下のインストーラを使うと簡単。
PostgreX（PostgreSQLのOSX用インストールパッケージ）-PostgreSQL installer

郵便番号での住所自動入力

郵便番号の入力が終わったとたん（＝フォーカスが郵便番号フィールドから外れたとき）入力された郵便番号から住所を自動入力されるようにした。

自前で郵便番号辞書を持つのはめんどうなので GROOVE Technology社の郵便番号検索 Web Service(無料)を利用した。
GROOVE Technology

javascript だけで実現できる。JSONP（JavaScript Object Notation with Padding）という仕組みを使っている。
JSONPの動作原理

Railsの多言語化

ユーザーが日本国内だけの場合はいいが、海外のユーザーもいる場合は、最低日本語と英語の両方のページをサポートする必要がある。

Cocoaの場合は、標準で国際化（Internationalization）がサポートされているので容易に多言語化が可能だが、Railsの場合は標準では英語しかサポートされていない。

日本語だけでいいなら、ActiveHeart というプラグインがある。ActiveHeartについては
http://jp.rubyist.net/magazine/?0012-RubyOnRails

複数言語のサポートには、Ruby-GetText-Package を使う。
http://www.yotabanana.com/hiki/ja/ruby-gettext.html

ActiveHeart と GetText の比較については、
http://blog.masuidrive.jp/articles/2006/07/03/gettext

オンラインソフトの販売システム

オンラインソフトをクレジットカード認証を行って販売・発行するシステムにはいろいろある。オンラインソフトの長所は、ユーザーと開発がダイレクトにつながり新鮮で良質なソフトを安く手に入れられるという点にある。しかし、Vector、kagi.comなどはその中間に入って10-15％ものマージンをとってしまい結果的にユーザーの負担が増えてしまう。

最近、Paypalが完全日本語化されクレジットカードの認証が小規模のソフトハウスでも簡単に行えるようになった。ライセンスキーの発行を手動で行うのであれば、簡単なHTMLを書くだけでショッピングカート付きのオンラインソフト販売システムを構築できる。手数料も3-5%で手ごろである。

ただ、手動（オフライン）でライセンスキーを発行する場合、年末年始や夏休みなどのときにライセンスキーの発行が遅れてしまうことになり、やっぱり今の時代ライセンスキーを自動（リアルタイム）で発行したほうがずっと良い。

Paypalを使ってライセンスキーを自動発行するシステムで、PotionStoreというオープンソースがある。２日位でクレジットカード認証付きのライセンスキー自動システムができてしまうそうだ。
http://www.potionfactory.com/potionstore/

しかし、ダウンロードして実際にセットアップしてみると以下の点で、日本の環境ではすぐには使えないことがわかった

1) WebPayment Proは日本では利用できない。（日本ではWebPayment Standardしかサポートされていない）
2) Google Checkoutも、現在アメリカとイギリスのマーチャントしか利用できない。

PotionStoreは、Ruby on Rails で書かれており日本用に修正すれば、なんとか使えそうだ。

ということで Ruby on Rails の勉強がはじまったのが2007年7月のはじめであった。