Mes questions:
1) Pourquoi est-ce que j'obtiens http comme schéma dans l'en-tête Location lorsque la requête d'origine du navigateur a été faite avec https?
2) Est-ce une charge wildfly problème d'équilibreur?
Mon en-tête de demande est:
content-length: 0 date: Thu, 03 Jan 2019 04:55:42 GMT location: http://10.43.201.207/myapp/dashboard.html?init=1 server: WildFly/12 set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly status: 302 x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-powered-by: Undertow/1 x-xss-protection: 1; mode=block
Mon en-tête de réponse est:
method: POST scheme: https accept-encoding: gzip, deflate, br accept-language: en-US,en;q=0.9 content-length: 39 content-type: application/x-www-form-urlencoded origin: https://10.43.201.207 referer: https://10.43.201.207/myapp/login.html
3 Réponses :
L'équilibreur de charge supprime-t-il le TLS et transmet-il la requête à l'application en tant que HTTP? Si tel est le cas, l'application, lorsqu'elle effectue une redirection, utilise probablement le même protocole sur lequel elle a reçu la demande.
Si tel est le cas, demandez à l'application de forcer https ou demandez à l'équilibreur de charge de réécrire les réponses qui reviennent.
Vous devrez peut-être définir proxy-address-forwarding = "true" et / ou request_header_add X-Forwarded-Proto https .
Salut Mennon, comment puis-je vérifier ceci: - l'équilibreur de charge supprime le TLS et transmet la demande à l'application en tant que HTTP?
Vous pouvez vérifier où le certificat TLS est configuré - s'il se trouve sur l'équilibreur de charge, il s'occupe du décryptage, si c'est sur l'application (ou le serveur d'application) à la place, alors c'est le cas. Ou si ce n'est pas vous qui avez configuré TLS, demandez à la personne / à l'équipe qui l'a fait.
@Mennon et @ Subodh, nous avons ajouté proxy-address-forwarding = "true" dans la configuration du serveur d'applications wildfly, cela a fonctionné
une autre solution simple serait de ne pas définir du tout le schéma dans le champ d'en-tête Location
Voici l'explication détaillée de la solution au problème ci-dessus:
Nous avons un équilibreur de charge assis devant deux serveurs wildfly. L'équilibreur de charge gère la négociation SSL et force tout le trafic sur https , les nœuds wildfly n'ont pas de certificats et le trafic entre l'équilibreur de charge et les serveurs n'est pas chiffré, les nœuds wildfly ne savent rien du SSL. La communication entre l'équilibreur de charge et les nœuds wildfly se fait via le protocole http .
Lorsqu'un utilisateur accède à une page protégée, par exemple https: // someip / app
Le déroulement des demandes est le suivant:
https http . proxy-address-forwarding = "true" dans le http du nœud de serveur wildlfy
auditeur Une autre option consiste à demander à l'équilibreur de charge d'ajouter l'en-tête Strict-Transport-Security à la réponse du serveur, par exemple:
Strict-Transport-Security max-age=300;
Cela indiquera effectivement au client qu'il doit toujours utiliser https pour contacter votre serveur.
Cela semble être une redirection.
Salut Robert, ouais correct, il s'agit uniquement de redirection, mais nous ne disons pas comme redirection avec http. Dans notre code LoginServlet, nous écrivons comme ci-dessous dans la méthode doPost
response.sendRedirect ("dashboard.html");J'ai fait quelques recherches avant de commenter votre question. Cela semble suggérer qu'une redirection peut se produire avant que la négociation TLS ne soit réalisée.
Dois-je donc avoir besoin de changer mon code LoginServlet quelque chose comme s'il s'agit de http remplacer par https ? ou il me manque une configuration d'équilibrage de charge?
Salut, je n'ai pas eu d'indice à ce sujet, pourquoi l'en-tête de la réponse est http, quelqu'un peut-il me suggérer ici comment puis-je sortir de ce problème?