[webkit-dev] Security Origins

[Jeremy Orlow]

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?


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.


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.

Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090601/33b222a7/attachment.html>