Documentation ¶
Overview ¶
Package proxy contains implementation of the filtering MITM proxy
Package proxy implements a MITM proxy that uses urlfilter to filter content. TODO(ameshkov): extract to a submodule
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Config ¶
type Config struct { // Config of the MITM proxy ProxyConfig gomitmproxy.Config // Paths to the filtering rules FiltersPaths map[int]string // InjectionHost is used for injecting custom CSS/JS into web pages. // // Here's how it works: // * The proxy injects `<script src="//INJECTIONS_HOST/content-script.js?domain=HOSTNAME&flags=FLAGS"></script>` // * Depending on the FLAGS and the HOSTNAME, it either injects cosmetic rules or not // * Proxy handles requests to this host // * The content script content depends on the FLAGS value InjectionHost string // If true, we will serve the content-script compressed // This is useful for the case when the proxy is on a public server, // as it saves some data. CompressContentScript bool }
Config contains the MITM proxy configuration
type Server ¶
type Server struct { Config // Server configuration // contains filtered or unexported fields }
Server contains the current server state
type Session ¶ added in v0.7.0
type Session struct { // Request is the original request data. Request *rules.Request // HTTPRequest is the original HTTP request data. HTTPRequest *http.Request // HTTPResponse is the original HTTP response data. HTTPResponse *http.Response // Result is the filtering engine result. Result *rules.MatchingResult // ID is the session identifier. ID string // MediaType is MIME media type. MediaType string // Charset is the response charset (if it's possible to parse it from // content-type). Charset string }
Session contains all the necessary data to filter requests and responses. It also contains the current state of the request. Throughout the HTTP request lifetime, session data is updated with new information.
There are two main stages of the HTTP request lifetime:
- Received the HTTP request headers. At this point, we can find all the rules matching the request using what we know. We assume the resource type by URL and "Accept" headers and look for matching rules. If there's a match, and the request should be blocked, we simply block it. Otherwise, we continue the HTTP request execution.
- Received the HTTP response headers. At this point we've got the content-type header so we know for sure what type of resource we're dealing with. We are looking for matching rules again, and update them. The possible outcomes are:
2.1. The request must be blocked. 2.2. The response must be modified (with a $replace or a $csp rule, for instance). 2.3. This is an HTML response so we need to filter the response body and apply cosmetic filters. 2.4. We should continue execution and do nothing with the response.
func NewSession ¶ added in v0.7.0
NewSession creates a new instance of the Session struct and initializes it. id -- unique session identifier req -- HTTP request data
func (*Session) SetResponse ¶ added in v0.7.0
SetResponse sets the response of this session This can also end in changing the request type