深刻理解Amazon Alexa Skill（二）

理解skill調用

本節來更詳細的討論alexa是如何肯定調用哪一個skill的。
參考：https://developer.amazon.com/zh/docs/custom-skills/understanding-how-users-invoke-custom-skills.html

明確調用（Specific Request (Intent)）

用戶在語音中明確的包含了要調用的skill的名字，雲會給skill發送一個帶有具體intent的 IntentRequest。用戶能夠有不少種表達方式來明確的調用skill，包括疑問句、祈使句等等，甚至不帶具體的請求內容只是呼喚skill的名字。這些都由Alexa來自動處理。Alexa預設了一些調用的表達方式，例如

<some action> <connecting word> <invocation name> e.g.「give me my Taurus horoscope using Daily Horoscopes」
Ask <invocation name> <connecting word> <some action> e.g.「Ask Daily Horoscopes to give me the horoscope for Taurus」
Start <invocation name> and <some action> e.g.「Start Daily Horoscopes and give me the horoscope for Taurus」

這裏主要潛在的安全問題就是skill的調用名稱的處理了，惡意skill要與正常skill爭奪誰被調用。

隱式調用（Name-free Interaction）（beta測試功能）

第二種比較有意思的是隱式調用，用戶不須要明確說出想要調用的skill，由Alexa來自動尋找調用合適的skill。大致流程以下：

1. 用戶作出請求行爲後，Alexa解析請求，並將請求發送給排名靠前的候選skill，向這些skill來發送CanFulfillIntentRequest 詢問是否能夠處理該intent。
2. 若是skill實現了canFulfillIntent，skill此時不該該作出任何實際操做，包括開關燈、播放音樂等等。
3. Alexa收集響應看哪一個skill合適，選擇後再發送IntentRequest給被選中的skill。
4. 收到IntentRequest的skill再回複用戶執行具體的操做。

因此，若是skill想要被隱式調用的話，就要實現CanFulfillIntentRequest接口，userId不會在調用這個接口的時候就傳入。這就至關於，Alexa會將用戶的intent廣播給全部註冊了的skill，彷佛發給惡意的skill會有一些隱私問題，雖然文檔說canFulfillIntent時不該該作出實際操做，可是skill此時是否能夠悄悄地發送用戶的intent? 官網中的CanFulfillIntentRequest 請求例子以下

{
  "request": {
    "type": "CanFulfillIntentRequest",
    "requestId": "...",
    "intent": {
      "name": "PlaySound",
      "slots": {
        "Sound": {
          "name": "Sound",
          "value": "crickets"
        }
      },
    },
    "locale": "en-US",
    "timestamp": "..."
  },
  "context": {
    "System": {
      "application": {
        "applicationId": "amzn1.ask.skill.<skill-id-value>"
      },
      "user": {
        "userId": "<user-id-value>"
      },
      "device": {
        "supportedInterfaces": {}
      }
    }
  },
  "version": "1.0"
}

skill須要使用canFulfillIntent來響應Alexa發出的CanFulfillIntentRequest，設置canFulfill = "YES"/"NO"/"MAYBE" 來代表本skill是否能處理這個用戶的intent。 這個徹底也是靠skill本身自覺來回應的，Alexa彷佛尚未能力來進一步的確認skill是否是真的有能力？此外，skill的響應和Alexa系統的請求是如何認證保證不被僞造的？
一個intent響應的例子以下：

{
    "version":"1.0",
    "response":{
        "canFulfillIntent": {
            "canFulfill": "YES",
            "slots":{
                "slotName1": {
                    "canUnderstand": "YES",
                    "canFulfill": "YES"
                },
               "slotName2": {
                    "canUnderstand": "YES",
                    "canFulfill": "YES"
                }
            }
        }
    }
}

亞馬遜文檔其實在這裏給出了答案。亞馬遜發來的JSON裏會攜帶一個Application ID，服務端skill的代碼要本身檢查發來的請求中的Application ID是否與本身Skill ID同樣，若是一致才執行，不一致就回復一個HTTP的400 Bad Request。也就是說Skill的ID是個祕密（像這樣amzn1.ask.skill.661ecf07-280b-41fe-8fe4-8c5fbCCCCCC）。所以，可否找到泄露的Skill ID，或者開發者是否忘記了檢查Skill ID，就是可否僞造Alexa調用Skill請求的關鍵了。