API change for 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 01/05/13 11:09, Dmitry Samersoff wrote:
> Michael,
>
>> "GET,POST:Header1,Header2"
> Colon is a delimiter between http header and it's value.
>
> With this syntax we might have problems in a future if sometimes we will
> support different headers for different methods or add an ability to
> check header value as well.
>
> -Dmitry

Dmitry,

It would complicate the syntax a lot if you wanted to support
different headers for different methods. Would be a lot simpler
to just grant separate permissions for the two cases. Eg.

grant {
     permission  java.net.HttpURLPermission "http://www.foo.com/-", 
"GET:Header1,Header2";
     permission  java.net.HttpURLPermission "http://www.foo.com/-", 
"POST:Header3,Header4";
};

Michael

> On 2013-04-30 14:30, Michael McMahon wrote:
>> Hi Kurchi,
>>
>> I can include such an example easily. Eg:
>>
>> "GET,POST:Header1,Header2"
>>
>> means one permission that permits either GET or POST with either or both
>> of the two headers. If you wanted to restrict one set of headers to GET
>> and another set to POST, then that would require two different
>> permissions.
>>
>> - Michael
>>
>> On 30/04/13 00:40, Kurchi Hazra wrote:
>>> Hi Michael,
>>>
>>>       From the documentation, it is not clear to me how to represent
>>> both request-headers and method list together in an actions string for
>>> two or more methods. (Say I have two methods GET and POST and I want
>>> to specify a request-headers list for each, how do I do it?) Maybe
>>> another example will help.
>>>
>>> Thanks,
>>> Kurchi
>>>
>>> On 4/29/2013 3:53 AM, Michael McMahon wrote:
>>>> On 28/04/13 09:01, Chris Hegarty wrote:
>>>>> In the main I link the new HttpURLPermission class.
>>>>>
>>>>> When reading the docs I found the references to "the URL" and "URL
>>>>> string" confusing ( it could be just me ). When I see capital 'URL'
>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all
>>>>> cases you mean the URL string given when constructing the
>>>>> HttpURLPermission, right?
>>>>>
>>>> Yes, that is what is meant. The class does not use j.n.URL at all, as
>>>> that would bring us back
>>>> to the old (undesirable) behavior with DNS lookups required for basic
>>>> operations like equals() and hashCode()
>>>>
>>>>> Another example is the equals method
>>>>>    "Returns true if, this.getActions().equals(p.getActions()) and p's
>>>>>     URL equals this's URL. Returns false otherwise."
>>>>>
>>>>> this is referring so a simple string comparison of the given URL
>>>>> string, right? This should be case insensitive too. Does it take
>>>>> into account default protocol ports, e.g. http://foo.com/ equal
>>>>> http://foo.com:80/
>>>>>
>>>> The implementation uses a java.net.URI internally. So URI takes care
>>>> of that.
>>>>
>>>>> implies() makes reference to the URL scheme, and other specific
>>>>> parts of the URL. Also, the constructors throw IAE  'if url is not a
>>>>> valid URL', but what does this mean. Should we just bite the bullet
>>>>> and just say that URI is used to parse the given string into its
>>>>> specific parts? Otherwise, how can this be validated.
>>>>>
>>>> I originally didn't want to mention URI in the apidoc due to
>>>> potential confusion surrounding the use of URL in the permission
>>>> class name. But, maybe it would be clearer to be explicit about it,
>>>> particularly for the equals() behavior.
>>>> Otherwise we have to specify all of it in this class.
>>>>
>>>>> As for the additions to HttpURLConnection, what are the implications
>>>>> on proxies? Permissions, etc...
>>>>>
>>>> There's no change in behavior with respect to proxies. Permission is
>>>> given to connect to proxies implicitly
>>>> except in cases where the caller specifies the proxy through the
>>>> URL.openConnection(Proxy) api.
>>>> There are other unusual cases like the Http "Use Proxy" response.
>>>> Explicit permission is required
>>>> for that case also.
>>>>
>>>> Thanks!
>>>>
>>>> Michael
>>>>
>>>>> -Chris.
>>>>>
>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The is the suggested API for one of the two new JEPs recently
>>>>>> submitted.
>>>>>>
>>>>>> This is for JEP 184: HTTP URL Permissions
>>>>>>
>>>>>> The idea here is to define a higher level http permission class
>>>>>> which "knows about" URLs, HTTP request methods and headers.
>>>>>> So, it is no longer necessary to grant blanket permission for any kind
>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission
>>>>>> restricts
>>>>>> access to only the Http protocol itself. Restrictions can also be
>>>>>> imposed
>>>>>> based on URL paths, specific request methods and request headers.
>>>>>>
>>>>>> The API change can be seen at the URL below:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/
>>>>>>
>>>>>> In addition to defining a new permission class, HttpURLConnection
>>>>>> is modified to make use of it and the documentation change
>>>>>> describing this
>>>>>> can be seen at the link below:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html
>>>>>>
>>>>>> All comments welcome.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Michael.
>