//
//  ========================================================================
//  Copyright (c) 1995-2020 Mort Bay Consulting Pty Ltd and others.
//  ========================================================================
//  All rights reserved. This program and the accompanying materials
//  are made available under the terms of the Eclipse Public License v1.0
//  and Apache License v2.0 which accompanies this distribution.
//
//      The Eclipse Public License is available at
//      http://www.eclipse.org/legal/epl-v10.html
//
//      The Apache License v2.0 is available at
//      http://www.opensource.org/licenses/apache2.0.php
//
//  You may elect to redistribute this code under either of these licenses.
//  ========================================================================
//

[[ipaccess-handler]]
=== IP Access Handler

[[ipaccess-handler-metadata]]
==== Info

* Classname: `org.eclipse.jetty.server.handler.IPAccessHandler`
* Maven Artifact: org.eclipse.jetty:jetty-server
* Javadoc: {JDURL}/org/eclipse/jetty/server/handler/IPAccessHandler.html

[[ipaccess-handler-usage]]
==== 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.
