On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman <micha...@google.com>wrote:
>
>
> On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman <micha...@google.com>wrote:
>
>>
>>
>> On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow <jor...@chromium.org>wrote:
>>
>>> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman
>>> <micha...@google.com>wrote:
>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher <da...@chromium.org>wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth <aba...@chromium.org>wrote:
>>>>>
>>>>>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman <micha...@google.com>
>>>>>> 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
-~----------~----~----~----~------~----~------~--~---
