On 13/05/13 14:29, Weijun Wang wrote:
Hi Michael
Until now, for all types of permissions, the "actions" property takes
the form of a comma separated list, and it's always accumulative. For
example, it can be "read", or "write", or "read, write". In fact, the
policytool makes use of this style so that you can click on single
actions items to create a combined one.
Now with HttpURLPermission, this is no longer true.
Of course, there is no way to list single items for HttpURLPermission
(no wellknown header name) so the new style doesn't really affect
policytool that much. It's just that I realized this difference when
trying to support this new Permission type in policytool.
Max
If I understand you right, the difference isn't the fact that the list
elements "accumulate", but that
the range of possible values is unlimited. Of course, there is a syntax
difference (with the ":" char) also.
To use the old style, "GET,POST:Header1,Header2" will have to be
rewritten to "GET:Header1, GET:Header2, POST: Header1, POST:Header2".
The more the items are, the more complicated it will be. I am not sure
how many methods and headers you would need in a typical use case.
I'm not sure I follow this. The second example isn't supported in
HttpURLPermission. You would
just create four separate permission objects if that's what you want to
grant. I imagine that typically
only small numbers of headers (5 or less?) would typically be used.
Michael
Thanks
Max
On 5/10/13 7:34 PM, Michael McMahon wrote:
Hi,
This is the webrev for the HttpURLPermission addition.
As well as the new permission class, the change
includes the use of the permission in java.net.HttpURLConnection.
The code basically checks for a HttpURLPermission in plainConnect(),
getInputStream() and getOutputStream() for the request and if
the caller has permission the request is executed in a doPrivileged()
block. When the limited doPrivileged feature is integrated, I will
change the doPrivileged() call to limit the privilege elevation to a
single
SocketPermission (as shown in the code comments).
The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/
Thanks
Michael
