On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman <[email protected]>wrote:
> > > On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow <[email protected]> wrote: > >> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <[email protected]>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 <[email protected]>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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
