anchor.diff:  
   Re-launch the resource server and open the UI up in a new browser window.
   
  -== Why Doesn't it All Work With Cookies?
  +//== Why Doesn't it All Work With Cookies?
  +== なぜ Cookie だけではうまく動かないの ?
   
   We had to use a custom header and write code in the client to populate the header, which isn't terribly complicated, but it seems to contradict the advice in <<_the_login_page_angular_js_and_spring_security_part_ii,Part II>> to use cookies and sessions wherever possible. The argument there was that not to do so introduces additional unecessary complexity, and for sure the implementation we have now is the most complex we have seen so far: the technical part of the solution far outweighs the business logic (which is admittedly tiny). This is definitely a fair criticism (and one we plan to address in the next section in this series), but let's just briefly look at why it's not as simple as just using cookies and sessions for everything.
   
  
positive.code: [[_the_resource_server_angular_js_and_spring_security_part_iii]]
  = The Resource Server
  
  In this section we continue <<_the_login_page_angular_js_and_spring_security_part_ii,our discussion>> of how to use http://projects.spring.io/spring-security[Spring Security] with http://angularjs.org[Angular JS] in a "single page application". Here we start by breaking out the "greeting" resource that we are using as the dynamic content in our application into a separate server, first as an unprotected resource, and then protected by an opaque token. This is the third in a series of sections, and you can catch up on the basic building blocks of the application or build it from scratch by reading the <<_spring_and_angular_js_a_secure_single_page_application,first section>>, or you can just go straight to the source code in Github, which is in two parts: one where the https://github.com/dsyer/spring-security-angular/tree/master/vanilla[resource is unprotected], and one where it is https://github.com/dsyer/spring-security-angular/tree/master/spring-session[protected by a token].
  
  
negative.code: 
  TIP: if you don't have a redis server running locally you can easily spin one up with https://www.docker.com/[Docker] (on Windows or MacOS this requires a VM). There is a http://docs.docker.com/compose/[`docker-compose.yml`] file in the https://github.com/dsyer/spring-security-angular/tree/master/spring-session/docker-compose.yml[source code in Github] which you can run really easily on the command line with `docker-compose up`.
  
  //== Sending a Custom Token from the UI
  == UI からカスタムトークンを送信する
  
  The only missing piece is the transport mechanism for the key to the data in the store. The key is the `HttpSession` ID, so if we can get hold of that key in the UI client, we can send it as a custom header to the resource server. So the "home" controller would need to change so that it sends the header as part of the HTTP request for the greeting resource. For example:
  
  