[Webkit-unassigned] [Bug 117823] [Qt] Add interface API for Origin whiteListing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jun 25 02:20:09 PDT 2013


https://bugs.webkit.org/show_bug.cgi?id=117823





--- Comment #8 from Allan Sandfeld Jensen <allan.jensen at digia.com>  2013-06-25 02:22:04 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (From update of attachment 205064 [details] [details] [details])
> > > I don't like creating new securityOrigins for the purpose of just calling the SecurityPolicy methods. Would it be possible to instead make the calls methods called on the QWebSecurityOrigin? In that case you already have a WebCore::SecurityOrigin in the private data.
> > 
> > Or to match the WebPolicy API. Just make the methods take QWebSecurityOrigin as arguments.
> 
> Hi Allen,
> 
> Currently a public constructor to create a QWebSecurityOrigin is not available. Such a constructor can be exposed. But if we are to use the existing WebCore::SecurityOrigin in QWebSecurityOriginPrivate then let us consider the following scenario: 
> 
> Suppose there are N origins that the browser wants to white-list, every time it wants to specify a new origin: the exiting WebCore::SecurityOrigin in QWebSecurityOriginPrivate needs to be deleted and replaced with a new SecurityOrigin and then call the SecurityPolicy API using that. (As we cannot modify an existing WebCore::SecurityOrigin once created)
> 
> I am not sure if this would be a nice way to do it.
> 
The end result is essentially the same, but I can see your point about the lack of QWebSecurityOrigin constructors.

I still don't like the temporary smart pointers though. I think it would be nicer to keep the SecurityOrigin objects in proper RefPtr variables. 

Also I know from a Qt API point of view we discourage the use of boolean arguments. While it does match the WebCore API. I know my colleagues would prefer if you used an enum.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list