Jetty Logo
Version: 9.4.5.v20170502
Contact the core Jetty developers at www.webtide.com

private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services for sponsored feature development

IP Access Handler

Info
Usage

Info

Usage

Controls access to the wrapped handler by the real remote IP. Control is provided by white/black lists that include both internet addresses and URIs. This handler uses the real internet address of the connection, not one reported in the forwarded for headers, as this cannot be as easily forged.

Typically, the black/white lists will be used in one of three modes:

  • Blocking a few specific IPs/URLs by specifying several black list entries.
  • Allowing only some specific IPs/URLs by specifying several white lists entries.
  • Allowing a general range of IPs/URLs by specifying several general white list entries, that are then further refined by several specific black list exceptions.

An empty white list is treated as match all. If there is at least one entry in the white list, then a request must match a white list entry. Black list entries are always applied, so that even if an entry matches the white list, a black list entry will override it.

Internet addresses may be specified as absolute address or as a combination of four octet wildcard specifications (a.b.c.d) that are defined as follows.

  • nnn - an absolute value (0-255)
  • mmm-nnn - an inclusive range of absolute values, with following shorthand notations:

    • nnn- ⇒ nnn-255
    • -nnn ⇒ 0-nnn
    • - ⇒ 0-255
  • a,b,…​ - a list of wildcard specifications

Internet address specification is separated from the URI pattern using the "|" (pipe) character. URI patterns follow the servlet specification for simple * prefix and suffix wild cards (e.g. /, /foo, /foo/bar, /foo/bar/*, *.baz).

Earlier versions of the handler used internet address prefix wildcard specification to define a range of the internet addresses (e.g. 127., 10.10., 172.16.1.). They also used the first "/" character of the URI pattern to separate it from the internet address. Both of these features have been deprecated in the current version.

Examples of the entry specifications are:

  • 10.10.1.2 - all requests from IP 10.10.1.2
  • 10.10.1.2|/foo/bar - all requests from IP 10.10.1.2 to URI /foo/bar
  • 10.10.1.2|/foo/* - all requests from IP 10.10.1.2 to URIs starting with /foo/
  • 10.10.1.2|*.html - all requests from IP 10.10.1.2 to URIs ending with .html
  • 10.10.0-255.0-255 - all requests from IPs within 10.10.0.0/16 subnet
  • 10.10.0-.-255|/foo/bar - all requests from IPs within 10.10.0.0/16 subnet to URI /foo/bar
  • 10.10.0-3,1,3,7,15|/foo/* - all requests from IPs addresses with last octet equal to 1,3,7,15 in subnet 10.10.0.0/22 to URIs starting with /foo/

Earlier versions of the handler used internet address prefix wildcard specification to define a range of the internet addresses (e.g. 127., 10.10., 172.16.1.). They also used the first "/" character of the URI pattern to separate it from the internet address. Both of these features have been deprecated in the current version.

See an error or something missing? Contribute to this documentation at Github!(Generated: 2017-05-02)