Re: API change for 8010464: Evolve java networking same origin policy

[Michael McMahon]

Ah right. The permission only contains header names.
It never contains header values. And header names are "tokens"
in the Http spec that cannot contain a colon character.

Michael

On 01/05/13 12:11, Dmitry Samersoff wrote:

Michael,

I'm just asking about replacing : (colon) to another character to be
able to write something like:

  permission
  java.net.HttpURLPermission "http://www.foo.com/-";,
  "GET Location: http://www.foo.com/*, Content-type: image/jpeg";

in a future

-Dmitry.

On 2013-05-01 15:04, Michael McMahon wrote:

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.