Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

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