[webkit-dev] Security Origins

[Sam Weinig]

On Mon, Jun 1, 2009 at 3:50 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> I have 2 questions about SecurityOrigins.
>
>
> First of all, in SecurityOrigin::databaseIdentifier() (in
> http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the
> following comment appears: "Serialize the security origin for storage in the
> database. This format is deprecated and should be used only for
> compatibility with old databases; use toString() and createFromString()
> instead."  This was done in http://trac.webkit.org/changeset/32597
>
> Despite the comments in the change log, I don't fully understand what the
> intention here is.  DatabaseTracker and LocalStorage still use
> databaseIdentifier() which makes sense since, unless I'm totally missing
> something, the toString() format produces file names that are invalid on
> most file systems.  At the same time, databaseIdentifier omits some of the
> logic found in toString (which might be the cause of bugs like
> https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet).
>
> So, maybe instead of databaseIdentifier() being "deprecated", it should be
> updated to be more like a toString that uses file system safe characters?
>

It is deprecated in the sense that only Database code should use it.  We
can't make Database code use toString() because there are existing clients
that depend on the identifier to remain the same.


> In addition, the creation of SecurityOrigin objects doesn't quite seem
> right.  There are many places (like in DatabaseTracker) where security
> origins are created based on the file, port, and protocol.  This is fine
> when all you're doing is .equals (which the HashMap's
> HashArg=SecurityOriginHash prarmeter does for you), but it seems like it
> could be inefficient (many SecurityOrigin objects describing the same
> origin) and could potentially lead to bugs (since not all of the properties
> are serialized during toString()/databaseIdentifier()).
>
> It's surprising to me that there isn't one central store of SecurityOrigin
> objects (maybe with weak references?) to eliminate the possibility of 2
> SecurityOrigin objects describing the same origin.
>

I suspect SecurityOrigins can be optimized, but as of yet they have not
appeared on profiles.  I would like to improve SecurityOrigins to better
represent the concepts of effective script origin and origins representing
resources more effectively.


>
>
> In general, I suppose I'm just trying to understand the thought behind
> SecurityOrigin objects and how they're used in the source code...because it
> doesn't seem very natural to me.
>

SecurityOrigin was created to cleanup the way we do same-origin checks in
the JavaScript bindings, and as such, carry some of that baggage (eg. domain
relaxing).  The main design constraint then was that it was a cheap compare
for two origins representing the same document (pointer compare) as that is
common case.  The code evolved from there.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090601/63d99440/attachment.html>