2009/12/03

TwitterはRESTなAPIを備えているので、httpの通信ができれば基本的にどんな言語でもクライアントを作ることができるのがいいです。そこで私もPSTweetsというPowerShell版Twitterクライアントを作っているのですが、認証周りで問題が発生しています。

Twitterの認証には標準認証とOAuthが使えるのですが、現在はセキュリティ上の理由で標準認証は非推奨です。標準認証がなぜまずいかというと、マッシュアップサービスでTwitterに対して認証が必要な操作をする場合、ユーザーがその第三者のサービスにTwitterのIDとパスワードを送らなければならないためです。そのサービスがユーザーの認証情報を安全に保持してくれる保証はありません。

そこで考えられたのがOAuthという認証方法です。OAuthはとてもややこしいプロセスを含んでいますが、実質はそんなに難しいものではないです。要は、Twitterというサービス(これをサービスプロバイダという)にアクセスするための権限を、マッシュアップやクライアントを提供する第三者(これをコンシューマという)に委譲する仕組みです。ユーザーが「コンシューマを使いたい!」と思ったら、コンシューマは「じゃあついったーのページに飛ばしますから、あなたのアカウントを私が自由に使うことを許可してね」と言います。それでユーザーがTwitterのOAuth承認ページで「許可」すると、コンシューマはユーザーのアカウント情報を使ってTwitterのAPIを叩けるようになり、ユーザーはコンシューマにTwitterのパスワードを知らせることなくコンシューマの提供するサービスを利用することができるわけです。

さて、このOAuthをコンシューマが利用するには、Twitterにあらかじめ申請する必要があります。といっても登録ページでクライアント/サービス名などを入力するだけです。そうすると、コンシューマキーとコンシューマシークレットという文字列をもらえます。これはクライアントを特定するためのユーザー名とパスワードみたいなものです。ちなみにこの情報はコンシューマを提供する人のTwitterのユーザーアカウントに紐づいています。

コンシューマを通じてユーザーがTwitterのサービスを使うには、コンシューマを通じてTwitterからアクセストークンというものを貰う必要があります。このとき、コンシューマはTwitterに毎回コンシューマキーとコンシューマシークレットを送らなければなりません。

ここでコンシューマが独立したサーバーで運営されているサービスならば何も問題ありません。ユーザーがコンシューマキーとコンシューマシークレットを知る必要もユーザーに知られる危険性もありません。ところが、デスクトップクライアントだとどうなるかというと、コンシューマはデスクトップクライアントそのものです。なので、デスクトップクライアントはコンシューマキーとシークレットを何らかの方法で取得し、Twitterに送る機構が必要になります。

ここで、いくつかの方法があると思います。コンシューマキーとシークレットをデスクトップクライアントに暗号化して埋め込むのも一つの方法でしょう。ですが、結局は復号してTwitterに送らなければならないので、その通信をキャプチャすればユーザーは知ることができます。

なぜコンシューマキーとシークレットをユーザーに知られるとまずいかというと、それらを使うとまったく別のクライアントやサービスを、そのサービス名を詐称して作ることができてしまうからです。これがどうして問題なのかというと、そうなるとOAuthの承認が有名無実化してしまうためです。ユーザーがOAuthの承認ページで承認するサービスが本物かどうか調べるすべがありません。

メール登録制にしてコンシューマキーとシークレットを配布するとか考えましたが、なんだか大昔のシェアウェアのようで、なんとかシリアル集がはびこったように誰かが漏らしてしまう危険性を考えると難しいです。

コンシューマキーとシークレットを自分で取得してもらうというのも考えましたが、それはユーザーにとってかなり敷居が高いうえ、クライアント名がみんなバラバラになってしまいます(Twitterクライアント名はユニークであるため)。

コンシューマキーとシークレットを保持し、ユーザーからのリクエストに応じてアクセストークンを発行するサーバーを立てるというのも考えましたが、それってもうデスクトップTwitterクライアントじゃなくて、Twitterマッシュアップのデスクトップクライアントになってしまいます。

なので、デスクトップクライアントでOAuthを使うのは事実上無理なんじゃないかというのが私の結論です。

標準認証でもいいんですが、現在は標準認証は非推奨であり、そのため今からクライアントを作る場合は標準認証だとクライアント名をTwitterに登録することができなくなっています(タイムラインには「APIで」という表示になってしまう)。昔はメールでクライアント名を申請できたんですが、今はできません(この体制になる前に申請されたクライアントなら、今でも標準認証でもクライアント名を名乗れます)。これから作るクライアントで、クライアント名を名乗るにはOAuth必須です。ボット作者など、コンシューマ=ユーザーの場合はそれでもいいんですが…。これはぜひなんとか改善してもらいたいところですね。といっても、Twitter側からみると、それがコンシューマからのアクセスなのか、ユーザーからのアクセスなのか、区別をするのは難しいでしょうから、デスクトップアプリに限り標準認証でもクライアント名を名乗れるようにする、というのは難しいんじゃないかという気はします。

最近、新しいデスクトップクライアントがあまり登場せず、一方でやたらTwitterのマッシュアップサイトが増えたと思いませんか?中には、それデスクトップアプリでいいじゃないというものもちらほら。もしかして、この制限ができたためなんじゃないかと邪推までしています。うーむ、なんとかならないですかねー?

元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/12/03/183506.aspx

2009/07/20

こんにちは、むたぐちです。

PowerShellによるWindowsサーバ管理術(永尾 幸夫、小鮒 通成、国井 傑、竹島 友理、牟田口 大介 著)という書籍が、ソフトバンク クリエイティブから2009/07/30に発売予定です。私は1章と2章を執筆させていただきました。

おそらく国内では初の、PowerShell ver.2を使ったスクリプトベースでのWindowsサーバー管理ノウハウの書籍です。ぜひ本屋さんでお手に取ってみてください!

PowerShell ver.2はまだCTP3ですが、いずれWindows Server 2008をはじめ各種OS用のモジュールが提供される予定です。Windows Server 2008 R2とWindows 7ではPSv2が標準機能となっており、現在これらは製品版に近いRC版が公開されていますが、これに含まれるPSv2はほぼ完成しています。そのため、このバージョンのPSv2でも本初収録のスクリプトは動作することを確認しています。そのため、PSv2正式版が公開されてもこの本は問題なく使用できると思います。

# ただ一点だけ、Enable-PSRemotingというコマンドレットがCTPでは関数だったりps1ファイルだったり何となくまだ仕様が謎だったので、winrm quickconfigを使ってありますw

目次はこのような感じです。

第1章 Wndows PowerShellという環境
第2章 PowerShellの基礎知識
第3章 プロセスの管理
第4章 ActiveDirectoryとユーザー管理
第5章 システム情報の管理
第6章 サービスの管理
第7章 イベントログの管理
第8章 ExchangeServerの管理

元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/07/20/178462.aspx

2006/11/29

WMIクラスのインスタンスは簡単にGet-WMIObjectコマンドレットで取れますが、WMIのスタティックなメソッドを実行するにはどうすればいいのでしょう?

結論は.NETクラスのSystem.Management.ManagementClassをnew-objectしたインスタンスから呼べます。

(new-object System.Management.ManagementClass Win32_Process).create("not
epad")

このように、コンストラクタにWMIクラス名を指定します。例はnotepad.exeのプロセスを作成するというものですが、PowerShellではnotepadと入力するだけで実行できるのであまり適切な例とは言えませんが…

ついでに後片付け。notepad.exeを終了します。

gwmi Win32_Process|?{$_.processname -eq "notepad.exe"}|%{$_.terminate()}

betaの段階ではInvokeMethodメソッドを呼ばなければいけなかったようですが、正式版では直で呼べるようですね。ありがたや。

これもstop-process -name notepadでできるのであまり適切な例とは言えませんが…

元記事:http://blogs.wankuma.com/mutaguchi/archive/2006/11/29/47498.aspx

2006/07/14

.NET Framework 2.0にはタスクトレイにアイコンを表示させるためのクラス、NotifyIconクラスがあります。これを使ってみましょう。

function CreateNotifyIconMenu()
{
 # menuItem1オブジェクトの作成
 $menuItem1 = new-object System.Windows.Forms.MenuItem("終了(&X)")
 
 # Clickイベント
 $menuItem1.Add_Click({Form_Closing})
 
 # contextMenuオブジェクトの作成
 $contextMenu = new-object System.Windows.Forms.ContextMenu
 
 # menuItemオブジェクトをcontextMenuオブジェクトのMenuItemsコレクションに追加
 [void]$contextMenu.MenuItems.Add($menuItem1)
 #↑ここの[void]を忘れるとAddメソッドの戻り値がreturnされてしまう。
 
 return ($contextMenu)
}
function Form_Closing()
{
 # フォームとシステムトレイアイコンを非表示に
 $form.Visible = $false
 $notifyIcon.Visible = $false
 
 # PowerShellの終了
 [System.Environment]::Exit(0)
}
[void] [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") 
[void] [System.Windows.Forms.Application]::EnableVisualStyles()
# notifyIconオブジェクトの作成とプロパティの設定
$notifyIcon = new-object System.Windows.Forms.NotifyIcon
# System.Drawing.Iconクラスのコンストラクタにはicoファイルのパスを指定する
$notifyIcon.Icon = new-object System.Drawing.Icon C:\script\test\a.ico
$notifyIcon.Text = "PowerShell実行中"
$notifyIcon.ContextMenu = CreateNotifyIconMenu
$notifyIcon.Visible = $true
# formオブジェクトの作成
$form = new-object System.Windows.Forms.Form
# Closingイベント
$form.Add_Closing({Form_Closing})
# フォームの表示
[void]$form.showDialog()

理論上はフォームを表示させなくても良いはずなんですが、ループをまわすいい方法が思いつきませんでした(start-sleepを使うとその間イベントが実行されない)。あと、showDialogで表示したフォームを閉じるいい方法も思いつかなかったので[System.Environment]::Exit(0)
としてPowerShell自体のプロセスを終了させています(exitとやるとエラーが出るんですよね。なんでしょうこれは)。これらに対する良い解決策をお持ちの方は教えてください。

PowerShellのfunctionって引数がなしのとき、呼び出す際()を使うとエラーになるんですよね。あと、文頭に持ってこないといけないのも気に入りません。何とかならなかったのでしょうか…。

せっかくタスクトレイが使えるのに、フォームとコンソールまで表示されてしまいます。そこでWSHを併用してごまかす方法を。

Set WshShell=CreateObject("WScript.Shell")
WshShell.Run "powershell test.ps1",0

このようなvbsファイルを作ってps1ファイルをキックしてやります。Runメソッドの第二引数に0を指定すると、コンソールおよびフォームが非表示になりますが、タスクトレイは表示されます。この手を使うとまるでタスクトレイだけが表示されているかのような状態を作り出せます。ちなみに、MessageBoxも同じようにそれだけを表示させることができます。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2006/07/14/32470.aspx

新しい記事のページへ


Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Twitter

Books