我們假設你今天的 Facebook App，在某個按下按鈕的動作，或是某個 po 文的瞬間，因為當初 user 在 Facebook Login 時沒有給予你網站業務需求上應該需要的權限，而導致各種 error 或是 bla~bla~bla~ 等奇怪的頁面，你就需要額外去想辦法知道該 user 是否有給你應有的權限去做某件事情，進而做出適當的處理。
Example: 比方說你的某個功能需要幫 user 發文到塗鴉牆，照理說 user 應該要給你的 app 有 publish_action 的權限，但他沒有給，然而在 po 文的那刻才出錯，燈惹!~，因為你沒有去判斷他到底有沒有給你這個權限。
由於工程師在時程壓力下，大部份都會按照著心中認為順利的流程下去走，所以難免會遺漏掉這些不在正軌上的流程，往往會再發生問題那一刻才會想起來，對耶~ 忘記檔這個功能等等的內心 OS，其實我也是這樣，這是常態 XDD。
接下來就直接看 API 的部分:
/{user-id}/permission
/{user-id}/permission (/me/permissions) 這隻 Graph API 屬於 User 分類下面的 API， 我現在用的版本是 v2.x 的，過去 v1.0 也有這個 api，只是要到的資料格式不太一樣。
permission 僅供你兩個可用的 Method，Get 跟 Delete:
(一) GET
你用 GET (Reading) 的方式取拿取某個 user 針對你提出授權的項目的狀態，包含 granted 跟 declined (同意或是不同意)。
要到的資料為 permission 表示權限的名稱，以及 status 表示狀態，會用 enum 的方式列舉，不是 granted 就是 declined。
這是我用 Graph API Explorer 針對某隻 App 測試的結果:
{
"data": [
{
"permission": "public_profile",
"status": "granted"
},
{
"permission": "email",
"status": "granted"
},
{
"permission": "publish_actions",
"status": "granted"
},
{
"permission": "user_friends",
"status": "granted"
}
]
}
"data": [
{
"permission": "public_profile",
"status": "granted"
},
{
"permission": "email",
"status": "granted"
},
{
"permission": "publish_actions",
"status": "granted"
},
{
"permission": "user_friends",
"status": "granted"
}
]
}
如果要測試 declined，就要自己去 facebook app setting 找出該 app，把某個權限拿掉，ex: 拿掉該 app 的 publish_action:
然後再要一次 permission 的結果，就會拿到 declined:
通常如果取得 declined，在自己的 app 因為達不到某種功能，所以通常會有個訊息告訴 user 沒有給予適當的權限，可以先做 permission 確認再決定要不要繼續執行後面需要的 API。
(二) Delete
用來刪除某個權限。(我現在想不起來到底哪時候會用到這個...，我沒有經驗，所以無法多做說明。XD)
結論
permission 確認其實蠻方便的，我太晚知道這個功能了，問題是什麼時機點要 call 這個 API 以及這種資料該用何種方式存下來我倒是覺得比較傷腦筋，值得思考...。很可惜我沒這方面的經驗，無法分享 :P
參考
＊https://developers.facebook.com/docs/graph-api/reference/v2.2/user/permissions
相關文章
＊Facebook Graph API 升級到 v2.x
＊Facebook Graph API (v2.x) 之審核篇 - 標記朋友 Taggable Friends
沒有留言:
張貼留言
若你看的文章，時間太久遠的問題就別問了，因為我應該也忘了... XD