Flickr 也支援 OAuth Core 1.0a 了...

Flickr 宣佈支援 OAuth Core 1.0a 了:「Flickr now Supports OAuth 1.0a」,同時也宣佈舊的 API 將在 2012 年的上半年停用。文件在「User Authentication」這邊可以看到。

另外,除了推出新的 API 以外,Flickr 也提供用舊的 token 直接取得 OAuth Core 1.0a 的 access token 的 API call:

Transition from the old Authentication API

You can exchange an old auth token from the old Authentication API, to an OAuth access token token. The process simply requires that you make an authenticated request to the flickr.auth.oauth.getAccessToken API, which will exchange the old token used to make the request, with a new OAuth access token.

Please note, that the old auth token will be deleted 24 hours after calling this API method.

這個方法讓現有的應用可以直接轉換到新的 OAuth Core 1.0a API 上,不需要再認證一次。

Linode 也推出 Load balancer 服務... (剛開始 beta)

Linode 在「NodeBalancers - Managed Load Balancers」這邊公開了 NodeBalancer (lbass) 服務,目前在 beta 中,想要測試的人可以開 ticket 詢問。另外,API 文件也已經先公開,可以在「NodeBalancer API」這邊看到。

以 API 提供的功能看起來還算 okay,這樣就不需要自己用 Linode 提供的 IP Failover 並且在上面架 HAProxy server...

不過有些細節還是得等測試後才知道。像是 trusted IP 問題,我在「ELB 的 IP 信任問題...」有提過 EC2 的同樣問題 (前幾天用 ELB security group 解掉了)。

支援新版 Plurk API (OAuth Core 1.0a) 的 Twitter To Plurk Script

code 放在「Plurk 新版 OAuth Core 1.0a 的 twitter to plurk」,其中裡面用到的 SQLite 的表格結構請參考「Twitter 轉 Plurk 的程式...」這篇文章的說明。把本來是 plaintext password 的程式換過去後看起來舒服多了,不過中間寫起來讓人頗 orz...

先是一直沒辦法透過 OAuth::Lite 送出 UTF8 內容,於是決定換成 Net::OAuth,結果因為文件內的範例都沒講到重點而倒地不起...

然後遇到 Plurk API 2.0 beta 的文件沒有列出是 GET 或是 POST,於是又試了老半天...

文件真的很重要...

Plurk API:OAuth Core 1.0a

Plurk API 2.0 beta」總算是提供 OAuth Core 1.0a 介面讓人使用了,想把之前「Twitter 轉 Plurk 的程式...」的程式改寫,不過新的 API 不管怎麼註冊都不會過...

有人有註冊成功的嗎?

PS:另外「* 如果這不是一個網頁應用程式,請留空白即可」好像也怪怪的,我記得應該反過來?

AWS API 的認證方式

Amazon Web Services 有提供很多服務,有的早在「雲端風潮」前就有,有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後,只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 S3 的延伸,所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2,以及後來大多數的服務,都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53,又再引入了 REST 概念,但欄位名稱為 X-Amzn-Authorization,要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係,API 的設計讓人感覺頗疲倦... XD