Implement chrome.usb API Permissions.

Implement chrome.usb API Permissions.

This change introduces the concept of a permission that MUST be
optional.  The usbDevice permission is the first example of this type of
permission.

The permission is specified as a vendorId:productId pair, encoded as a
string.

BUG=123801
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=172271

[bryeung, 2012-12-10 22:23:10]

tsepez: for extension_messages*
sky: for DEPS/gypi changes
mpcomplete: for extensions changes
gdk: because it touches the USB API

[Tom Sepez, 2012-12-10 22:30:12]

In general, we'd be happier if you were passing the underlying members of the
struct using the IPC_STRUCT_TRAITS macros rather than sending strings to parse
with hand-written serializers.  Can it be done that way?

[Matt Perry, 2012-12-10 22:32:52]

Has the USB API undergone an extensions API review?

[bryeung, 2012-12-10 22:35:39]

On 2012/12/10 22:30:12, Tom Sepez wrote:
> In general, we'd be happier if you were passing the underlying members of the
> struct using the IPC_STRUCT_TRAITS macros rather than sending strings to parse
> with hand-written serializers.  Can it be done that way?

I've filed a bug to fix it , but I'm not that familiar with the uses of these
messages so I don't feel like I know enough to have an opinion.

As this is just copying the existing pattern, can we land it and have it get
fixed via the bug?

https://code.google.com/p/chromium/issues/detail?id=165267

[Tom Sepez, 2012-12-10 22:39:41]

LGTM for now, but please assign an owner to that bug and ensure it doesn't
languish.

[Matt Perry, 2012-12-10 23:16:43]

Is it possible with our permission system to specify permissions like "usb":
{vendorId: 432, productId: 99} ?

Maybe that's too verbose anyway.

LGTM.

https://codereview.chromium.org/11280311/diff/1/chrome/common/extensions/exte...
File chrome/common/extensions/extension.cc (right):

https://codereview.chromium.org/11280311/diff/1/chrome/common/extensions/exte...
chrome/common/extensions/extension.cc:1489: // Check for any permissions that
are optional only
nit: end with .

[bryeung, 2012-12-10 23:22:12]

On Mon, Dec 10, 2012 at 6:16 PM,  <[email protected]> wrote:
> Is it possible with our permission system to specify permissions like "usb":
> {vendorId: 432, productId: 99} ?

I was thinking about that too...

I'd prefer to proceed with this as-is, but I'll try to get a follow-up
CL in that changes both the Bluetooth API and this one to use objects
instead of strings before the M25 branch.

Bryan




>
> Maybe that's too verbose anyway.
>
> LGTM.
>
>
>
https://codereview.chromium.org/11280311/diff/1/chrome/common/extensions/exte...
> File chrome/common/extensions/extension.cc (right):
>
>
https://codereview.chromium.org/11280311/diff/1/chrome/common/extensions/exte...
> chrome/common/extensions/extension.cc:1489: // Check for any permissions
> that are optional only
> nit: end with .
>
> https://codereview.chromium.org/11280311/

[Matt Perry, 2012-12-10 23:27:29]

On 2012/12/10 23:22:12, bryeung wrote:
> On Mon, Dec 10, 2012 at 6:16 PM,  <mailto:[email protected]> wrote:
> > Is it possible with our permission system to specify permissions like "usb":
> > {vendorId: 432, productId: 99} ?
> 
> I was thinking about that too...
> 
> I'd prefer to proceed with this as-is, but I'll try to get a follow-up
> CL in that changes both the Bluetooth API and this one to use objects
> instead of strings before the M25 branch.
> 

Does that mean it's not possible to use complex objects yet?

[bryeung, 2012-12-10 23:31:41]

On Mon, Dec 10, 2012 at 6:27 PM,  <[email protected]> wrote:
> On 2012/12/10 23:22:12, bryeung wrote:
>
>> On Mon, Dec 10, 2012 at 6:16 PM,  <mailto:[email protected]> wrote:
>> > Is it possible with our permission system to specify permissions like
>> > "usb":
>> > {vendorId: 432, productId: 99} ?
>
>
>> I was thinking about that too...
>
>
>> I'd prefer to proceed with this as-is, but I'll try to get a follow-up
>> CL in that changes both the Bluetooth API and this one to use objects
>> instead of strings before the M25 branch.
>
>
>
> Does that mean it's not possible to use complex objects yet?

Sort of...the current API is converting to JSON and then the specific
permissions are created from the base::Values that results in (as of
this CL).

That means that internally, as an implementation detail, we're doing
the wrong thing.  But externally we could be using complex objects so
that the API interface is done The Right Way (TM).

There are some core features needed in json schema compiler and the
IDL parser before we can properly support complex objects as
first-class citizens in the API.
https://code.google.com/p/chromium/issues/detail?id=162042
https://code.google.com/p/chromium/issues/detail?id=162044

Bryan

[sky, 2012-12-11 00:06:29]

DEPS/*GYP LGTM

[commit-bot: I haz the power, 2012-12-11 01:28:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11280311/4002

[commit-bot: I haz the power, 2012-12-11 02:21:52]

Retried try job too often on linux_rel for step(s) unit_tests

[commit-bot: I haz the power, 2012-12-11 02:25:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11280311/5003

[commit-bot: I haz the power, 2012-12-11 07:18:17]

Change committed as 172271