anchor.diff:  
   The second entry there is the request from the client to the gateway on "/resource" and you can see the cookies (added by the browser) and the CSRF header (added by Angular as discussed in link:second[Part II]). The first entry has `remote: true` and that means it's tracing the call to the resource server. You can see it went out to a uri path "/" and you can see that (crucially) the cookies and CSRF headers have been sent too. Without Spring Session these headers would be meaningless to the resource server, but the way we have set it up it can now use those headers to re-constitute a session with authentication and CSRF token data. So the request is permitted and we are in business!
   
  -== Conclusion
  +//== Conclusion
  +== 結論
   
   We covered quite a lot in this section but we got to a really nice place where there is a minimal amount of boilerplate code in our two servers, they are both nicely secure and the user experience isn't compromised. That alone would be a reason to use the API Gateway pattern, but really we have only scratched the surface of what that might be used for (Netflix uses it for https://github.com/Netflix/zuul/wiki/How-We-Use-Zuul-At-Netflix[a lot of things]). Read up on http://projects.spring.io/spring-cloud/[Spring Cloud] to find out more on how to make it easy to add more features to the gateway. The <<_sso_with_oauth2_angular_js_and_spring_security_part_v,next section>> in this series will extend the application architecture a bit by extracting the authentication responsibilities to a separate server (the Single Sign On pattern).
positive.code: 
  Now when we fire up the servers everything is working and the requests are being proxied through the UI (API Gateway) to the resource server.
  
  === Further Simplifications
  
  Even better: we don't need the CORS filter any more in the resource server. We threw that one together pretty quickly anyway, and it should have been a red light that we had to do anything as technically focused by hand (especially where it concerns security). Fortunately it is now redundant, so we can just throw it away, and go back to sleeping at night!
  
  == Securing the Resource Server
  
  You might remember in the intermediate state that we started from there is no security in place for the resource server. 
  
  
negative.code: [[_the_api_gateway_pattern_angular_js_and_spring_security_part_iv]]
  //= The API Gateway
  = API ゲートウェイ
  
  In this section we continue <<_the_resource_server_angular_js_and_spring_security_part_iii,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 show how to build an API Gateway to control the authentication and access to the backend resources using http://projects.spring.io/spring-cloud/[Spring Cloud]. This is the fourth 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 https://github.com/dsyer/spring-security-angular/tree/master/proxy[source code in Github]. In the <<_the_resource_server_angular_js_and_spring_security_part_iii,last section>> we built a simple distributed application that used https://github.com/spring-projects/spring-session/[Spring Session] to authenticate the backend resources. In this one we make the UI server into a reverse proxy to the backend resource server, fixing the issues with the last implementation (technical complexity introduced by custom token authentication), and giving us a lot of new options for controlling access from the browser client.
  
  