Charts: [bitnami/wordpress] Ingress exposes internal 8080 port when trying to access /wp-admin (only without trailing slash)

Created on 22 Mar 2020 · 19Comments · Source: bitnami/charts

Which chart:
wordpress-9.0.4

Description
I have just installed wordpress chart on GKE, exposed with http and https.
When I try opening http(s)://my-url/wp-admin (no trailing slash) I get:

→ curl https://my-url/wp-admin

301 Moved Permanently

Moved Permanently

The document has moved here.

However if I add trailing slash everything works ok

Steps to reproduce the issue:

Install chart with following values.yaml:

service:
  type: LoadBalancer
persistence:
  enabled: false

Once it is deployed try opening /wp-admin

Describe the results you received:

301 response with trailing slash to "/wp-admin/" with port 8080 instead of 80

Describe the results you expected:

301 response with trailing slash to port 80

Version of Helm and Kubernetes:

Output of helm version:

version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.8-gke.3", GitCommit:"2ccf2c797713077f4a3d0f87c4b4bae725362326", GitTreeState:"clean", BuildDate:"2020-01-29T19:27:22Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

stale

Source

rgrebski

👍3

Most helpful comment

The easiest thing I can think of is adding ingress annotation that will do redirect by itself:

    nginx.ingress.kubernetes.io/configuration-snippet: |
      location ~ /wp-admin$ {
           return 301 /wp-admin/;
       }

I know this does not solve root cause, just wanted to share a workaround for now

rgrebski on 30 Apr 2020

👍6

All 19 comments

Hi @rgrebski, thank you for reporting this issue, it is reproducible not only in GKE also in other environments when LoadBalancer is used. You can try other URLs like

All of them are working fine, it seems there is a wrong redirection somewhere when going /wp-admin and we need to find it.

dani8art on 24 Mar 2020

Thanks for the update, please note that I observe the same when using nginx-ingress + NodePort.
I took a quick look at nginx config and it seems fine, my guess is that its either apache or wordpress config issue. I will do some more "debugging" over the weekend

rgrebski on 24 Mar 2020

I did some tests from the container so I could realize apache is doing the redirection for /wp-admin while Wordpress is doing the others. If you go inside the container

$ kubectl exec -ti w-wordpress-7b689fb64b-qrg9j bash

You could execute

$ curl -v http://localhost:8080/wp-admin
> GET /wp-admin HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 25 Mar 2020 07:57:09 GMT
< Server: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/7.4.3
< Location: http://localhost:8080/wp-admin/
< Content-Length: 239
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://localhost:8080/wp-admin/">here</a>.</p>
</body></html>

then if you do

$ curl -v http://localhost:8080/admin 
> GET /admin HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Wed, 25 Mar 2020 07:59:10 GMT
< Server: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/7.4.3
< X-Powered-By: PHP/7.4.3
< Expires: Wed, 11 Jan 1984 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate, max-age=0
< Link: <http://localhost:8080/wp-json/>; rel="https://api.w.org/"
< X-Redirect-By: WordPress
< Location: http://localhost:8080/wp-admin/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<

then we could see three main differences

HTTP redirect codes are difference /wp-admin -> 301 /admin -> 302
Body /wp-admin has body
/admin has a header X-Redirect-By: WordPress

The thing is that k8s service which is doing the proxy between pods is not interpreting the first redirection well if you try

$ curl -v http://<service_ip>/wp-admin
## redirect to http://<service_ip>:8080/wp-admin/

however, if you do

$ curl -v http://<service_ip>/admin
## redirect to http://<service_ip>/wp-admin/

dani8art on 25 Mar 2020

👍2

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

stale[bot] on 9 Apr 2020

Hi @rgrebski any updates on that? did you try something more? were you able to solve the problems?

dani8art on 13 Apr 2020

@dani8art I have been quite busyrecently, I will handle the issue this weekend

rgrebski on 15 Apr 2020

Ok good, let's keep in touch! thx

dani8art on 15 Apr 2020

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

stale[bot] on 30 Apr 2020

The easiest thing I can think of is adding ingress annotation that will do redirect by itself:

    nginx.ingress.kubernetes.io/configuration-snippet: |
      location ~ /wp-admin$ {
           return 301 /wp-admin/;
       }

I know this does not solve root cause, just wanted to share a workaround for now

rgrebski on 30 Apr 2020

👍6

Thanks for sharing the solution! We're glad you were able to fix this.

We have found similar issues in a past support case, i.e. with phpMyAdmin (accessing from /phpmyadmin/ works but not /phpmyadmin) and it looks related to some NGINX configuration.

However, we've not yet identified the issue. We've associated an internal task with this issue, with the hope of being able to get back and let you know what the issue on the other case was.

marcosbc on 1 May 2020

Thank you @rgrebski for the workaround, it really helped !
Any update about the "long term" resolution @marcosbc ?

v-six on 20 May 2020

Hi @v-six , unfortunately we can not give you an ETA and we've not yet identified the root cause for this issue. We would try to identify, however, if you guys have a chance and would like to contribute to the bitnami/wordpress and bitnami/bitnami-docker-wordpress, we will be happy to handle the PRs. Thank you so much for your feedback!

dani8art on 21 May 2020

Hi, it seems this behavior is happening because of the NGINX absolute_redirect configuration: http://nginx.org/en/docs/http/ngx_http_core_module.html#absolute_redirect

Setting the following configuration to your NGINX server should fix the issue:

absolute_redirect off;

marcosbc on 3 Jul 2020

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

stale[bot] on 18 Jul 2020

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

stale[bot] on 25 Jul 2020

bilaltas on 5 Nov 2020

Hi it seems this error is fixed as commented in https://github.com/bitnami/charts/issues/2111#issuecomment-653546313, did you faced it after applying this fix?

dani8art on 6 Nov 2020

I think it should be applied on the build itself since it's always necessary to prevent being redirected to the internal port. It's not good practice for WP image users to apply that configuration every time. Right?

bilaltas on 7 Nov 2020

We think so as well, we have a task to apply it, unfortunately we can not give you an ETA, however, we are open to contributions if you have a chance and would like to contribute to the bitnami/wordpress and bitnami/bitnami-docker-wordpress, we will be happy to handle the PRs. Thank you so much for your feedback!

dani8art on 11 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings