You can read more about that rule on [MDN](https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file%3A_URIs "Same-origin policy for file: URIs").
+<a id="my-case"></a>
I often violate that rule, when developing templates for dynamically rendered pages with [Thymeleaf](http://www.thymeleaf.org/ "Read more about the XML/XHTML/HTML5 template engine Thymeleaf"), or similar techniques.
That is, because I like to place the template-files on a subdirectory of the directory, that contains my webapp ( `src/main/webapp` with Maven):
Chrome:
Restart Chrome with `--disable-web-security` or `--allow-file-access-from-files` (for more, see this [question on Stackoverflow)](http://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome "Read more on how to turn of the Same-origin policy in chrome").
-## Quick Fix For Firefox
+## <a id="quick-solution"></a>Quick Fix For Firefox
If you develop with Firefox, there is a quick fix, to bypass the Same-origin policy for local files.
So, here is, what you have to do to fix this [broken example](http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html#maven-config-https "Jump to the example in the documentation of the jetty-maven-plugin"): the content shown for the file `jetty.xml` in the example is wrong. It has to look like the other example-files. That is, ith has to start with a `<Configure>`-tag. The corrected content of the file looks like this:
+<a id="jetty-xml"></a>
```html
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
If you are getting the error `[ERROR] Failed to execute goal org.eclipse.jetty:jetty-maven-plugin:9.0.5.v20130815:run (default-cli) on project FOOBAR: Failure: etc/jetty.keystore (file or directory not found) -> [Help 1]` now, this is because you have to create/get a certificate for your HTTPS-Connector. For development, a selfsigned certificate is sufficient. You can easily create one like back in the [good old `maven-jetty-plugin`-times](http://mrhaki.blogspot.de/2009/05/configure-maven-jetty-plugin-for-ssl.html "Example for configuring the HTTPS-Connector of the old maven-jetty-plugin"), with this command:
+<a id="keytool"></a>
```bash
keytool -genkey \
-alias jetty \
Just be sure, to change the example file `jetty-ssl.xml`, to reflect the path to your new keystore file and password. Your `jetty-ssl.xml` should look like:
+<a id="jetty-ssl-xml"></a>
```html
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
Unless you are running `mvn jetty:run` as `root`, you should see another error now: `[ERROR] Failed to execute goal org.eclipse.jetty:jetty-maven-plugin:9.0.5.v20130815:run (default-cli) on project FOOBAR: Failure: Permission denied -> [Help 1]`. This is, because the ports are set to the numbers `80` and `443` of the privileged port-range.
+<a id="jetty-http-xml"></a>
You have to change `jetty-http.xml` like this:
```html
</Configure>
```
+<a id="jetty-https-xml"></a>
... and `jetty-https.xml` like this:
```html
Because of that, I've created a simple 6-step quick-fix-guide to get the HTTPS-Connector of the `jetty-maven-plugin` running.
-## Quick Fix
+## <a id="quick-fix"></a>Quick Fix
1. Download [jetty.xml](/wp-uploads/2014/02/jetty.xml) or copy it [from above](#jetty-xml) and place it in `src/test/resources/jetty.xml`
1. Download [jetty-http.xml](/wp-uploads/2014/02/jetty-http.xml) or copy it [from above](#jetty-http-xml) and place it in `src/test/resources/jetty-http.xml`
But what is even worse: after [really turning off wordpress's automagically-messup-functionality](#disable "Jump to the tech-section, if you only want to find out, how to disable wordpress's auto-messup functionality"), nearly all my handwritten `<p>`-tags were gone, too.
So, if you want to turn of automatic `<p>-` and `<br>`-tags, you should really do it as early, as you can. Otherwise, you will have to clean up all your old posts afterwards like me. TI've lost some hours with usless HTML-editing today, because of that sh#%&\*!
-## How to disable them
+## <a id="disable"></a>How to disable them
The [wordpress-documentation of the build-in HTML-editor](https://codex.wordpress.org/TinyMCE#Automatic_use_of_Paragraph_Tags) links to [this post](http://redrokk.com/2010/08/16/removing-p-tags-in-wordpress/), which describs how to disable autmatic use of paragraph tags.
Simple open the file `wp-includes/default-filters.php` of you wordpress-installation and comment out the following line:
_If you want, that your clients also authentificate themselfs to your services, so that only clients with a trusted certificate can connect (2-Way-Authentication), client B also needs its own signed certificate to authenticate against service A and service A also needs access to the truststore, to be able to trust that certificate._
-## Simple Example-Scripts To Create A Private CA And Self-Signed Certificates With SAN-Extension
+## <a id="scripts"></a>Simple Example-Scripts To Create A Private CA And Self-Signed Certificates With SAN-Extension
The following two scripts automate the presented steps and may be useful, when setting up a private CA for Java-development:
- [Connect A Network Namespace To A Bridge](#netns2br)
- [Connect Two Bridges](#br2br)
-### Connect Two Network Namespaces
+### <a id="netns2netns"></a>Connect Two Network Namespaces
In this usage scenario, two [network namespaces](/virtual-networking-with-linux-network-namespaces "Network Namespaces Explained") (i.e., two virtual hosts) are connected with a virtual patch cable (the veth-pair).
One of the two network namespaces may be the default network namespace, but not both (see [Pitfall: Pointless Usage Of Veth-Pairs](#pointless "See Pitfall: Wrong (Or Better: Pointless) Usage Of Veth-Pairs")).
```
-### Connect A Network Namespace To A Bridge
+### <a id="netns2br"></a>Connect A Network Namespace To A Bridge
In this usage scenario, a [network namespace](/virtual-networking-with-linux-network-namespaces "Network Namespaces Explained") (i.e., a virtual host) is connected to a [bridge](/virtual-networking-with-linux-virtual-bridges "Virtual Bridges Explained") (i.e. a virtual network/switch) with a virtual patch cable (the veth-pair).
The network namespace may be the default network namespace (i.e., the local host).
In general, it is advisable, to use the first approach, if you do need a connection to the local host, because it does not clutter your default network namespace with two more interfaces (here: `veth0` and `link_2`).
-### Connect Two Bridges
+### <a id="br2br"></a>Connect Two Bridges
Receipt:
- [Capturing Packages On Virtual Interfaces](#capturing)
- [Wrong (Or Better: Pointless) Usage Of Veth-Pairs](#pointless)
-### Do Not Forget To Specifiy The Prefix-Length For The Addressses
+### <a id="prefix-length"></a>Do Not Forget To Specifiy The Prefix-Length For The Addressses
**If you forget to specifiy the prefix-length for one of the addresses, you will not be able to ping the host on the other end of the veth-pair.**
`192.168.111.1/24` specifies the address `192.168.111.1` as part of the subnet with the network-mask `255.255.255.0`. If you forget the prefix, the address will be interpreted as `192.168.111.1/32` and the kernel will not add a network-route. Hence, you will not be able to ping the other end ( `192.168.111.2`), because the kernel would not know, that it is reachable via the interface that belongs to the address `192.168.111.1`.
-### Capturing Packages On Virtual Interfaces
+### <a id="capturing"></a>Capturing Packages On Virtual Interfaces
If you run `tcpdump` on an interface in the default-namespace, the captured packages show up immediatly.
I.e.: You can watch the exchange of ICMP-packages live, as it happens.
_Do not ask me why — I just witnessed that odd behaviour on my linux-box and found it noteworthy, because I thought, that my setup was not working several times, before I realised, that I had to kill `tcpdump` to see the captured packages._
-### Wrong (Or Better: Pointless) Usage Of Veth-Pairs
+### <a id="pointless"></a>Wrong (Or Better: Pointless) Usage Of Veth-Pairs
This is another reason, why packages might not show up on the virtual interfaces of the configured veth-pair.
Often, veth-pairs are used as a simple example for virtual networking like in the following snippet:
## Step by Step (Uh Baby!)
-### Step I: Investigate the Structured Part
+### <a id="step-01"></a>Step I: Investigate the Structured Part
Let us start with the strictly structured part of the document: **the article and it's subsections**.
At first a minimal example with no markup except the `article`\- and the `section`-tags:
We can add headings of any kind ( `h1`- `h6`) here and will always get an identically structured outline, that reflects the text of our headings.
If we want to give the body a title, we have to place a heading outside and before any sectioning-elements:
-#### Example 05: Markup
+#### <a id="example-05"></a>Example 05: Markup
```html
<!DOCTYPE html>
For now, you only have to know, that in HTML5, sectioning elements define the structure of the outline.
Also, you should memorize, that the outline always has a single root without any siblings: the `body`.
-### Step II: Investigate the Page-Elements
+### <a id="step-2"></a>Step II: Investigate the Page-Elements
So, let us do the same with the tags that represent the different logical sections of a web-page: **the page-elements**.
We start with a minimal example again, that contains no markup except the `header`\- the `main` and the `footer`-tags:
We want a `h1`-heading for our main-content, because it is the important part of our page.
The header should have a `h2`-heading and the footer a `h3`-heading, because it is rather unimportant.
-#### Example 07: Markup
+#### <a id="example-07"></a>Example 07: Markup
```html
<!DOCTYPE html>
[View Example 13](/wp-uploads/2015/06/example-13.html)
+<a id="sectioning-elemnts"></a>
The HTML5 spec defines four [sectioning elements](http://www.w3.org/WAI/GL/wiki/Using_HTML5_section_elements "Read about the intended use of these sectioning elements"): `article`, `section`, `nav` and `aside`!
Some explain the confusion about this fact with the constantly evolving standard, that leads to [structurally unclear specifications](http://www.smashingmagazine.com/2013/01/18/the-importance-of-sections/#cad-middle "Jump to this rather lame excuse in an otherwise great article").
I will be frank:
**...it simply does not work at all!**
-## The Fix
+## <a id="fix"></a>The Fix
The simple fix for this problem is, to add a `@Bean` of type `InMemoryHttpTraceRepository` to your **`@Configuration`**-class:
```
-## The Explanation
+## <a id="explanation"></a>The Explanation
The cause of this problem is not a bug, but a legitimate change in the default configuration.
Unfortunately, this change is not noted in the according section of the documentation.
_By the way:_
Any other server, that can act as reverse proxy, or some real gateway,like [Zuul](https://github.com/Netflix/zuul "In real real-world you should consider something like Zuul of similar") would work as well, but we stick with good old NGINX, to keep it simple.
-## Switching The Setup Of Your OAuth2-Provider To Production
+## <a id="provider-production-setup"></a>Switching The Setup Of Your OAuth2-Provider To Production
In our example we are using GitHub as oauth2-provider and `example.com` as the domain, where the app should be found after the release.
So, we will have to change the **Authorization callback URL** to
_In order to tackle this chicken-egg-problem, we will fool our locally running browser to belive, that `example.com` is our local development system._
-## Setting Up The Alias for `example.com`
+## <a id="set-alias-for-domain"></a>Setting Up The Alias for `example.com`
On Linux/Unix this can be simply done by editing **`/etc/hosts`**.
You just have to add the domain ( `example.com`) at the end of the line that starts with `127.0.0.1`:
Locally running programms - like your browser - will now resolve `example.com` as `127.0.0.1`
-## Create A Virtual Network With Docker
+## <a id="create-virtual-network"></a>Create A Virtual Network With Docker
Next, we have to create a virtual network, where we can put in both containers:
_You might want to switch to Docker-Compose later._
_Especially, if you plan to set up an environment, that you will frequently reuse for manual tests or such._
-## Move The App Into The Virtual Network
+## <a id="move-app-into-virtual-network"></a>Move The App Into The Virtual Network
To move our app into the virtual network, we have to start it again with the additional parameter **`--network`**.
We also want to give it a name this time, by using **`--name`**, to be able to contact it by name.
- If you wonder, which containers are actually running, **`docker ps`** is your friend.
-## Starting the Reverse-Proxy Aka Gateway
+## <a id="start-gateway-in-virtual-network"></a>Starting the Reverse-Proxy Aka Gateway
Next, we will start NGINX alongside our app and configure it as reverse-proxy:
_You may as well use any other OAuth2-application here. For example your own POC, if you already have build one that works while running on `localhost`_
-## Some Short Notes On OAuth2
+## <a id="spring-boot-oauth2"></a>Some Short Notes On OAuth2
I will only explain the protocol in very short words here, so that you can understand what goes wrong in case you stumble across one of the many pitfalls, when setting up oauth2.
You can [read more about oauth2 elswhere](https://www.oauth.com/oauth2-servers/getting-ready/ "And you most probably should: At least if you are planning to use it in production!")
Configuration-keys starting with **`spring.security.oauth2.client.registration.github`** are choosing GitHub as the oauth2-provider and trigger a bunch of predifined default-configuration.
If you have set up your own oauth2-provider, you have to configure everything manually.
-## Running The App Inside Docker
+## <a id="build-a-docker-image"></a>Running The App Inside Docker
To faciliate the debugging - and because this most probably will be the way you are deploying your app anyway - we will start by building a docker-image from the app
projects / website / commitdiff