anchor.diff:  
   So the UI application is ready and will include the session ID in a header called "X-Auth-Token" for all calls to the backend.
   
  -== Authentication in the Resource Server
  +//== Authentication in the Resource Server
  +== リソースサーバにおける認証
   
   There is one tiny change to the resource server for it to be able to accept the custom header. The CORS filter has to nominate that header as an allowed one from remote clients, e.g.
   
  
positive.code: 
  If you try loading that resource from the UI (on port 8080) in a browser, you will find that it doesn't work because the browser won't allow the XHR request.
  
  == CORS Negotiation
  
  The browser tries to negotiate with our resource server to find out if it is allowed to access it according to the http://en.wikipedia.org/wiki/Cross-origin_resource_sharing[Cross Origin Resource Sharing] protocol. It's not an Angular JS responsibility, so just like the cookie contract it will work like this with all JavaScript in the browser. The two servers do not declare that they have a common origin, so the browser declines to send the request and the UI is broken.
  
  
negative.code: ...
  ----
  
  //=== Server Side Changes
  === サーバ側の変更
  
  The https://github.com/dsyer/spring-security-angular/blob/master/vanilla/ui/src/main/java/demo/UiApplication.java[UI server] is trivial to change: we just need to remove the `@RequestMapping` for the greeting resource (it was "/resource"). Then we need to create a new resource server, which we can do like we did in the <<_spring_and_angular_js_a_secure_single_page_application,first section>> using the https://start.spring.io[Spring Boot Initializr]. E.g. using curl on a UN*X like system:
  
  