[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman wrote:

>
>
> On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman wrote:
>
>>
>>
>> On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote:
>>
>>> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman 
>>> wrote:
>>>


 On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote:

> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote:
>
>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
>> wrote:
>> > As mentioned f2f, this falls apart as soon as Chrome tries to
>> manufacture a
>> > security origin. I'm not sure, may already have instances of that in
>> the
>> > code base for all I know.
>>
>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
>> There's a lot of tricky work in the canonicalization that we don't
>> want to duplicate.
>>
>> Adam
>>
>
>
> Agreed, and we shouldn't be in that business.  I think for all our use
> cases, the
> factory for security origins can be WebCore.
>
> Chrome just needs to be able to serialize / de-serialize a security
> origin, compare
> them, and possibly access some component parts (though I'm not certain
> of this
> requirement).
>

 I think i have use cases for creating an 'origin' based on a GURL.

>>>
>>> We've talked through these repeatedly and I think we've made good cases
>>> against them.  WebCore canonicalizes security origins.  At the moment, we
>>> never create "security origins" in Chrome.
>>>
>>
>> I wasn't implying that webcore's origin code wasn't doing the work, just
>> mentioning the use case of determining an origin based on a url. Something
>> like this could work.
>>
>> // Returns the security origin associated with the given url.
>> (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url);
>>
>>
>>> You've given some examples of where we _might_ (read: this is vaporware)
>>> do this in the future.  For all the use cases I've seen so far, I would
>>> actually propose adding a canonicalizeSecurityOrigin() method to
>>> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
>>> immediately toString() it.
>>>
>>
>>> What other use cases are there?  With each one, please make clear whether
>>> it's something we need today or whether it's something you suspect we'll
>>> need in the future...because I think most if not all of them are in this
>>> second bucket.  And I don't want us to code ourselves into a corner, but I
>>> also don't want us to write a bunch of dead code that may be used in the
>>> future.
>>>
>>
>> The use case is tracking usage per-origin in the appcache code. This isn't
>> a hypothetical thing.
>>
>
> And also restricting access to resources based on origins, also not a
> hypothetical thing.
>

I don't think I ever used the word "hypothetical".

Anyway, I think the WebSecurityOrigin::fromURL(blah)->toString() will work
fine in this use case.  But I might create a static method that's a shortcut
for that just to make it super obvious to users.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman wrote:

>
>
> On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote:
>
>> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
> wrote:
> > As mentioned f2f, this falls apart as soon as Chrome tries to
> manufacture a
> > security origin. I'm not sure, may already have instances of that in
> the
> > code base for all I know.
>
> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
> There's a lot of tricky work in the canonicalization that we don't
> want to duplicate.
>
> Adam
>


 Agreed, and we shouldn't be in that business.  I think for all our use
 cases, the
 factory for security origins can be WebCore.

 Chrome just needs to be able to serialize / de-serialize a security
 origin, compare
 them, and possibly access some component parts (though I'm not certain
 of this
 requirement).

>>>
>>> I think i have use cases for creating an 'origin' based on a GURL.
>>>
>>
>> We've talked through these repeatedly and I think we've made good cases
>> against them.  WebCore canonicalizes security origins.  At the moment, we
>> never create "security origins" in Chrome.
>>
>
> I wasn't implying that webcore's origin code wasn't doing the work, just
> mentioning the use case of determining an origin based on a url. Something
> like this could work.
>
> // Returns the security origin associated with the given url.
> (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url);
>
>
>> You've given some examples of where we _might_ (read: this is vaporware)
>> do this in the future.  For all the use cases I've seen so far, I would
>> actually propose adding a canonicalizeSecurityOrigin() method to
>> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
>> immediately toString() it.
>>
>
>> What other use cases are there?  With each one, please make clear whether
>> it's something we need today or whether it's something you suspect we'll
>> need in the future...because I think most if not all of them are in this
>> second bucket.  And I don't want us to code ourselves into a corner, but I
>> also don't want us to write a bunch of dead code that may be used in the
>> future.
>>
>
> The use case is tracking usage per-origin in the appcache code. This isn't
> a hypothetical thing.
>

And also restricting access to resources based on origins, also not a
hypothetical thing.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow  wrote:

> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote:
>
>>
>>
>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:
>>>
 On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
 wrote:
 > As mentioned f2f, this falls apart as soon as Chrome tries to
 manufacture a
 > security origin. I'm not sure, may already have instances of that in
 the
 > code base for all I know.

 I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
 There's a lot of tricky work in the canonicalization that we don't
 want to duplicate.

 Adam

>>>
>>>
>>> Agreed, and we shouldn't be in that business.  I think for all our use
>>> cases, the
>>> factory for security origins can be WebCore.
>>>
>>> Chrome just needs to be able to serialize / de-serialize a security
>>> origin, compare
>>> them, and possibly access some component parts (though I'm not certain of
>>> this
>>> requirement).
>>>
>>
>> I think i have use cases for creating an 'origin' based on a GURL.
>>
>
> We've talked through these repeatedly and I think we've made good cases
> against them.  WebCore canonicalizes security origins.  At the moment, we
> never create "security origins" in Chrome.
>

I wasn't implying that webcore's origin code wasn't doing the work, just
mentioning the use case of determining an origin based on a url. Something
like this could work.

// Returns the security origin associated with the given url.
(Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url);


> You've given some examples of where we _might_ (read: this is vaporware) do
> this in the future.  For all the use cases I've seen so far, I would
> actually propose adding a canonicalizeSecurityOrigin() method to
> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
> immediately toString() it.
>

> What other use cases are there?  With each one, please make clear whether
> it's something we need today or whether it's something you suspect we'll
> need in the future...because I think most if not all of them are in this
> second bucket.  And I don't want us to code ourselves into a corner, but I
> also don't want us to write a bunch of dead code that may be used in the
> future.
>

The use case is tracking usage per-origin in the appcache code. This isn't a
hypothetical thing.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
>>> wrote:
>>> > As mentioned f2f, this falls apart as soon as Chrome tries to
>>> manufacture a
>>> > security origin. I'm not sure, may already have instances of that in
>>> the
>>> > code base for all I know.
>>>
>>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
>>> There's a lot of tricky work in the canonicalization that we don't
>>> want to duplicate.
>>>
>>> Adam
>>>
>>
>>
>> Agreed, and we shouldn't be in that business.  I think for all our use
>> cases, the
>> factory for security origins can be WebCore.
>>
>> Chrome just needs to be able to serialize / de-serialize a security
>> origin, compare
>> them, and possibly access some component parts (though I'm not certain of
>> this
>> requirement).
>>
>
> I think i have use cases for creating an 'origin' based on a GURL.
>

We've talked through these repeatedly and I think we've made good cases
against them.  WebCore canonicalizes security origins.  At the moment, we
never create "security origins" in Chrome.

You've given some examples of where we _might_ (read: this is vaporware) do
this in the future.  For all the use cases I've seen so far, I would
actually propose adding a canonicalizeSecurityOrigin() method to
WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
immediately toString() it.

What other use cases are there?  With each one, please make clear whether
it's something we need today or whether it's something you suspect we'll
need in the future...because I think most if not all of them are in this
second bucket.  And I don't want us to code ourselves into a corner, but I
also don't want us to write a bunch of dead code that may be used in the
future.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:
>
>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
>> wrote:
>> > As mentioned f2f, this falls apart as soon as Chrome tries to
>> manufacture a
>> > security origin. I'm not sure, may already have instances of that in the
>> > code base for all I know.
>>
>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
>> There's a lot of tricky work in the canonicalization that we don't
>> want to duplicate.
>>
>> Adam
>>
>
>
> Agreed, and we shouldn't be in that business.  I think for all our use
> cases, the
> factory for security origins can be WebCore.
>
> Chrome just needs to be able to serialize / de-serialize a security
> origin, compare
> them, and possibly access some component parts (though I'm not certain of
> this
> requirement).
>

I think i have use cases for creating an 'origin' based on a GURL.


>
> -Darin
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

I guess you're rightabout pretty much everything.
I'll put it in chrome/common then?  (Note I actually wasn't planning on
putting it in base unless the API depended on it, but it seemed like
including that would just make what I was saying more confusing.)

On Thu, Oct 15, 2009 at 12:19 AM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow  wrote:
>
>> I think the main points of contention regarding SecurityOrigin::toString()
>> are the name "toString" and what type it should return.
>>
>> In terms of the names:  I think we should provide constructors and getters
>> for each "component" of each WebKit API type.  So, for example,
>> WebSecurityOrigin should have a constructor that takes in a single string
>> and a getter called |origin|.
>>
>
> It seems strange for something that is an origin to have a getter named
> origin.  It leads to code like this: origin->origin(), which seems bad to
> me.
>
> toString() is the name used by WebCore, and it seems reasonable to me.  It
> is merely a method that returns a string representation of the
> SecurityOrigin suitable for pickling.  What is your objection to toString?
>
>
>
>>  (We can argue about the name later.)  base::SecurityOrigin
>>
>
> I mentioned before that base is not the right place for SecurityOrigin.
>  See Brett's posts about what should and shouldn't be part of base/.  It is
> a dumping ground today, and we should resist more of that will full force.
>  In this case, only webkit/glue and above needs this type, so it does not
> need to live in base/.
>
>
>
>> can then have a method to produce WebSecurityOrigins (using that
>> constructor that takes in the base componentswhich is just "origin" in
>> this classes case) and it can have a constructor that takes in a
>> WebSecurityOrigin (which will construct itself by using the aforementioned
>> getter(s)).
>>
>
> This seems fine to me provided we actually need WebSecurityOrigin or
> SecurityOrigin to expose the component parts.  However, I haven't seen any
> use cases for that yet.  Maybe I have missed them?
>
>
>
>>
>> In terms of what it should return:  Each "component" should really be a
>> C++ primitive.  This of course leaves the question of how to handle strings.
>>  Personally, I think we should do one of 2 things:  Either WebString should
>> expose its components (an array of unsigned shorts + a size_t)
>>
>
> WebString already has accessors for the array of unsigned shorts and a
> size_t for the length.
>
>
>
>> or we should just put string16 into the WebKit API.  The latter is not as
>> insane as it sounds: it's just a special case of std::string.  The former
>> isn't that insane either since it can be fed directly to a std::string(16)
>> constructor.
>>
>
> The WebKit API is intended to be usable by consumers who do not have a full
> STL implementation (e.g., Android).
>
>
>
>>
>> If we add the proper constructors and factories for WebKit types to
>> NullableString16, GURL, SecurityOrigin, and any other types we might want to
>> connect to WebKit types in the future, then we can actually make the
>> dependency 100% one way.
>>
>
> It is OK for the WebKit API to know about GURL since WebCore depends on
> googleurl (specifically the generic, implementation bits).  However, since
> GURL uses STL, there is just an optional (#ifdef controlled) conversion
> helper on WebURL for it.
>
> The same does not apply for NullableString16 or SecurityOrigin.
>
>
>
>>
>> I guess I feel like we should either say that depending on base types is
>> OK (as long as we think they'll be very stable implementation wise) or we
>> should say they're never allowed.  This middle ground just feels wrong.
>>  Note that the difference between toString and a single getter that returns
>> a string is subtle, but if all WebKit types follow this same convention,
>> then it's much less likely that people will do stupid things with them.
>>
>>
> I generally prefer all or nothing approaches too, but the implicit
> conversions to string16 and std::string are extremely nice.  I don't want to
> give them up.  At the same time, I object to building further dependencies
> on base from svn.webkit.org.
>
> NullableString16 seemed like a reasonable addition since it is just a
> slight variant of string16 that we can probably afford to treat as frozen.
>
> -Darin
>
>
>
>
>> J
>>
>>
>> On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow wrote:
>>>
 You mean string16, right?
>>>
>>>
>>> I see instances of std::string and string16.  I would be happiest if we
>>> unified on one.  string16 is probably the path of least resistance.
>>>
>>>  std::string has the benefit of being more compact, which for something
>>> like this which is really just a bag of bytes is probably a good thing.
>>>
>>>
>>>

 I really don't think it buys us much if it's purely optional that people
 put the security origin (in string representation) into a wrapper that then
>

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow  wrote:

> I think the main points of contention regarding SecurityOrigin::toString()
> are the name "toString" and what type it should return.
>
> In terms of the names:  I think we should provide constructors and getters
> for each "component" of each WebKit API type.  So, for example,
> WebSecurityOrigin should have a constructor that takes in a single string
> and a getter called |origin|.
>

It seems strange for something that is an origin to have a getter named
origin.  It leads to code like this: origin->origin(), which seems bad to
me.

toString() is the name used by WebCore, and it seems reasonable to me.  It
is merely a method that returns a string representation of the
SecurityOrigin suitable for pickling.  What is your objection to toString?



>  (We can argue about the name later.)  base::SecurityOrigin
>

I mentioned before that base is not the right place for SecurityOrigin.  See
Brett's posts about what should and shouldn't be part of base/.  It is a
dumping ground today, and we should resist more of that will full force.  In
this case, only webkit/glue and above needs this type, so it does not need
to live in base/.



> can then have a method to produce WebSecurityOrigins (using that
> constructor that takes in the base componentswhich is just "origin" in
> this classes case) and it can have a constructor that takes in a
> WebSecurityOrigin (which will construct itself by using the aforementioned
> getter(s)).
>

This seems fine to me provided we actually need WebSecurityOrigin or
SecurityOrigin to expose the component parts.  However, I haven't seen any
use cases for that yet.  Maybe I have missed them?



>
> In terms of what it should return:  Each "component" should really be a C++
> primitive.  This of course leaves the question of how to handle strings.
>  Personally, I think we should do one of 2 things:  Either WebString should
> expose its components (an array of unsigned shorts + a size_t)
>

WebString already has accessors for the array of unsigned shorts and a
size_t for the length.



> or we should just put string16 into the WebKit API.  The latter is not as
> insane as it sounds: it's just a special case of std::string.  The former
> isn't that insane either since it can be fed directly to a std::string(16)
> constructor.
>

The WebKit API is intended to be usable by consumers who do not have a full
STL implementation (e.g., Android).



>
> If we add the proper constructors and factories for WebKit types to
> NullableString16, GURL, SecurityOrigin, and any other types we might want to
> connect to WebKit types in the future, then we can actually make the
> dependency 100% one way.
>

It is OK for the WebKit API to know about GURL since WebCore depends on
googleurl (specifically the generic, implementation bits).  However, since
GURL uses STL, there is just an optional (#ifdef controlled) conversion
helper on WebURL for it.

The same does not apply for NullableString16 or SecurityOrigin.



>
> I guess I feel like we should either say that depending on base types is OK
> (as long as we think they'll be very stable implementation wise) or we
> should say they're never allowed.  This middle ground just feels wrong.
>  Note that the difference between toString and a single getter that returns
> a string is subtle, but if all WebKit types follow this same convention,
> then it's much less likely that people will do stupid things with them.
>
>
I generally prefer all or nothing approaches too, but the implicit
conversions to string16 and std::string are extremely nice.  I don't want to
give them up.  At the same time, I object to building further dependencies
on base from svn.webkit.org.

NullableString16 seemed like a reasonable addition since it is just a slight
variant of string16 that we can probably afford to treat as frozen.

-Darin




> J
>
>
> On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow wrote:
>>
>>> You mean string16, right?
>>
>>
>> I see instances of std::string and string16.  I would be happiest if we
>> unified on one.  string16 is probably the path of least resistance.
>>
>>  std::string has the benefit of being more compact, which for something
>> like this which is really just a bag of bytes is probably a good thing.
>>
>>
>>
>>>
>>> I really don't think it buys us much if it's purely optional that people
>>> put the security origin (in string representation) into a wrapper that then
>>> blocks them from doing anything silly with it.
>>>
>>
>> we could give it a ToString() method.  i think the point of SecurityOrigin
>> would be to guide people in the right direction.
>>
>> -darin
>>
>>
>>
>>>
>>> More to the point, I don't think it's useful enough that I'm going to
>>> bother implementing it.  If someone else wants to, I'd probably use it.
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher wrote:
>>>
 To be clear:  I only weakly advocate Ch

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

I think the main points of contention regarding SecurityOrigin::toString()
are the name "toString" and what type it should return.

In terms of the names:  I think we should provide constructors and getters
for each "component" of each WebKit API type.  So, for example,
WebSecurityOrigin should have a constructor that takes in a single string
and a getter called |origin|.  (We can argue about the name later.)
 base::SecurityOrigin can then have a method to produce WebSecurityOrigins
(using that constructor that takes in the base componentswhich is just
"origin" in this classes case) and it can have a constructor that takes in a
WebSecurityOrigin (which will construct itself by using the aforementioned
getter(s)).

In terms of what it should return:  Each "component" should really be a C++
primitive.  This of course leaves the question of how to handle strings.
 Personally, I think we should do one of 2 things:  Either WebString should
expose its components (an array of unsigned shorts + a size_t) or we should
just put string16 into the WebKit API.  The latter is not as insane as it
sounds: it's just a special case of std::string.  The former isn't that
insane either since it can be fed directly to a std::string(16) constructor.

If we add the proper constructors and factories for WebKit types to
NullableString16, GURL, SecurityOrigin, and any other types we might want to
connect to WebKit types in the future, then we can actually make the
dependency 100% one way.

I guess I feel like we should either say that depending on base types is OK
(as long as we think they'll be very stable implementation wise) or we
should say they're never allowed.  This middle ground just feels wrong.
 Note that the difference between toString and a single getter that returns
a string is subtle, but if all WebKit types follow this same convention,
then it's much less likely that people will do stupid things with them.

J


On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow  wrote:
>
>> You mean string16, right?
>
>
> I see instances of std::string and string16.  I would be happiest if we
> unified on one.  string16 is probably the path of least resistance.
>
>  std::string has the benefit of being more compact, which for something
> like this which is really just a bag of bytes is probably a good thing.
>
>
>
>>
>> I really don't think it buys us much if it's purely optional that people
>> put the security origin (in string representation) into a wrapper that then
>> blocks them from doing anything silly with it.
>>
>
> we could give it a ToString() method.  i think the point of SecurityOrigin
> would be to guide people in the right direction.
>
> -darin
>
>
>
>>
>> More to the point, I don't think it's useful enough that I'm going to
>> bother implementing it.  If someone else wants to, I'd probably use it.
>>
>>
>> On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher  wrote:
>>
>>> To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
>>> also OKwith just using std::string.  I think either is better than using
>>> GURL.
>>>
>>> -Darin
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher wrote:
>>>
 Hmm... it seems useful as a means of making the code more
 self-documenting anda bit safer.  I'd rather not have people passing
 strings for origins since they might be
 tempted to parse the strings.

 The momentary translation to strings on the boundary of the WebKit API
 does not
 completely make this fragile.  If the end-points in Chrome use
 SecurityOrigin and
 the end-points in the WebKit API use WebSecurityOrigin, then developers
 will be
 naturally inclined to convert between SecurityOrigin and
 WebSecurityOrigin,
 ignoring the toString() getter on WebSecurityOrigin.

 This is a case where existing code should help guide people in the right
 direction.

 -Darin



 On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow wrote:

> If this is the case, then I don't think a SecurityOrigin wrapper buys
> us anything.  Never mind.
>
>
> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher wrote:
>
>>
>>
>> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher 
 wrote:

> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow  > wrote:
>
>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher > > wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow <
>>> jor...@chromium.org> wrote:
>>>
 On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
 micha...@google.com> wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow  wrote:

> You mean string16, right?


I see instances of std::string and string16.  I would be happiest if we
unified on one.  string16 is probably the path of least resistance.

std::string has the benefit of being more compact, which for something like
this which is really just a bag of bytes is probably a good thing.



>
> I really don't think it buys us much if it's purely optional that people
> put the security origin (in string representation) into a wrapper that then
> blocks them from doing anything silly with it.
>

we could give it a ToString() method.  i think the point of SecurityOrigin
would be to guide people in the right direction.

-darin



>
> More to the point, I don't think it's useful enough that I'm going to
> bother implementing it.  If someone else wants to, I'd probably use it.
>
>
> On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher  wrote:
>
>> To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
>> also OKwith just using std::string.  I think either is better than using
>> GURL.
>>
>> -Darin
>>
>>
>> On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher  wrote:
>>
>>> Hmm... it seems useful as a means of making the code more
>>> self-documenting anda bit safer.  I'd rather not have people passing
>>> strings for origins since they might be
>>> tempted to parse the strings.
>>>
>>> The momentary translation to strings on the boundary of the WebKit API
>>> does not
>>> completely make this fragile.  If the end-points in Chrome use
>>> SecurityOrigin and
>>> the end-points in the WebKit API use WebSecurityOrigin, then developers
>>> will be
>>> naturally inclined to convert between SecurityOrigin and
>>> WebSecurityOrigin,
>>> ignoring the toString() getter on WebSecurityOrigin.
>>>
>>> This is a case where existing code should help guide people in the right
>>> direction.
>>>
>>> -Darin
>>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow wrote:
>>>
 If this is the case, then I don't think a SecurityOrigin wrapper buys us
 anything.  Never mind.


 On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher wrote:

>
>
> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:
>
>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow 
 wrote:

> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher 
> wrote:
>
>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow <
>> jor...@chromium.org> wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>> micha...@google.com> wrote:
>>>
 +1 SecurityOrigin class
 Sounds like a reasonable plan.
 I suspect there may already be cases where we're actually
 comparing a chrome generated security origin, as produced by
 GURL.GetOrigin(), with a webkit generated security origin, as 
 produced by
 WebSecurityOrigin.toString(). So we may want to accelerate the 
 part of the
 plan to do more than opaquely pass around and test webkit generated
 representations.

 Also, I think dumi has a use case to crack it open in order to
 form file path elements of the form 'scheme_host_port'

>>>
>>> Actually, Dumi's case is slightly different.  He wants to get
>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>> should
>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>
>>
>> Dumi has such a method in a CL that he is working on at the
>> moment.  Also, note: we don't have a way to use FilePath from the 
>> WebKit
>> API, and I'm not sure that we should.  We use WebString for file 
>> paths in
>> the WebKit API.
>>
>
> So then he's adding such a method to WebSecurityOrigin that returns
> a string?  If so, sounds good.  What's the CL, btw?
>

 Yes:
 http://codereview.chromium.org/256073/diff/11001/11029



>
>
>>  ... and why not use strings?
 * does the string contain a trailing slash, or not?
 * in the default port case, does the string contain the default
 port number or not?

>>>
>>> WebCore::SecurityOrigin handles these for us.  I'll make it
>>> difficult for a base::SecurityOrigin to be constructed any way 
>>> besides it
>>> coming from WebKit::WebSecurityOrigin (which only comes from
>>> WebCore::WebSecurityOrigin).  We can then deal with these details 
>>> only
>>> if/when we need to.
>>>
>>>
>>> On

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

You mean string16, right?
I really don't think it buys us much if it's purely optional that people put
the security origin (in string representation) into a wrapper that then
blocks them from doing anything silly with it.

More to the point, I don't think it's useful enough that I'm going to bother
implementing it.  If someone else wants to, I'd probably use it.

On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher  wrote:

> To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
> also OKwith just using std::string.  I think either is better than using
> GURL.
>
> -Darin
>
>
> On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher  wrote:
>
>> Hmm... it seems useful as a means of making the code more self-documenting
>> anda bit safer.  I'd rather not have people passing strings for origins
>> since they might be
>> tempted to parse the strings.
>>
>> The momentary translation to strings on the boundary of the WebKit API
>> does not
>> completely make this fragile.  If the end-points in Chrome use
>> SecurityOrigin and
>> the end-points in the WebKit API use WebSecurityOrigin, then developers
>> will be
>> naturally inclined to convert between SecurityOrigin and
>> WebSecurityOrigin,
>> ignoring the toString() getter on WebSecurityOrigin.
>>
>> This is a case where existing code should help guide people in the right
>> direction.
>>
>> -Darin
>>
>>
>>
>> On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow wrote:
>>
>>> If this is the case, then I don't think a SecurityOrigin wrapper buys us
>>> anything.  Never mind.
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher wrote:
>>>


 On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:
>
>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow 
>>> wrote:
>>>
 On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher 
 wrote:

> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  > wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>> micha...@google.com> wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually
>>> comparing a chrome generated security origin, as produced by
>>> GURL.GetOrigin(), with a webkit generated security origin, as 
>>> produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part 
>>> of the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to
>>> form file path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>> should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi has such a method in a CL that he is working on at the moment.
>  Also, note: we don't have a way to use FilePath from the WebKit API, 
> and
> I'm not sure that we should.  We use WebString for file paths in the 
> WebKit
> API.
>

 So then he's adding such a method to WebSecurityOrigin that returns
 a string?  If so, sounds good.  What's the CL, btw?

>>>
>>> Yes:
>>> http://codereview.chromium.org/256073/diff/11001/11029
>>>
>>>
>>>


>  ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default
>>> port number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it
>> difficult for a base::SecurityOrigin to be constructed any way 
>> besides it
>> coming from WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details 
>> only
>> if/when we need to.
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow <
>>> jor...@chromium.org> wrote:
>>>
 Right now, we don't have a good story for what to do with
 WebCore::SecurityOrigins in Chromium.  We now have a 
 WebSecurityOrigin in
 WebKit, but if you want to move the data between processes, you 
 need to
 convert it to a string and then send that.  In some cases we then 
 convert
 the string to a GURL, but this seems like the wrong thing to do 
 (more on
 this in a sec).
 To me, the right answer is t

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
also OKwith just using std::string.  I think either is better than using
GURL.

-Darin

On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher  wrote:

> Hmm... it seems useful as a means of making the code more self-documenting
> anda bit safer.  I'd rather not have people passing strings for origins
> since they might be
> tempted to parse the strings.
>
> The momentary translation to strings on the boundary of the WebKit API does
> not
> completely make this fragile.  If the end-points in Chrome use
> SecurityOrigin and
> the end-points in the WebKit API use WebSecurityOrigin, then developers
> will be
> naturally inclined to convert between SecurityOrigin and WebSecurityOrigin,
> ignoring the toString() getter on WebSecurityOrigin.
>
> This is a case where existing code should help guide people in the right
> direction.
>
> -Darin
>
>
>
> On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow  wrote:
>
>> If this is the case, then I don't think a SecurityOrigin wrapper buys us
>> anything.  Never mind.
>>
>>
>> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher  wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:
>>>
 On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:

> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>
>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow 
 wrote:

> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
> micha...@google.com> wrote:
>
>> +1 SecurityOrigin class
>> Sounds like a reasonable plan.
>> I suspect there may already be cases where we're actually
>> comparing a chrome generated security origin, as produced by
>> GURL.GetOrigin(), with a webkit generated security origin, as 
>> produced by
>> WebSecurityOrigin.toString(). So we may want to accelerate the part 
>> of the
>> plan to do more than opaquely pass around and test webkit generated
>> representations.
>>
>> Also, I think dumi has a use case to crack it open in order to
>> form file path elements of the form 'scheme_host_port'
>>
>
> Actually, Dumi's case is slightly different.  He wants to get
> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
> should
> have a databaseIdentifier() method that outputs a FilePath object?
>

 Dumi has such a method in a CL that he is working on at the moment.
  Also, note: we don't have a way to use FilePath from the WebKit API, 
 and
 I'm not sure that we should.  We use WebString for file paths in the 
 WebKit
 API.

>>>
>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>> string?  If so, sounds good.  What's the CL, btw?
>>>
>>
>> Yes:
>> http://codereview.chromium.org/256073/diff/11001/11029
>>
>>
>>
>>>
>>>
  ... and why not use strings?
>> * does the string contain a trailing slash, or not?
>> * in the default port case, does the string contain the default
>> port number or not?
>>
>
> WebCore::SecurityOrigin handles these for us.  I'll make it
> difficult for a base::SecurityOrigin to be constructed any way 
> besides it
> coming from WebKit::WebSecurityOrigin (which only comes from
> WebCore::WebSecurityOrigin).  We can then deal with these details only
> if/when we need to.
>
>
> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow > > wrote:
>>
>>> Right now, we don't have a good story for what to do with
>>> WebCore::SecurityOrigins in Chromium.  We now have a 
>>> WebSecurityOrigin in
>>> WebKit, but if you want to move the data between processes, you 
>>> need to
>>> convert it to a string and then send that.  In some cases we then 
>>> convert
>>> the string to a GURL, but this seems like the wrong thing to do 
>>> (more on
>>> this in a sec).
>>> To me, the right answer is to create a type in base called
>>> SecurityOrigin that wraps a string and does equality checks.  The 
>>> equality
>>> checks can be done as string comparisons since the
>>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, 
>>> in the
>>> future, we need to do anything more with SecurityOrigins (besides
>>> transporting them, testing equality, and using them in sets/maps) 
>>> then we
>>> can make the class more complex.
>>>
>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state
>

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

Hmm... it seems useful as a means of making the code more self-documenting
anda bit safer.  I'd rather not have people passing strings for origins
since they might be
tempted to parse the strings.

The momentary translation to strings on the boundary of the WebKit API does
not
completely make this fragile.  If the end-points in Chrome use
SecurityOrigin and
the end-points in the WebKit API use WebSecurityOrigin, then developers will
be
naturally inclined to convert between SecurityOrigin and WebSecurityOrigin,
ignoring the toString() getter on WebSecurityOrigin.

This is a case where existing code should help guide people in the right
direction.

-Darin



On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow  wrote:

> If this is the case, then I don't think a SecurityOrigin wrapper buys us
> anything.  Never mind.
>
>
> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher  wrote:
>
>>
>>
>> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:

> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>
>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow 
>>> wrote:
>>>
 On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
 micha...@google.com> wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we're actually comparing
> a chrome generated security origin, as produced by GURL.GetOrigin(), 
> with a
> webkit generated security origin, as produced by
> WebSecurityOrigin.toString(). So we may want to accelerate the part 
> of the
> plan to do more than opaquely pass around and test webkit generated
> representations.
>
> Also, I think dumi has a use case to crack it open in order to form
> file path elements of the form 'scheme_host_port'
>

 Actually, Dumi's case is slightly different.  He wants to get
 SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
 should
 have a databaseIdentifier() method that outputs a FilePath object?

>>>
>>> Dumi has such a method in a CL that he is working on at the moment.
>>>  Also, note: we don't have a way to use FilePath from the WebKit API, 
>>> and
>>> I'm not sure that we should.  We use WebString for file paths in the 
>>> WebKit
>>> API.
>>>
>>
>> So then he's adding such a method to WebSecurityOrigin that returns a
>> string?  If so, sounds good.  What's the CL, btw?
>>
>
> Yes:
> http://codereview.chromium.org/256073/diff/11001/11029
>
>
>
>>
>>
>>>  ... and why not use strings?
> * does the string contain a trailing slash, or not?
> * in the default port case, does the string contain the default
> port number or not?
>

 WebCore::SecurityOrigin handles these for us.  I'll make it
 difficult for a base::SecurityOrigin to be constructed any way besides 
 it
 coming from WebKit::WebSecurityOrigin (which only comes from
 WebCore::WebSecurityOrigin).  We can then deal with these details only
 if/when we need to.


 On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow 
 wrote:
>
>> Right now, we don't have a good story for what to do with
>> WebCore::SecurityOrigins in Chromium.  We now have a 
>> WebSecurityOrigin in
>> WebKit, but if you want to move the data between processes, you need 
>> to
>> convert it to a string and then send that.  In some cases we then 
>> convert
>> the string to a GURL, but this seems like the wrong thing to do 
>> (more on
>> this in a sec).
>> To me, the right answer is to create a type in base called
>> SecurityOrigin that wraps a string and does equality checks.  The 
>> equality
>> checks can be done as string comparisons since the
>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in 
>> the
>> future, we need to do anything more with SecurityOrigins (besides
>> transporting them, testing equality, and using them in sets/maps) 
>> then we
>> can make the class more complex.
>>
>> Why not use GURL?  For one, the SecurityOrigin has a "null" state
>> which is significant and which isn't represented in GURL.  In 
>> addition,
>> there's a lot of operations you can do with a GURL which don't 
>> really make
>> sense in the context of a SecurityOrigin.  Passing around a 
>> SecurityOrigin
>> object is also much more self-documenting.  But, the fact t

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
> wrote:
> > As mentioned f2f, this falls apart as soon as Chrome tries to manufacture
> a
> > security origin. I'm not sure, may already have instances of that in the
> > code base for all I know.
>
> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
> There's a lot of tricky work in the canonicalization that we don't
> want to duplicate.
>
> Adam
>


Agreed, and we shouldn't be in that business.  I think for all our use
cases, the
factory for security origins can be WebCore.

Chrome just needs to be able to serialize / de-serialize a security
origin, compare
them, and possibly access some component parts (though I'm not certain of
this
requirement).

-Darin

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

If this is the case, then I don't think a SecurityOrigin wrapper buys us
anything.  Never mind.

On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher  wrote:

>
>
> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:

> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>
>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>> micha...@google.com> wrote:
>>>
 +1 SecurityOrigin class
 Sounds like a reasonable plan.
 I suspect there may already be cases where we're actually comparing
 a chrome generated security origin, as produced by GURL.GetOrigin(), 
 with a
 webkit generated security origin, as produced by
 WebSecurityOrigin.toString(). So we may want to accelerate the part of 
 the
 plan to do more than opaquely pass around and test webkit generated
 representations.

 Also, I think dumi has a use case to crack it open in order to form
 file path elements of the form 'scheme_host_port'

>>>
>>> Actually, Dumi's case is slightly different.  He wants to get
>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>> should
>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>
>>
>> Dumi has such a method in a CL that he is working on at the moment.
>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>> I'm not sure that we should.  We use WebString for file paths in the 
>> WebKit
>> API.
>>
>
> So then he's adding such a method to WebSecurityOrigin that returns a
> string?  If so, sounds good.  What's the CL, btw?
>

 Yes:
 http://codereview.chromium.org/256073/diff/11001/11029



>
>
>>  ... and why not use strings?
 * does the string contain a trailing slash, or not?
 * in the default port case, does the string contain the default port
 number or not?

>>>
>>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult
>>> for a base::SecurityOrigin to be constructed any way besides it coming 
>>> from
>>> WebKit::WebSecurityOrigin (which only comes from
>>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>>> if/when we need to.
>>>
>>>
>>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow 
>>> wrote:

> Right now, we don't have a good story for what to do with
> WebCore::SecurityOrigins in Chromium.  We now have a 
> WebSecurityOrigin in
> WebKit, but if you want to move the data between processes, you need 
> to
> convert it to a string and then send that.  In some cases we then 
> convert
> the string to a GURL, but this seems like the wrong thing to do (more 
> on
> this in a sec).
> To me, the right answer is to create a type in base called
> SecurityOrigin that wraps a string and does equality checks.  The 
> equality
> checks can be done as string comparisons since the
> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in 
> the
> future, we need to do anything more with SecurityOrigins (besides
> transporting them, testing equality, and using them in sets/maps) 
> then we
> can make the class more complex.
>
> Why not use GURL?  For one, the SecurityOrigin has a "null" state
> which is significant and which isn't represented in GURL.  In 
> addition,
> there's a lot of operations you can do with a GURL which don't really 
> make
> sense in the context of a SecurityOrigin.  Passing around a 
> SecurityOrigin
> object is also much more self-documenting.  But, the fact that GURL 
> looks
> like a tempting way to store a SecurityOrigin is actually one of the 
> biggest
> reasons why I think we should make a dedicated type.
>
> If people agree with this, my plan is to create such a type in base
> and modify WebKit::WebSecurityOrigin to do conversions to
> base::SecurityOrigin.  I'll then convert everything over (or ask 
> people to
> do the conversion if it looks scary).  Finally, I'll remove
> WebSecurityOrigin::toString().
>

>>
>> As I mentioned in person, I'm not happy having WebKit API depend on
>> base for too many things.  I would prefer to not introduce this 
>> dependency
>> since it is a circular dependency (in the way the respective repositories
>> relate).  Circular 

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 4:32 PM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:

> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>
>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>> micha...@google.com> wrote:
>>>
 +1 SecurityOrigin class
 Sounds like a reasonable plan.
 I suspect there may already be cases where we're actually comparing
 a chrome generated security origin, as produced by GURL.GetOrigin(), 
 with a
 webkit generated security origin, as produced by
 WebSecurityOrigin.toString(). So we may want to accelerate the part of 
 the
 plan to do more than opaquely pass around and test webkit generated
 representations.

 Also, I think dumi has a use case to crack it open in order to form
 file path elements of the form 'scheme_host_port'

>>>
>>> Actually, Dumi's case is slightly different.  He wants to get
>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>> should
>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>
>>
>> Dumi has such a method in a CL that he is working on at the moment.
>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>> I'm not sure that we should.  We use WebString for file paths in the 
>> WebKit
>> API.
>>
>
> So then he's adding such a method to WebSecurityOrigin that returns a
> string?  If so, sounds good.  What's the CL, btw?
>

 Yes:
 http://codereview.chromium.org/256073/diff/11001/11029


>>> we decided to use GURLs instead of string16s to represent SecurityOrigins
>>> on the chromium side, so we don't need a
>>> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do
>>> GURL(SecurityOrigin::toString()), and then create a file path from
>>> GURL::scheme(), GURL::host() and GURL::port().
>>>
>>
>> The point of this thread is that we should not be converting
>> SecurityOrigins of GURLs.  I believe michaeln was the primary proponent of
>> this and I believe we convinced him that we shouldn't be doing it.  And I
>> believe most if not all the reasons why were in my original email.
>>  (Michael, correct me if I'm wrong.)
>>
>
> I think i have two primary concerns.
>
> 1) What is the format of the data written to disk that we need to support
> going forward since it is on disk. We need a decision that we can stick
> with.
>
> 2) What measures are in place to ensure that we're actually persisting data
> in that prescribed format today.
>
> Having 'strings' float around makes me uneasy on that second point. If
> chrome can't validate these string values are in the prescribed format (its
> not smart enough to reason about them), how can we assert we've got it right
> (inspection doesn't work well... working backwards from a callsite in chrome
> browser code storing an 'origin' string to the source of that string being
> produced is just not practical).
>
> Given the current state of affairs, i still think GURL is a better option.
> Given a GURL, we can reason about it (produce path elements, produce a
> canonical string representation, test if another GURL falls in that origin
> or not (we do that in appcache code sans webkit)). The "null" security
> origin is an odd corner case that gives the GURL representation grief.
>

We don't need to reason about it.  WebCore::SecurityOrigin can do it for us.
 As Adam said, duplicating this kind of code in Chromium is not really
useful.  Let's let WebCore take care of it for us.


>
>
>>
>>> also, i'd argue that no class representing an origin should have a
>>> toFilePath()-like method: origins and file paths have nothing in common;
>>> using the origin URL as part of the DB file name is a database-specific
>>> decision and the code for that conversion should be kept in some
>>> database-specific class, or a separate origin_to_file_path_util.h file at
>>> best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only
>>> because that method was already there.)
>>>
>>
>> Well, SecurityOrigin has a method that creates a database file name.  I
>> don't see why we can't have a "::databasePath" method of our own.  And if we
>> do, then it does make sense for it to return a FilePath.
>>
>> That said, I think what Darin suggested in the code review is actually the
>> cleanest way to do it.  And I think returning a String is not a big deal.
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
 

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow  wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>>
 On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:

> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman > > wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with 
>>> a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>> the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form
>>> file path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>> should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi has such a method in a CL that he is working on at the moment.
>  Also, note: we don't have a way to use FilePath from the WebKit API, and
> I'm not sure that we should.  We use WebString for file paths in the 
> WebKit
> API.
>

 So then he's adding such a method to WebSecurityOrigin that returns a
 string?  If so, sounds good.  What's the CL, btw?

>>>
>>> Yes:
>>> http://codereview.chromium.org/256073/diff/11001/11029
>>>
>>>
>>>


>  ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default port
>>> number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult
>> for a base::SecurityOrigin to be constructed any way besides it coming 
>> from
>> WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>> if/when we need to.
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>
 Right now, we don't have a good story for what to do with
 WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin 
 in
 WebKit, but if you want to move the data between processes, you need to
 convert it to a string and then send that.  In some cases we then 
 convert
 the string to a GURL, but this seems like the wrong thing to do (more 
 on
 this in a sec).
 To me, the right answer is to create a type in base called
 SecurityOrigin that wraps a string and does equality checks.  The 
 equality
 checks can be done as string comparisons since the
 WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in 
 the
 future, we need to do anything more with SecurityOrigins (besides
 transporting them, testing equality, and using them in sets/maps) then 
 we
 can make the class more complex.

 Why not use GURL?  For one, the SecurityOrigin has a "null" state
 which is significant and which isn't represented in GURL.  In addition,
 there's a lot of operations you can do with a GURL which don't really 
 make
 sense in the context of a SecurityOrigin.  Passing around a 
 SecurityOrigin
 object is also much more self-documenting.  But, the fact that GURL 
 looks
 like a tempting way to store a SecurityOrigin is actually one of the 
 biggest
 reasons why I think we should make a dedicated type.

 If people agree with this, my plan is to create such a type in base
 and modify WebKit::WebSecurityOrigin to do conversions to
 base::SecurityOrigin.  I'll then convert everything over (or ask 
 people to
 do the conversion if it looks scary).  Finally, I'll remove
 WebSecurityOrigin::toString().

>>>
>
> As I mentioned in person, I'm not happy having WebKit API depend on
> base for too many things.  I would prefer to not introduce this dependency
> since it is a circular dependency (in the way the respective repositories
> relate).  Circular dependencies are evil.  We have them for string16 and
> NullableString16.  Let's not add more.
>

 If we have one circular dependency on base, why not add more?

>>>
>>> Because they can be a source of great pain.  This is a slippery slope.
>>>  We can basically never change base/string16.h or base/nullable_str

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

On Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow  wrote:

> On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc wrote:
>
>>
>>
>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>>
 On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:

> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman > > wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with 
>>> a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>> the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form
>>> file path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>> should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi has such a method in a CL that he is working on at the moment.
>  Also, note: we don't have a way to use FilePath from the WebKit API, and
> I'm not sure that we should.  We use WebString for file paths in the 
> WebKit
> API.
>

 So then he's adding such a method to WebSecurityOrigin that returns a
 string?  If so, sounds good.  What's the CL, btw?

>>>
>>> Yes:
>>> http://codereview.chromium.org/256073/diff/11001/11029
>>>
>>>
>> we decided to use GURLs instead of string16s to represent SecurityOrigins
>> on the chromium side, so we don't need a
>> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do
>> GURL(SecurityOrigin::toString()), and then create a file path from
>> GURL::scheme(), GURL::host() and GURL::port().
>>
>
> The point of this thread is that we should not be converting
> SecurityOrigins of GURLs.  I believe michaeln was the primary proponent of
> this and I believe we convinced him that we shouldn't be doing it.  And I
> believe most if not all the reasons why were in my original email.
>  (Michael, correct me if I'm wrong.)
>

I think i have two primary concerns.

1) What is the format of the data written to disk that we need to support
going forward since it is on disk. We need a decision that we can stick
with.

2) What measures are in place to ensure that we're actually persisting data
in that prescribed format today.

Having 'strings' float around makes me uneasy on that second point. If
chrome can't validate these string values are in the prescribed format (its
not smart enough to reason about them), how can we assert we've got it right
(inspection doesn't work well... working backwards from a callsite in chrome
browser code storing an 'origin' string to the source of that string being
produced is just not practical).

Given the current state of affairs, i still think GURL is a better option.
Given a GURL, we can reason about it (produce path elements, produce a
canonical string representation, test if another GURL falls in that origin
or not (we do that in appcache code sans webkit)). The "null" security
origin is an odd corner case that gives the GURL representation grief.


>
>> also, i'd argue that no class representing an origin should have a
>> toFilePath()-like method: origins and file paths have nothing in common;
>> using the origin URL as part of the DB file name is a database-specific
>> decision and the code for that conversion should be kept in some
>> database-specific class, or a separate origin_to_file_path_util.h file at
>> best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only
>> because that method was already there.)
>>
>
> Well, SecurityOrigin has a method that creates a database file name.  I
> don't see why we can't have a "::databasePath" method of our own.  And if we
> do, then it does make sense for it to return a FilePath.
>
> That said, I think what Darin suggested in the code review is actually the
> cleanest way to do it.  And I think returning a String is not a big deal.
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form file
>>> path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi needs to form file path elements, yes.
>
> Dumi also needs to store a canonical string representation of an 'origin'
> in the tracker database which will equate to the canonical string
> represetation 6 months from now (either that or upgrade the column values
> whenever that representation changes). Q: What is the canonical string
> representation used in the localstorage.db which has the similar requirement
> to track things per origin? Probably WebCore::SecurityOrigin::toString(), is
> that right?
>

LocalStorage uses SecurityOrigin::databaseIdentifier() from within WebCore.

Those two things probably shouldn't be confounded.
>
> At some point in the not too distant future, we'll need to interrogate from
> a ChromeUI  database, localstorage, appcache, and (filesystem) for what
> 'origins' are making how heavy a use of those systems.
>

We can add these methods as necessary.  We may need to add the methods to
the WebSecurityOrigin since base::SecurityOrigin will be dumb.

An important point is that code today is writing string values, and code 6
> months from now has to interpret those values and match against them.
>
>
>> ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default port
>>> number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for
>> a base::SecurityOrigin to be constructed any way besides it coming from
>> WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>> if/when we need to.
>>
>
> As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a
> security origin. I'm not sure, may already have instances of that in the
> code base for all I know.
>
>
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>
 Right now, we don't have a good story for what to do with
 WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
 WebKit, but if you want to move the data between processes, you need to
 convert it to a string and then send that.  In some cases we then convert
 the string to a GURL, but this seems like the wrong thing to do (more on
 this in a sec).
 To me, the right answer is to create a type in base called
 SecurityOrigin that wraps a string and does equality checks.  The equality
 checks can be done as string comparisons since the
 WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
 future, we need to do anything more with SecurityOrigins (besides
 transporting them, testing equality, and using them in sets/maps) then we
 can make the class more complex.

 Why not use GURL?  For one, the SecurityOrigin has a "null" state which
 is significant and which isn't represented in GURL.  In addition, there's a
 lot of operations you can do with a GURL which don't really make sense in
 the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
 also much more self-documenting.  But, the fact that GURL looks like a
 tempting way to store a SecurityOrigin is actually one of the biggest
 reasons why I think we should make a dedicated type.

 If people agree with this, my plan is to create such a type in base and
 modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
  I'll then convert everything over (or ask people to do the conversion if 
 it
 looks scary).  Finally, I'll remove WebSecurityOrigin::toString().

 Does this sound like a good plan?

 J

>>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc  wrote:

>
>
> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:

> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
> wrote:
>
>> +1 SecurityOrigin class
>> Sounds like a reasonable plan.
>> I suspect there may already be cases where we're actually comparing a
>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>> webkit generated security origin, as produced by
>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>> the
>> plan to do more than opaquely pass around and test webkit generated
>> representations.
>>
>> Also, I think dumi has a use case to crack it open in order to form
>> file path elements of the form 'scheme_host_port'
>>
>
> Actually, Dumi's case is slightly different.  He wants to get
> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
> have a databaseIdentifier() method that outputs a FilePath object?
>

 Dumi has such a method in a CL that he is working on at the moment.
  Also, note: we don't have a way to use FilePath from the WebKit API, and
 I'm not sure that we should.  We use WebString for file paths in the WebKit
 API.

>>>
>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>> string?  If so, sounds good.  What's the CL, btw?
>>>
>>
>> Yes:
>> http://codereview.chromium.org/256073/diff/11001/11029
>>
>>
> we decided to use GURLs instead of string16s to represent SecurityOrigins
> on the chromium side, so we don't need a
> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do
> GURL(SecurityOrigin::toString()), and then create a file path from
> GURL::scheme(), GURL::host() and GURL::port().
>

The point of this thread is that we should not be converting SecurityOrigins
of GURLs.  I believe michaeln was the primary proponent of this and I
believe we convinced him that we shouldn't be doing it.  And I believe most
if not all the reasons why were in my original email.  (Michael, correct me
if I'm wrong.)


> also, i'd argue that no class representing an origin should have a
> toFilePath()-like method: origins and file paths have nothing in common;
> using the origin URL as part of the DB file name is a database-specific
> decision and the code for that conversion should be kept in some
> database-specific class, or a separate origin_to_file_path_util.h file at
> best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only
> because that method was already there.)
>

Well, SecurityOrigin has a method that creates a database file name.  I
don't see why we can't have a "::databasePath" method of our own.  And if we
do, then it does make sense for it to return a FilePath.

That said, I think what Darin suggested in the code review is actually the
cleanest way to do it.  And I think returning a String is not a big deal.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>
 On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:

> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
> wrote:
>
>> +1 SecurityOrigin class
>> Sounds like a reasonable plan.
>> I suspect there may already be cases where we're actually comparing a
>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>> webkit generated security origin, as produced by
>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>> the
>> plan to do more than opaquely pass around and test webkit generated
>> representations.
>>
>> Also, I think dumi has a use case to crack it open in order to form
>> file path elements of the form 'scheme_host_port'
>>
>
> Actually, Dumi's case is slightly different.  He wants to get
> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
> have a databaseIdentifier() method that outputs a FilePath object?
>

 Dumi has such a method in a CL that he is working on at the moment.
  Also, note: we don't have a way to use FilePath from the WebKit API, and
 I'm not sure that we should.  We use WebString for file paths in the WebKit
 API.

>>>
>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>> string?  If so, sounds good.  What's the CL, btw?
>>>
>>
>> Yes:
>> http://codereview.chromium.org/256073/diff/11001/11029
>>
>>
>>
>>>
>>>
  ... and why not use strings?
>> * does the string contain a trailing slash, or not?
>> * in the default port case, does the string contain the default port
>> number or not?
>>
>
> WebCore::SecurityOrigin handles these for us.  I'll make it difficult
> for a base::SecurityOrigin to be constructed any way besides it coming 
> from
> WebKit::WebSecurityOrigin (which only comes from
> WebCore::WebSecurityOrigin).  We can then deal with these details only
> if/when we need to.
>
>
> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>
>>> Right now, we don't have a good story for what to do with
>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin 
>>> in
>>> WebKit, but if you want to move the data between processes, you need to
>>> convert it to a string and then send that.  In some cases we then 
>>> convert
>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>> this in a sec).
>>> To me, the right answer is to create a type in base called
>>> SecurityOrigin that wraps a string and does equality checks.  The 
>>> equality
>>> checks can be done as string comparisons since the
>>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
>>> future, we need to do anything more with SecurityOrigins (besides
>>> transporting them, testing equality, and using them in sets/maps) then 
>>> we
>>> can make the class more complex.
>>>
>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state
>>> which is significant and which isn't represented in GURL.  In addition,
>>> there's a lot of operations you can do with a GURL which don't really 
>>> make
>>> sense in the context of a SecurityOrigin.  Passing around a 
>>> SecurityOrigin
>>> object is also much more self-documenting.  But, the fact that GURL 
>>> looks
>>> like a tempting way to store a SecurityOrigin is actually one of the 
>>> biggest
>>> reasons why I think we should make a dedicated type.
>>>
>>> If people agree with this, my plan is to create such a type in base
>>> and modify WebKit::WebSecurityOrigin to do conversions to
>>> base::SecurityOrigin.  I'll then convert everything over (or ask people 
>>> to
>>> do the conversion if it looks scary).  Finally, I'll remove
>>> WebSecurityOrigin::toString().
>>>
>>

 As I mentioned in person, I'm not happy having WebKit API depend on base
 for too many things.  I would prefer to not introduce this dependency since
 it is a circular dependency (in the way the respective repositories 
 relate).
  Circular dependencies are evil.  We have them for string16 and
 NullableString16.  Let's not add more.

>>>
>>> If we have one circular dependency on base, why not add more?
>>>
>>
>> Because they can be a source of great pain.  This is a slippery slope.  We
>> can basically never change base/string16.h or base/nullable_string16.h.  I
>> don't want more of that.  Things like ChromiumBridge exist so we can avoid
>> having more of these.
>>
>
If we're making a DLL out of WebKit, then you're right.  Every time we
changed base, we'd 

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Dumitru Daniliuc]

On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>
 On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
 wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we're actually comparing a
> chrome generated security origin, as produced by GURL.GetOrigin(), with a
> webkit generated security origin, as produced by
> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
> plan to do more than opaquely pass around and test webkit generated
> representations.
>
> Also, I think dumi has a use case to crack it open in order to form
> file path elements of the form 'scheme_host_port'
>

 Actually, Dumi's case is slightly different.  He wants to get
 SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
 have a databaseIdentifier() method that outputs a FilePath object?

>>>
>>> Dumi has such a method in a CL that he is working on at the moment.
>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>> I'm not sure that we should.  We use WebString for file paths in the WebKit
>>> API.
>>>
>>
>> So then he's adding such a method to WebSecurityOrigin that returns a
>> string?  If so, sounds good.  What's the CL, btw?
>>
>
> Yes:
> http://codereview.chromium.org/256073/diff/11001/11029
>
>
we decided to use GURLs instead of string16s to represent SecurityOrigins on
the chromium side, so we don't need a (Web)SecurityOrigin::toFilePath()-like
method anymore; we can just do GURL(SecurityOrigin::toString()), and then
create a file path from GURL::scheme(), GURL::host() and GURL::port().

also, i'd argue that no class representing an origin should have a
toFilePath()-like method: origins and file paths have nothing in common;
using the origin URL as part of the DB file name is a database-specific
decision and the code for that conversion should be kept in some
database-specific class, or a separate origin_to_file_path_util.h file at
best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only
because that method was already there.)

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
> wrote:
> > As mentioned f2f, this falls apart as soon as Chrome tries to manufacture
> a
> > security origin. I'm not sure, may already have instances of that in the
> > code base for all I know.
>
> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
> There's a lot of tricky work in the canonicalization that we don't
> want to duplicate.
>

I agree.  I think the solution is to (if/when we actually need this!) add a
hook to the WebKit API to ask WebCore to manufacture one for us.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Adam Barth]

On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman  wrote:
> As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a
> security origin. I'm not sure, may already have instances of that in the
> code base for all I know.

I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
There's a lot of tricky work in the canonicalization that we don't
want to duplicate.

Adam

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:

> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>
>> +1 SecurityOrigin class
>> Sounds like a reasonable plan.
>> I suspect there may already be cases where we're actually comparing a
>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>> webkit generated security origin, as produced by
>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>> plan to do more than opaquely pass around and test webkit generated
>> representations.
>>
>> Also, I think dumi has a use case to crack it open in order to form file
>> path elements of the form 'scheme_host_port'
>>
>
> Actually, Dumi's case is slightly different.  He wants to get
> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
> have a databaseIdentifier() method that outputs a FilePath object?
>

Dumi has such a method in a CL that he is working on at the moment.  Also,
note: we don't have a way to use FilePath from the WebKit API, and I'm not
sure that we should.  We use WebString for file paths in the WebKit API.



>
> ... and why not use strings?
>> * does the string contain a trailing slash, or not?
>> * in the default port case, does the string contain the default port
>> number or not?
>>
>
> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for a
> base::SecurityOrigin to be constructed any way besides it coming from
> WebKit::WebSecurityOrigin (which only comes from
> WebCore::WebSecurityOrigin).  We can then deal with these details only
> if/when we need to.
>
>
> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow  wrote:
>>
>>> Right now, we don't have a good story for what to do with
>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>>> WebKit, but if you want to move the data between processes, you need to
>>> convert it to a string and then send that.  In some cases we then convert
>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>> this in a sec).
>>> To me, the right answer is to create a type in base called SecurityOrigin
>>> that wraps a string and does equality checks.  The equality checks can be
>>> done as string comparisons since the WebCore::SecurityOrigin::toString()
>>> method canonicalizes it.  If, in the future, we need to do anything more
>>> with SecurityOrigins (besides transporting them, testing equality, and using
>>> them in sets/maps) then we can make the class more complex.
>>>
>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which
>>> is significant and which isn't represented in GURL.  In addition, there's a
>>> lot of operations you can do with a GURL which don't really make sense in
>>> the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
>>> also much more self-documenting.  But, the fact that GURL looks like a
>>> tempting way to store a SecurityOrigin is actually one of the biggest
>>> reasons why I think we should make a dedicated type.
>>>
>>> If people agree with this, my plan is to create such a type in base and
>>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>>  I'll then convert everything over (or ask people to do the conversion if it
>>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>>
>>

As I mentioned in person, I'm not happy having WebKit API depend on base for
too many things.  I would prefer to not introduce this dependency since it
is a circular dependency (in the way the respective repositories relate).
 Circular dependencies are evil.  We have them for string16 and
NullableString16.  Let's not add more.

-Darin


>
>>> Does this sound like a good plan?
>>>
>>> J
>>>
>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:

> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>
>> +1 SecurityOrigin class
>> Sounds like a reasonable plan.
>> I suspect there may already be cases where we're actually comparing a
>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>> webkit generated security origin, as produced by
>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>> plan to do more than opaquely pass around and test webkit generated
>> representations.
>>
>> Also, I think dumi has a use case to crack it open in order to form file
>> path elements of the form 'scheme_host_port'
>>
>
> Actually, Dumi's case is slightly different.  He wants to get
> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
> have a databaseIdentifier() method that outputs a FilePath object?
>

Dumi needs to form file path elements, yes.

Dumi also needs to store a canonical string representation of an 'origin' in
the tracker database which will equate to the canonical string represetation
6 months from now (either that or upgrade the column values whenever that
representation changes). Q: What is the canonical string representation used
in the localstorage.db which has the similar requirement to track things per
origin? Probably WebCore::SecurityOrigin::toString(), is that right?

Those two things probably shouldn't be confounded.

At some point in the not too distant future, we'll need to interrogate from
a ChromeUI  database, localstorage, appcache, and (filesystem) for what
'origins' are making how heavy a use of those systems.

An important point is that code today is writing string values, and code 6
months from now has to interpret those values and match against them.


> ... and why not use strings?
>> * does the string contain a trailing slash, or not?
>> * in the default port case, does the string contain the default port
>> number or not?
>>
>
> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for a
> base::SecurityOrigin to be constructed any way besides it coming from
> WebKit::WebSecurityOrigin (which only comes from
> WebCore::WebSecurityOrigin).  We can then deal with these details only
> if/when we need to.
>

As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a
security origin. I'm not sure, may already have instances of that in the
code base for all I know.


>
>
> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow  wrote:
>>
>>> Right now, we don't have a good story for what to do with
>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>>> WebKit, but if you want to move the data between processes, you need to
>>> convert it to a string and then send that.  In some cases we then convert
>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>> this in a sec).
>>> To me, the right answer is to create a type in base called SecurityOrigin
>>> that wraps a string and does equality checks.  The equality checks can be
>>> done as string comparisons since the WebCore::SecurityOrigin::toString()
>>> method canonicalizes it.  If, in the future, we need to do anything more
>>> with SecurityOrigins (besides transporting them, testing equality, and using
>>> them in sets/maps) then we can make the class more complex.
>>>
>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which
>>> is significant and which isn't represented in GURL.  In addition, there's a
>>> lot of operations you can do with a GURL which don't really make sense in
>>> the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
>>> also much more self-documenting.  But, the fact that GURL looks like a
>>> tempting way to store a SecurityOrigin is actually one of the biggest
>>> reasons why I think we should make a dedicated type.
>>>
>>> If people agree with this, my plan is to create such a type in base and
>>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>>  I'll then convert everything over (or ask people to do the conversion if it
>>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>>
>>> Does this sound like a good plan?
>>>
>>> J
>>>
>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>
 On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
 wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we're actually comparing a
> chrome generated security origin, as produced by GURL.GetOrigin(), with a
> webkit generated security origin, as produced by
> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
> plan to do more than opaquely pass around and test webkit generated
> representations.
>
> Also, I think dumi has a use case to crack it open in order to form
> file path elements of the form 'scheme_host_port'
>

 Actually, Dumi's case is slightly different.  He wants to get
 SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
 have a databaseIdentifier() method that outputs a FilePath object?

>>>
>>> Dumi has such a method in a CL that he is working on at the moment.
>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>> I'm not sure that we should.  We use WebString for file paths in the WebKit
>>> API.
>>>
>>
>> So then he's adding such a method to WebSecurityOrigin that returns a
>> string?  If so, sounds good.  What's the CL, btw?
>>
>
> Yes:
> http://codereview.chromium.org/256073/diff/11001/11029
>
>
>
>>
>>
>>>  ... and why not use strings?
> * does the string contain a trailing slash, or not?
> * in the default port case, does the string contain the default port
> number or not?
>

 WebCore::SecurityOrigin handles these for us.  I'll make it difficult
 for a base::SecurityOrigin to be constructed any way besides it coming from
 WebKit::WebSecurityOrigin (which only comes from
 WebCore::WebSecurityOrigin).  We can then deal with these details only
 if/when we need to.


 On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>
>> Right now, we don't have a good story for what to do with
>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>> WebKit, but if you want to move the data between processes, you need to
>> convert it to a string and then send that.  In some cases we then convert
>> the string to a GURL, but this seems like the wrong thing to do (more on
>> this in a sec).
>> To me, the right answer is to create a type in base called
>> SecurityOrigin that wraps a string and does equality checks.  The 
>> equality
>> checks can be done as string comparisons since the
>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
>> future, we need to do anything more with SecurityOrigins (besides
>> transporting them, testing equality, and using them in sets/maps) then we
>> can make the class more complex.
>>
>> Why not use GURL?  For one, the SecurityOrigin has a "null" state
>> which is significant and which isn't represented in GURL.  In addition,
>> there's a lot of operations you can do with a GURL which don't really 
>> make
>> sense in the context of a SecurityOrigin.  Passing around a 
>> SecurityOrigin
>> object is also much more self-documenting.  But, the fact that GURL looks
>> like a tempting way to store a SecurityOrigin is actually one of the 
>> biggest
>> reasons why I think we should make a dedicated type.
>>
>> If people agree with this, my plan is to create such a type in base
>> and modify WebKit::WebSecurityOrigin to do conversions to
>> base::SecurityOrigin.  I'll then convert everything over (or ask people 
>> to
>> do the conversion if it looks scary).  Finally, I'll remove
>> WebSecurityOrigin::toString().
>>
>
>>>
>>> As I mentioned in person, I'm not happy having WebKit API depend on base
>>> for too many things.  I would prefer to not introduce this dependency since
>>> it is a circular dependency (in the way the respective repositories relate).
>>>  Circular dependencies are evil.  We have them for string16 and
>>> NullableString16.  Let's not add more.
>>>
>>
>> If we have one circular dependency on base, why not add more?
>>
>
> Because they can be a source of great pain.  This is a slippery slope.  We
> can basically never change base/string16.h or base/nullable_string16.h.  I
> don't want more of that.  Things like ChromiumBridge exist so we can avoid
> having more of these.
>
>
>
>>  Anyhow, they're already #if'ed.  So if someone wanted to use the API
>> without base, they easily could change that #else to a #elif, right?  Maybe
>> we should just do that now?
>>
>
> Right, that was my intent.  They are currently defined when
> WEBKIT_IMPLEMENTATION is not defined, but we should probab

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Darin Fisher]

On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow  wrote:

> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>>>
 +1 SecurityOrigin class
 Sounds like a reasonable plan.
 I suspect there may already be cases where we're actually comparing a
 chrome generated security origin, as produced by GURL.GetOrigin(), with a
 webkit generated security origin, as produced by
 WebSecurityOrigin.toString(). So we may want to accelerate the part of the
 plan to do more than opaquely pass around and test webkit generated
 representations.

 Also, I think dumi has a use case to crack it open in order to form file
 path elements of the form 'scheme_host_port'

>>>
>>> Actually, Dumi's case is slightly different.  He wants to get
>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>
>>
>> Dumi has such a method in a CL that he is working on at the moment.  Also,
>> note: we don't have a way to use FilePath from the WebKit API, and I'm not
>> sure that we should.  We use WebString for file paths in the WebKit API.
>>
>
> So then he's adding such a method to WebSecurityOrigin that returns a
> string?  If so, sounds good.  What's the CL, btw?
>

Yes:
http://codereview.chromium.org/256073/diff/11001/11029



>
>
>>  ... and why not use strings?
 * does the string contain a trailing slash, or not?
 * in the default port case, does the string contain the default port
 number or not?

>>>
>>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for
>>> a base::SecurityOrigin to be constructed any way besides it coming from
>>> WebKit::WebSecurityOrigin (which only comes from
>>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>>> if/when we need to.
>>>
>>>
>>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:

> Right now, we don't have a good story for what to do with
> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
> WebKit, but if you want to move the data between processes, you need to
> convert it to a string and then send that.  In some cases we then convert
> the string to a GURL, but this seems like the wrong thing to do (more on
> this in a sec).
> To me, the right answer is to create a type in base called
> SecurityOrigin that wraps a string and does equality checks.  The equality
> checks can be done as string comparisons since the
> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
> future, we need to do anything more with SecurityOrigins (besides
> transporting them, testing equality, and using them in sets/maps) then we
> can make the class more complex.
>
> Why not use GURL?  For one, the SecurityOrigin has a "null" state which
> is significant and which isn't represented in GURL.  In addition, there's 
> a
> lot of operations you can do with a GURL which don't really make sense in
> the context of a SecurityOrigin.  Passing around a SecurityOrigin object 
> is
> also much more self-documenting.  But, the fact that GURL looks like a
> tempting way to store a SecurityOrigin is actually one of the biggest
> reasons why I think we should make a dedicated type.
>
> If people agree with this, my plan is to create such a type in base and
> modify WebKit::WebSecurityOrigin to do conversions to 
> base::SecurityOrigin.
>  I'll then convert everything over (or ask people to do the conversion if 
> it
> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>

>>
>> As I mentioned in person, I'm not happy having WebKit API depend on base
>> for too many things.  I would prefer to not introduce this dependency since
>> it is a circular dependency (in the way the respective repositories relate).
>>  Circular dependencies are evil.  We have them for string16 and
>> NullableString16.  Let's not add more.
>>
>
> If we have one circular dependency on base, why not add more?
>

Because they can be a source of great pain.  This is a slippery slope.  We
can basically never change base/string16.h or base/nullable_string16.h.  I
don't want more of that.  Things like ChromiumBridge exist so we can avoid
having more of these.



>  Anyhow, they're already #if'ed.  So if someone wanted to use the API
> without base, they easily could change that #else to a #elif, right?  Maybe
> we should just do that now?
>

Right, that was my intent.  They are currently defined when
WEBKIT_IMPLEMENTATION is not defined, but we should probably make consumers
opt-in by defining something explicit.



>
> I agree the circular dependencies are bad, but they're already there.  And,
> honestly, the WebKit API (in its current form) is not useful 

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form file
>>> path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi has such a method in a CL that he is working on at the moment.  Also,
> note: we don't have a way to use FilePath from the WebKit API, and I'm not
> sure that we should.  We use WebString for file paths in the WebKit API.
>

So then he's adding such a method to WebSecurityOrigin that returns a
string?  If so, sounds good.  What's the CL, btw?


>  ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default port
>>> number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for
>> a base::SecurityOrigin to be constructed any way besides it coming from
>> WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>> if/when we need to.
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>
 Right now, we don't have a good story for what to do with
 WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
 WebKit, but if you want to move the data between processes, you need to
 convert it to a string and then send that.  In some cases we then convert
 the string to a GURL, but this seems like the wrong thing to do (more on
 this in a sec).
 To me, the right answer is to create a type in base called
 SecurityOrigin that wraps a string and does equality checks.  The equality
 checks can be done as string comparisons since the
 WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
 future, we need to do anything more with SecurityOrigins (besides
 transporting them, testing equality, and using them in sets/maps) then we
 can make the class more complex.

 Why not use GURL?  For one, the SecurityOrigin has a "null" state which
 is significant and which isn't represented in GURL.  In addition, there's a
 lot of operations you can do with a GURL which don't really make sense in
 the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
 also much more self-documenting.  But, the fact that GURL looks like a
 tempting way to store a SecurityOrigin is actually one of the biggest
 reasons why I think we should make a dedicated type.

 If people agree with this, my plan is to create such a type in base and
 modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
  I'll then convert everything over (or ask people to do the conversion if 
 it
 looks scary).  Finally, I'll remove WebSecurityOrigin::toString().

>>>
>
> As I mentioned in person, I'm not happy having WebKit API depend on base
> for too many things.  I would prefer to not introduce this dependency since
> it is a circular dependency (in the way the respective repositories relate).
>  Circular dependencies are evil.  We have them for string16 and
> NullableString16.  Let's not add more.
>

If we have one circular dependency on base, why not add more?  Anyhow,
they're already #if'ed.  So if someone wanted to use the API without base,
they easily could change that #else to a #elif, right?  Maybe we should just
do that now?

I agree the circular dependencies are bad, but they're already there.  And,
honestly, the WebKit API (in its current form) is not useful unless you are
including base.

Whatsmore, if we output stuff as a string, then we're just hoping someone
goes ahead and immediately converts that to a SecurityOrigin.  But there's
no guarantee they won't.  Or that they won't do something incredibly stupid
before such a conversion.  By forcing things to go straight to a
base::SecurityOrigin (and comments in that code explaining why) it'll be
much harder for someone to do something dangerous without doing
it willfully.

Personally, I think we should have more functions for converting to base::
types rather than less.



>
> -Darin
>
>
>>
 Does this sound like a good plan?

 J

>>>
>>>
>>
>

--~--~--

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we're actually comparing a
> chrome generated security origin, as produced by GURL.GetOrigin(), with a
> webkit generated security origin, as produced by
> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
> plan to do more than opaquely pass around and test webkit generated
> representations.
>
> Also, I think dumi has a use case to crack it open in order to form file
> path elements of the form 'scheme_host_port'
>

Actually, Dumi's case is slightly different.  He wants to get
SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
have a databaseIdentifier() method that outputs a FilePath object?

... and why not use strings?
> * does the string contain a trailing slash, or not?
> * in the default port case, does the string contain the default port number
> or not?
>

WebCore::SecurityOrigin handles these for us.  I'll make it difficult for a
base::SecurityOrigin to be constructed any way besides it coming from
WebKit::WebSecurityOrigin (which only comes from
WebCore::WebSecurityOrigin).  We can then deal with these details only
if/when we need to.


On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow  wrote:
>
>> Right now, we don't have a good story for what to do with
>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>> WebKit, but if you want to move the data between processes, you need to
>> convert it to a string and then send that.  In some cases we then convert
>> the string to a GURL, but this seems like the wrong thing to do (more on
>> this in a sec).
>> To me, the right answer is to create a type in base called SecurityOrigin
>> that wraps a string and does equality checks.  The equality checks can be
>> done as string comparisons since the WebCore::SecurityOrigin::toString()
>> method canonicalizes it.  If, in the future, we need to do anything more
>> with SecurityOrigins (besides transporting them, testing equality, and using
>> them in sets/maps) then we can make the class more complex.
>>
>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which is
>> significant and which isn't represented in GURL.  In addition, there's a lot
>> of operations you can do with a GURL which don't really make sense in the
>> context of a SecurityOrigin.  Passing around a SecurityOrigin object is also
>> much more self-documenting.  But, the fact that GURL looks like a tempting
>> way to store a SecurityOrigin is actually one of the biggest reasons why I
>> think we should make a dedicated type.
>>
>> If people agree with this, my plan is to create such a type in base and
>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>  I'll then convert everything over (or ask people to do the conversion if it
>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>
>> Does this sound like a good plan?
>>
>> J
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Michael Nordman]

+1 SecurityOrigin class
Sounds like a reasonable plan.
I suspect there may already be cases where we're actually comparing a chrome
generated security origin, as produced by GURL.GetOrigin(), with a webkit
generated security origin, as produced by WebSecurityOrigin.toString(). So
we may want to accelerate the part of the plan to do more than opaquely pass
around and test webkit generated representations.

Also, I think dumi has a use case to crack it open in order to form file
path elements of the form 'scheme_host_port'

... and why not use strings?
* does the string contain a trailing slash, or not?
* in the default port case, does the string contain the default port number
or not?



On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow  wrote:

> Right now, we don't have a good story for what to do with
> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
> WebKit, but if you want to move the data between processes, you need to
> convert it to a string and then send that.  In some cases we then convert
> the string to a GURL, but this seems like the wrong thing to do (more on
> this in a sec).
> To me, the right answer is to create a type in base called SecurityOrigin
> that wraps a string and does equality checks.  The equality checks can be
> done as string comparisons since the WebCore::SecurityOrigin::toString()
> method canonicalizes it.  If, in the future, we need to do anything more
> with SecurityOrigins (besides transporting them, testing equality, and using
> them in sets/maps) then we can make the class more complex.
>
> Why not use GURL?  For one, the SecurityOrigin has a "null" state which is
> significant and which isn't represented in GURL.  In addition, there's a lot
> of operations you can do with a GURL which don't really make sense in the
> context of a SecurityOrigin.  Passing around a SecurityOrigin object is also
> much more self-documenting.  But, the fact that GURL looks like a tempting
> way to store a SecurityOrigin is actually one of the biggest reasons why I
> think we should make a dedicated type.
>
> If people agree with this, my plan is to create such a type in base and
> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>  I'll then convert everything over (or ask people to do the conversion if it
> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>
> Does this sound like a good plan?
>
> J
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---