An implementation of chrome.socket.secure().

chrome/browser/extensions/api/api_resource_manager.h

Index: chrome/browser/extensions/api/api_resource_manager.h
diff --git a/chrome/browser/extensions/api/api_resource_manager.h b/chrome/browser/extensions/api/api_resource_manager.h
index b459c2292b30c3fdf2ad3ea64dbd79b54b68081c..d3f0d17ea4abfe904fc2c7c4f1883b190b85a1f6 100644
--- a/chrome/browser/extensions/api/api_resource_manager.h
+++ b/chrome/browser/extensions/api/api_resource_manager.h
@@ -133,6 +133,10 @@ class ApiResourceManager : public ProfileKeyedAPI,
     return data_->GetResourceIds(extension_id);
   }
 
+  bool Set(const std::string& extension_id, int api_resource_id, T* resource) {
+    return data_->Set(extension_id, api_resource_id, resource);
+  }
+
  protected:
   // content::NotificationObserver:
   virtual void Observe(int type,
@@ -214,6 +218,18 @@ class ApiResourceManager : public ProfileKeyedAPI,
       return GetOwnedResource(extension_id, api_resource_id);
     }
 
+    bool Set(const std::string& extension_id,

[Ryan Sleevi, 2014/02/24 20:06:49]

I know this is not your code, and so the lack of documentation here is not a bug
you introduced.

However, I have a bit of trouble reasoning why Set() will only let you set an
api_resource_id iff there exists a previous resource with that same
api_resource_id.

If this is meant to be a compliment to ApiResourceData::Add(), then I believe
you should document both this method and on 136, to explain the correct usage.

Namely, that it exists to _replace_ an existing resource.

I'm going to have to defer to the extension OWNERs on the overall pattern, but
it does have the back hairs on my neck tingling that there may be an opportunity
for "confused deputy" attacks - in which a caller still has a pointer to an
older resource ID, and it wants to perform some action, and some security check
is made against the new object (eg: Returned by Get()). This is primarily
because of the linked_ptr<> pattern.

[lally, 2014/02/27 17:05:59]

I've renamed it Replace(), and documented that it requires that the resource ID
has to already exist and be owned by extension_id.  I *think* that different
extensions are firewalled by the different extension_ids, which are outside the
control of the relevant extensions -- does that help your concern about confused
deputies?

[lally, 2014/02/27 21:43:19]

I just checked with Renaud, yup, the extension_ids keep the extensions' state
separate from one another.

+             int api_resource_id,
+             T* api_resource) {
+      DCHECK(content::BrowserThread::CurrentlyOn(thread_id_));
+      T* old_resource = api_resource_map_[api_resource_id].get();
+      if (old_resource && extension_id == old_resource->owner_extension_id()) {
+        api_resource_map_[api_resource_id] = linked_ptr<T>(api_resource);
+        return true;
+      }
+      return false;
+    }
+
     base::hash_set<int>* GetResourceIds(const std::string& extension_id) {
       DCHECK(content::BrowserThread::CurrentlyOn(thread_id_));
       return GetOwnedResourceIds(extension_id);