JEP 184: HTTP URL Permissions
|Discussion||net dash dev at openjdk dot java dot net|
|Reviewed-by||Alan Bateman, Chris Hegarty, Jeff Nisewanger|
Define a new type of network permission which grants access in terms of URLs rather than low-level IP addresses.
The only way to specify network permissions today is with the
java.net.SocketPermission class, which has two major drawbacks:
Socket permissions govern the initiation of low-level TCP connections. They therefore cannot distinguish between an HTTP connection to some host, which might be permitted, and other kinds of TCP connections to the same host, which might not be permitted.
Socket permissions operate in terms of IP addresses rather than host names. This makes it impossible to distinguish between virtual HTTP servers hosted on the same physical server at the same IP address. Even though two such servers have different domain names, a
SocketPermissioninstance cannot be used to permit access to one server but not the other.
This feature will define a higher-level permission type specific to HTTP
or perhaps, more generally, to arbitrary URL schemes. The class will be
able to express permissions in terms of HTTP request methods (
PUT, etc.) and URL scheme, authority, and path components.
No DNS lookups will be required in order to do permission checks or to
compare permission objects for equality.
The HTTP protocol handler will check for these new permissions in the
call stack and, using the limited
doPrivileged() feature, it
will effectively convert the URL permission into a
the actual destination.
This feature introduces one new class, which can be tested using the
JDK’s built-in HTTP server. Unit tests for the class itself, i.e., for
testing public methods such as
implies(), can be written directly. The
engineering work for this feature will include both kinds of tests.
This feature depends on JEP 140: Limited doPrivileged.
- Security: Introduces a new security permission. The use of limited
doPrivileged()should limit the risk of security issues.