12
edits
(Update Scenarios) |
|||
Line 14: | Line 14: | ||
** Can you update the page to reflect this, especially "Add-ons that do not provide either of the previous methods of retrieving a secure update manifest must not mark themselves as compatible with Firefox 3." and "When the user updates all add-ons that do not support secure updates will be disabled" and "Any other add-on authors have two options open to them"--[[User:Np|Np]] 14:34, 5 July 2007 (PDT) | ** Can you update the page to reflect this, especially "Add-ons that do not provide either of the previous methods of retrieving a secure update manifest must not mark themselves as compatible with Firefox 3." and "When the user updates all add-ons that do not support secure updates will be disabled" and "Any other add-on authors have two options open to them"--[[User:Np|Np]] 14:34, 5 July 2007 (PDT) | ||
== Update Scenarios == | |||
Can you confirm that these three scenarios are accurate and cover all possibilites? | |||
1. Suppose install.rdf contains an em:updateURL of http://foo.com/update.rdf. When FF retrieves the resource at http://foo.com/update.rdf, if the resource does not contain an em:updateHash element or the value of the em:updateHash element is incorrect, the update is not installed. | |||
2. Suppose install.rdf contains an em:updateURL of https://foo.com/update.rdf. When FF retrieves the resource at https://foo.com/update.rdf, FF will install the update even if no em:updateURL element exists (assuming there are no problems with the certificate for foo.com). If, however, em:updateHash does exist, it is checked for validity against the update. | |||
3. Suppose install.rdf contains no updateURL. FF EM exclusively contacts AMO via https:// for updates. | |||
--[[User:Grimholtz|Grimholtz]] 12:18, 9 July 2007 (PDT) |
edits