From cb207320ce67c6b63549a6c64b5a6edf164762c5 Mon Sep 17 00:00:00 2001 From: Dave Syer Date: Tue, 16 Dec 2014 09:24:30 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- spring-cloud.html | 60 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 56 insertions(+), 4 deletions(-) diff --git a/spring-cloud.html b/spring-cloud.html index c047e0d..4790325 100644 --- a/spring-cloud.html +++ b/spring-cloud.html @@ -483,6 +483,7 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b
  • Router and Filter: Zuul
  • @@ -2222,6 +2223,30 @@ server if you set a default route ("/"), for example zuul.route.home: / would route all traffic (i.e. "/**") to the "home" service.

    +
    +

    Plain Embedded Zuul

    +
    +

    You can also run a Zuul server without the proxying, or switch on parts of the proxying platform selectively, if you +use @EnableZuulServer (instead of @EnableZuulProxy). Any beans that you add to the application of type ZuulFilter +will be installed automatically.

    +
    +
    +

    In this case the routes into the Zuul server are +still specified by configuring "zuul.routes.*", but there is no service discovery and no proxying, so the +"serviceId" and "url" settings are ignored. For example:

    +
    +
    +
    application.yml
    +
    +
     zuul:
    +  routes:
    +    api: /api/**
    +
    +
    +
    +

    maps all paths in "/api/**" to the Zuul filter chain.

    +
    +

    Spring Cloud Bus

    @@ -2605,13 +2630,40 @@ correct header.

    How does it work? The @EnableOAuth2Sso annotation pulls in spring-cloud-starter-security (which you could do manually in a -traditional app), and that has some autoconfiguration for a -ZuulFilter, which itself is activated because Zuul is on the +traditional app), and that in turn triggers some autoconfiguration for +a ZuulFilter, which itself is activated because Zuul is on the classpath (via @EnableZuulProxy). The -filter +filter just extracts an access token from the currently authenticated user, and puts it in a request header for the downstream requests.

    +
    +

    You can control the authorization behaviour downstream of an +@EnableZuulProxy through the proxy.auth.* settings. Example:

    +
    +
    +
    application.yml
    +
    +
    proxy:
    +  auth:
    +    routes:
    +      customers: oauth2
    +      stores: passthru
    +      recommendations: none
    +
    +
    +
    +

    In this example the "customers" service gets an OAuth2 token relay, +the "stores" service gets a passthrough (the authorization header is +just passed downstream), and the "recommendations" service has its +authorization header removed. The default behaviour is to do a token +relay if there is a token available, and passthru otherwise.

    +
    +
    +

    See + +ProxyAuthenticationProperties for full details.

    +
    @@ -2794,7 +2846,7 @@ service or the "resource" service if you have one).