I percorsi HATEOAS non sono validi quando si utilizza un gateway API in un'app di avvio di primavera

Question

Ho due applicazioni di avvio a molla in cui una di esse funge da gateway API (come illustrato qui Spring Example). L'altra che è cablata nella prima è l'esposizione di un servizio di profilo che utilizza il poggia-dati molla (spring-data-neo4j-rest).

La prima applicazione si avvia sulla porta 8080 e sta usando Zuul per instradare le richieste al secondo nel modo seguente:

zuul: 
    routes: 
    profiles: 
     path: /profiles/** 
     url: http://localhost:8083/profiles/ 

Questo tutto funziona benissimo e le richieste di http://localhost:8080/profiles vengono serviti dalla seconda applicazione. Il problema però è che i link HATEOAS nella risposta non sono corretti. La risposta da chiamare che secondo servizio siano corrette:

{ 
    "_links": { 
     "self": { 
      "href": "http://localhost:8083/profiles{?page,size,sort}", 
      "templated": true 
     }, 
     "search": { 
      "href": "http://localhost:8083/profiles/search" 
     } 
    }, 
    "_embedded": { 
     "profiles": [ 
      { 
       "name": "Andrew Rutter", 
       "_links": { 
        "self": { 
         "href": "http://localhost:8083/profiles/0" 
        } 
       } 
      }, 
      { 
       "name": "Andrew Rutter", 
       "_links": { 
        "self": { 
         "href": "http://localhost:8083/profiles/1" 
        } 
       } 
      } 
     ] 
    }, 
    "page": { 
     "size": 20, 
     "totalElements": 2, 
     "totalPages": 1, 
     "number": 0 
    } 
} 

Ma quando questo torna al mio gateway API, i link vengono riscritte per

{ 
    "name": "Andrew Rutter", 
    "_links": { 
    "self": { 
     "href": "http://localhost:8080/profiles/profiles/0" 
    } 
    } 
} 

che è l'alias percorso gateway più il servizio effettivo base Uri. Mi manca un'opzione zuul per disabilitare quel comportamento e basta lasciare l'hateoas uri in posizione con una regolazione host. O c'è un modo per il mio servizio dietro il gateway di essere collegato a/piuttosto che l'endpoint di risorsa predefinito di/profili (in questo caso) che eviterebbe l'aggiunta del percorso indesiderato.

Grazie!

Answer 1

Zuul o Spring-Cloud aggiunge l'intestazione "X-Forwarded-Host" a tutte le richieste inoltrate, che Spring-hateo rispetta e modifica i collegamenti in modo appropriato. Per citare i documenti Spring-Cloud:

L'intestazione X-Forwarded-Host aggiunta alle richieste inoltrate per predefinita. Per disattivarlo impostare zuul.addProxyHeaders = false. Il prefisso percorso viene rimosso per impostazione predefinita e la richiesta al backend preleva un'intestazione "X-Forwarded-Prefix" ("/ myusers" negli esempi precedenti).

si può provare la correzione raccomandata, che è quello di impostare le zuul.addProxyHeaders=false

Answer 2

avanti Zuul al/profili contextPath. l'impostazione di questa come di configurazione

Prova:

zuul: 
    routes: 
    profiles: 
     path: /profiles/** 
     url: http://localhost:8083/ 

Answer 3

Dopo aver lottato un po 'con lo stesso problema, finalmente ho provato zuul.addProxyHeaders = true e funziona! I collegamenti non sono più interrotti.

Answer 4

Nell'app demo che ho utilizzato per SpringOne nel mio intervento su Spring Data REST, ho la seguente configurazione sia per gestire le riscritture URI sia per regolare le intestazioni dei prefissi impostate correttamente.

zuul: 
    routes: 
    api: 
     path: /api/** 
     serviceId: spring-a-gram-backend 
     stripPrefix: false 
    files: 
     path: /files/** 
     serviceId: spring-a-gram-mongodb-fileservice 
     stripPrefix: false 

Guardalo in pieno al https://github.com/gregturn/spring-a-gram/blob/master/spring-a-gram-frontend/src/main/resources/application.yml#L23-L32

Answer 5

Ho avuto esattamente lo stesso problema.Cambiare la configurazione come segue:

zuul: 
    routes: 
    profiles: 
     path: /profiles/** 
     url: http://localhost:8083 
     stripPrefix: false 

Questo indirizza tutte le richieste che vanno al di corrispondenza del gateway "/ profili/**" al server back-end "http://localhost:8083" e lascia il prefisso (nel tuo caso "/ profili" dal questo è ciò che ha accompagnato il percorso).