Code review: 8010464: Evolve java networking same origin policy

[Michael McMahon]

Okay, I get you now. I think this is just a (complicating) consequence
of the syntax. I don't think there is anything we can do about it.

BTW, I probably should warn you that we are looking at changing the spec 
again
to allow port number ranges, the same as SocketPermission...

- Michael

On 13/05/13 14:54, Weijun Wang wrote:
>
>
> On 5/13/13 9:38 PM, Michael McMahon wrote:
>> 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.
>
> The components on the two sides of ":" have different meanings, so you 
> cannot make "A:B:C:D" from "A:B" and "C:D". That's what I mean "not 
> accumulative", at least, cannot be accumulated use simple string 
> concatenation.
>
> Yes, for existing Permission types, actions only have limited possible 
> values, but it's not restrictive to 1 or 2.
>
>>
>>> 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.
>
> Yes, I can see that from the CCC.
>
>> 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.
>
> And you normally need multiple methods as well?
>
> Thanks
> Max
>
>>
>> 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
>>