2012-08-06 40 views
4

我一直在爲我的公司開發和維護一個Chrome擴展程序,其中每位客戶都會在代碼中分配一個唯一的ID。我們一直在使用該ID來確定許可證狀態並登錄我們的服務(按月收費收費的延期付款)。Chrome網上應用店的擴展程序的用戶特定版本

到目前爲止,我們自己託管了擴展文件,併爲每個客戶擴展都有獨特的更新URL。這很好,很簡單;去我們的網站,點擊安裝,你就完成了。然而,在最新的Chrome版本中,Google的這一安裝過程受到阻礙,因爲他們現在要求用戶通過將CRX文件拖放到chrome:// chrome/extensions/tab來安裝擴展。當然,除非你的擴展,可通過Chrome網上應用店 - 這使我的問題:

  • 我們不想拖放CRX安裝 - 需要網上商店。
  • 我們不希望Web Store上的擴展的多個版本(每個客戶一個),因爲每次我們更新擴展時,這都是一個維護地獄。
  • 我們不想使用網上應用店授權,因爲:
    • 它需要OpenID登錄。
    • 我們向許多學生出售學校支付學費的擴展 - 而不是學生。
    • 我們不希望將我們的付款方式鎖定到一個瀏覽器,即我們希望能夠通過我們或服務器維持許可和付款。
  • 我們不希望用戶輸入許可證密鑰,因爲數千名學生不得不輸入密鑰的風險太大 - 還需要某種存儲器(cookies/localStorage)被清除,需要再次輸入許可證密鑰。

我不是100%肯定,我的發言是完全正確的,所以不吝賜教我,如果我錯過了什麼。

如果是這樣,問題是我們是否可以通過Web商店(使用唯一ID)爲每個客戶定製擴展程序,而無需爲每個ID發佈一個擴展?

作爲一個側面問題,任何可能解決與另一種方法的問題的答案也將被接受。

+0

關於localStorage:您的應用程序的localStorage不會被清除,除非您的應用程序執行此操作(您將知道發生了什麼並且可以正確處理它),或者您的用戶從JS控制檯執行它(在這種情況下他會知道它打破了,因爲他在JS控制檯上瞎忙)。應用程序localStorage永遠不會被瀏覽器任意清除 - 即使用戶擦除了所有localStorage(https://code.google.com/p/chromium/issues/detail?id=36550)(請注意鏈接的bug被標記爲「WontFix」)。然而,數千名學生輸入許可證密鑰是另一個問題。 – apsillers 2012-08-06 13:35:55

回答

2

對於下面的答案,我假設你的應用程序是打包應用程序,而不是託管應用程序。

我有一個與您當前的實現非常相似的解決方案,但爲用戶添加了一個額外的步驟。對於學生用戶,該過程將如下工作:

  1. 從網上應用店下載應用程序。該應用程序尚未運行,並啓動它只顯示「請點擊您的學校/機構提供的激活鏈接」消息。
  2. 點擊託管服務器上的鏈接(即,您用來承載更新URL服務器),看起來像https://myserver.com/activateapp.php?custid=123456789。您爲您支持的每個機構提供一個這樣的鏈接,並且提供與學生的鏈接是機構的工作。此鏈接激活應用程序。

從觀看的實施點,這裏是它的工作原理是:

  1. 主機頁面,https://myserver.com/activateapp.php,您的服務器上。在服務器端,檢查參數custid是否有效。如果不是,則發送404錯誤。
  2. 您的應用程序有一個內容腳本,它被注入到https://myserver.com/activateapp.php中,該腳本掃描URL並挑選出客戶ID。一旦應用程序找到該ID,它就會將其存儲在localStorage中。由於無效的客戶ID會產生404錯誤,因此您知道當內容腳本運行時,該頁面不是404錯誤;因此,它正在讀取有效的客戶ID。
  3. 任何時候應用程序想要查詢您的服務,它會檢查它是否在localStorage中有一個客戶ID。如果有,它使用該ID;如果沒有,它會顯示一條消息,說明該應用尚未激活。除非您的應用程序被編程爲擦除自己的存儲空間,或者用戶通過控制檯執行,否則打包的應用程序將永遠不會刪除其localStorage。存儲擦除永遠不會「意外」發生。即使是最強大的瀏覽器範圍內的數據/緩存清除,也只會從網頁中清除localStorage,而不會從應用和擴展中清除。

爲了提高安全性 - 如果您不想讓用戶隨機猜測客戶ID,您可以添加額外的簽名參數,如https://myserver.com/activateapp.php?custid=123456789&sig=2464509243。這個額外的參數是客戶ID(理想情況下是加密簽名或與數據庫中的ID相關聯的純隨機值)的經服務器驗證的變換,這是任何人都不可能猜到的。當activateapp.php的請求到達服務器時,它會檢查有效的客戶ID 有效的相應簽名。當然,這並不會阻止那些合法訪問有效鏈接的人將鏈接分享給未經授權的人,但我認爲這是舊系統中存在的一個漏洞。

+0

我建議在'localStorage'上使用['chrome.storage.sync'](http://code.google.com/chrome/extensions/storage.html#property-sync),因爲它允許用戶使用使用Google同步時,多臺計算機擁有相同的憑據。 – 2012-08-06 14:28:49

+0

我的老闆批准這種方法。出於好奇,你會如何避免將擴展與共享激活鏈接一樣簡單? – Woodgnome 2012-08-07 10:25:55

+0

我能想到的唯一真正的安全選項是用戶在登錄頁面(例如'enterpass.php?custid = ...')輸入的機構範圍用戶名/密碼:1)HTTP身份驗證或2)然後用作爲POST數據傳遞給激活頁面的用戶名和密碼重定向到'activateapp.php'。在#2下,如果POST數據是正確的,'activateapp.php'只會返回'200 OK'響應,除了檢查有效的'custid'。 – apsillers 2012-08-07 12:28:32

相關問題