@DD063520 do you have a minimum example docker-compose file that you might be able to provide for your setup?

This I think (60% sure) is due to the fact that the host knows it is 'https://my.host' but we are calling it over 'wikibase-docker.svc'

Yes, for a deployment of wikibase and quickstatements, calls for OAuth should use the real protocol and domain name to avoid signature errors.

The other route around this is making things like quickstatements call your reverse proxy with a Host header set, so the proxy knows where the call should go.
This requires code modifications, for quickstatements this means magnustools. This was done for wbstack and wikibase.cloud in a fork that should be upstreamed if it is useful for others.
The evil hack is https://github.com/wbstack/magnustools/blob/e0fadb9a7149f0b06ee419e554c2f78341c4f5b7/public_html/php/WbstackMagnusOauth.php which overrides some stuff to do with config parsing etc.

You may benefit from looking at the old reverse proxy setup for wbstack.com
https://github.com/wbstack/deploy/blob/1f5853eb832e40e3a39c7a9e54ab9a3bf555c9d0/k8s/helm/platform-nginx/nginx.conf
Infact the whole of wbstack.com was and wikibase.cloud still is behind a reverse proxy
(current wikibase.cloud config is not yet public)

In the wbstack nginx config you can find

real_ip_header X-Forwarded-For;
proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $realip_remote_addr";
proxy_set_header Host                   $http_host;

but it is not working either. The wikibase still replies 302 and points to the same redirect. Strangely this is only happening for 'https://my.host/w/index.php?title=Special:OAuth' Others paths are fine.

Could you in a single line / bullet points outline the various redirect steps? I found this part a little hard to follow above.

Hi,

thank you for the response! The nginx config look like this:

server {

    server_name wikibase.my.host;

    client_max_body_size 2M;

    location / {
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto: https;
        proxy_pass http://127.0.0.1:8080;

    }

    listen 443 ssl; 
    ssl_certificate /etc/letsencrypt/live/wikibase.my.host/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/wikibase.my.host/privkey.pem; 
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

}

server {
    if ($host = wikibase.my.host) {
        return 301 https://$host$request_uri;
    }

    listen 80;

    server_name wikibase.my.host
    return 404; 


}

Very similar for the different services. My idea, instead of making quickstatements setting the "Host" header, was to put it in the nginx configuration. Basically we want always, for every request going to the wikibase, to say that the $host is called. Like this we do not have to change the code in quickstatements. The problem is the one I described above:

"the Wikibase responds with 302 Found and redirects to the exact same URL. The reason (I guess) is that over the revers proxy the call is going to localhost:8080 and so the OAuth says, try again over 'https://my.host'."

(the Host header is ignored! and only for Special:OAuth urls as far as I can see )

Concretely as an example you can try here:

curl 'https://wikibase.the-qa-company.com/w/index.php?title=Special:OAuth/token&format=json&oauth_verifier=d9fc52fe7492a7f4626a680b43e389ff&oauth_consumer_key=177700dc97c6e471e106234ba3275972&oauth_token=8060d58cf24aece2d0b486c7b0705820&oauth_version=1.0&oauth_nonce=0787eb5ff478a613545670de5196d3c3&oauth_timestamp=1661179411&oauth_signature_method=HMAC-SHA1&oauth_signature=5RrE2SKUstzSsbGrw2HjS9pmvCQ%3D' -v -L

For the minimal docker compose see below. I marked with

CHANGE FROM OFFICIAL RELEASE

the changes from the official release.

If you wish I can share the access to the instance and show you. Might be quicker.

cat docker-compose.yml

# Example Wikibase docker-compose setup
version: '3.4'

x-common-variables: &wikibase_variables
  DB_SERVER: mysql.svc:3306
  MW_ADMIN_NAME: ${MW_ADMIN_NAME}
  MW_ADMIN_PASS: ${MW_ADMIN_PASS}
  MW_ADMIN_EMAIL: ${MW_ADMIN_EMAIL}
  MW_WG_SECRET_KEY: ${MW_SECRET_KEY}
  # Disable jobs running after requests when wikibase_jobrunner is defined
  MW_WG_JOB_RUN_RATE: 0
  DB_USER: ${DB_USER}
  DB_PASS: ${DB_PASS}
  DB_NAME: ${DB_NAME}
  WIKIBASE_HOST: ${WIKIBASE_HOST}

services:
  wikibase:
    image: "${WIKIBASE_BUNDLE_IMAGE_NAME}"
    links:
      - mysql
    depends_on:
      - mysql
    restart: unless-stopped
    ports:
      - "${WIKIBASE_PORT}:80"
    volumes:
      ## This shares the configuration with jobrunner
      - shared:/var/www/html/:rw

      ## Uncomment this next line to mount your own LocalSettings.php file
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
      - ./LocalSettings.php:/var/www/html/LocalSettings.d/LocalSettings.override.php
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------

    networks:
      default:
        aliases:
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
          #- ${WIKIBASE_HOST}
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
         - wikibase-docker.svc
    environment:
      <<: *wikibase_variables
      WIKIBASE_PINGBACK:
      MW_WG_ENABLE_UPLOADS:

  wikibase_jobrunner:
    image: "${WIKIBASE_BUNDLE_IMAGE_NAME}"
    entrypoint: /bin/bash
    command:  /jobrunner-entrypoint.sh
    links:
      - mysql
    depends_on:
      - mysql
    restart: always
    volumes:
      - shared:/shared/:ro
      - ./jobrunner-entrypoint.sh:/jobrunner-entrypoint.sh
    networks:
      default:
        aliases:
          - wikibase-jobrunner.svc
    environment:
      <<: *wikibase_variables
      MAX_JOBS: ${MAX_JOBS}

  mysql:
    image: "${MYSQL_IMAGE_NAME}"
    restart: unless-stopped
    volumes:
      - mediawiki-mysql-data:/var/lib/mysql
    environment:
      # CONFIG - Change the default values below (should match values passed to wikibase)
      MYSQL_DATABASE: ${DB_NAME}
      MYSQL_USER: ${DB_USER}
      MYSQL_PASSWORD: ${DB_PASS}
      MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
    networks:
      default:
        aliases:
         - mysql.svc

volumes:
  shared:
  mediawiki-mysql-data:

cat docker-compose.extra.yml

# Additional services example
version: '3.4'

x-common-variables: &wikibase_extra_variables
  MW_ELASTIC_HOST: ${MW_ELASTIC_HOST}
  MW_ELASTIC_PORT: ${MW_ELASTIC_PORT}

services:

  wikibase:
    volumes:
      - quickstatements-data:/quickstatements/data
      - ./extra-install.sh:/extra-install.sh
    environment:
      <<: *wikibase_extra_variables
      QS_PUBLIC_SCHEME_HOST_AND_PORT:

  wikibase_jobrunner:
    environment:
      <<: *wikibase_extra_variables

  elasticsearch:
    image: "${ELASTICSEARCH_IMAGE_NAME}"
    restart: unless-stopped
    volumes:
      - elasticsearch-data:/usr/share/elasticsearch/data
    networks:
      default:
        aliases:
         - elasticsearch.svc
    environment:
      discovery.type: single-node
      ES_JAVA_OPTS: "-Xms512m -Xmx512m -Dlog4j2.formatMsgNoLookups=true"

  wdqs-frontend:
    image: "${WDQS_FRONTEND_IMAGE_NAME}"
    restart: unless-stopped
    ports:
     - "${WDQS_FRONTEND_PORT}:80"
    depends_on:
      - wdqs-proxy
    networks:
      default:
        aliases:
         - ${WDQS_FRONTEND_HOST}
    environment:
      - WIKIBASE_HOST=${WIKIBASE_HOST}
      - WDQS_HOST=wdqs-proxy.svc
  wdqs:
    image: "${WDQS_IMAGE_NAME}"
    restart: unless-stopped
    command: /runBlazegraph.sh
    volumes:
      - query-service-data:/wdqs/data
    networks:
      default:
        aliases:
         - wdqs.svc
    environment:
      - WIKIBASE_HOST=${WIKIBASE_HOST}
      - WDQS_HOST=wdqs.svc
      - WDQS_PORT=9999
    expose:
      - 9999

  wdqs-proxy:
    image: "${WDQS_PROXY_IMAGE_NAME}"
    restart: unless-stopped
    environment:
      - PROXY_PASS_HOST=wdqs.svc:9999
    depends_on:
      - wdqs
    networks:
      default:
        aliases:
         - wdqs-proxy.svc

  wdqs-updater:
    image: "${WDQS_IMAGE_NAME}"
    restart: unless-stopped
    command: /runUpdate.sh
    depends_on:
    - wdqs
    - wikibase
    networks:
      default:
        aliases:
         - wdqs-updater.svc
    environment:
     - WIKIBASE_HOST=${WIKIBASE_HOST}
     - WDQS_HOST=wdqs.svc
     - WDQS_PORT=9999
     # CONFIG - WIKIBASE_SCHEME can be set to 'https' if the updater should expect https concept uris

  quickstatements:
    image: "${QUICKSTATEMENTS_IMAGE_NAME}"
    restart: unless-stopped
    volumes:
      - quickstatements-data:/quickstatements/data
    ports:
      - "${QUICKSTATEMENTS_PORT}:80"
    depends_on:
      - wikibase
    networks:
      default:
        aliases:
         - ${QUICKSTATEMENTS_HOST}
    environment:
      - QUICKSTATEMENTS_HOST
      - QS_PUBLIC_SCHEME_HOST_AND_PORT
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
      - WIKIBASE_SCHEME_AND_HOST=https://my.host
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
      - WB_PUBLIC_SCHEME_HOST_AND_PORT=http://${WIKIBASE_HOST}:${WIKIBASE_PORT}
      - WB_PROPERTY_NAMESPACE=122
      - "WB_PROPERTY_PREFIX=Property:"
      - WB_ITEM_NAMESPACE=120
      - "WB_ITEM_PREFIX=Item:"
      - OAUTH_CONSUMER_KEY=${OAUTH_CONSUMER_KEY}
      - OAUTH_CONSUMER_SECRET=${OAUTH_CONSUMER_SECRET}

volumes:
  LocalSettings:
  query-service-data:
  elasticsearch-data:
  quickstatements-data:
  mediawiki-mysql-data:

cat .env

## Example / Template .env file for Wikibase release pipeline docker-compose example
# WARNING: Do not add comments on the same line as env vars, as in some environments they will be included in the var!

## Image Configuration
WIKIBASE_IMAGE_NAME=wikibase/wikibase:1.36.3-wmde.5
WDQS_IMAGE_NAME=wikibase/wdqs:0.3.97-wmde.5
WDQS_FRONTEND_IMAGE_NAME=wikibase/wdqs-frontend:wmde.5
ELASTICSEARCH_IMAGE_NAME=wikibase/elasticsearch:6.8.23-wmde.5
WIKIBASE_BUNDLE_IMAGE_NAME=wikibase/wikibase-bundle:1.36.3-wmde.5
QUICKSTATEMENTS_IMAGE_NAME=wikibase/quickstatements:wmde.5
WDQS_PROXY_IMAGE_NAME=wikibase/wdqs-proxy:wmde.5
MYSQL_IMAGE_NAME=mariadb:10.3

## Mediawiki Configuration
## Admin password
## Passwords must be at least 10 characters.
## Your password must be different from your username.
## Your password must not appear within your username.
## The password must not be in a list of very commonly used passwords. Please choose a unique password.
MW_ADMIN_PASS=change-this-password
MW_ADMIN_NAME=admin
MW_ADMIN_EMAIL=admin@example.com
MW_SECRET_KEY=some-secret-key
MW_WG_ENABLE_UPLOADS=false

## Jobrunner Configuration
MAX_JOBS=1

## Database Configuration
DB_NAME=my_wiki
DB_USER=sqluser
DB_PASS=change-this-sqlpassword

## Wikibase Configuration
WIKIBASE_PINGBACK=false
# wikibase.svc is the internal docker hostname, change this value to the public hostname
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
WIKIBASE_HOST=wikibase.my.host
WIKIBASE_PORT=8080
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------

## WDQS-frontend Configuration
# wdqs-frontend.svc is the internal docker hostname, change this value to the public hostname
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
WDQS_FRONTEND_HOST=query.my.host
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
WDQS_FRONTEND_PORT=8834

## Quickstatements Configuration
# quickstatements.svc is the internal docker hostname, change this value to the public or local hostname
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
QS_PUBLIC_SCHEME_HOST_AND_PORT=https://quickstatements.wikibase.my.host
QUICKSTATEMENTS_HOST=quickstatements.wikibase.my.host
--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
QUICKSTATEMENTS_PORT=8840

## ElasticSearch
## Comment out MW_ELASTIC_HOST to disable ElasticsSearch
## See https://github.com/wmde/wikibase-release-pipeline/blob/wmde.5/Docker/build/WikibaseBundle/LocalSettings.d.template/WikibaseCirrusSearch.php#L6
MW_ELASTIC_HOST=elasticsearch.svc
MW_ELASTIC_PORT=9200

cat LocalSettings.php

<?php

/*******************************/
/* Enable Federated properties */
/*******************************/
#$wgWBRepoSettings['federatedPropertiesEnabled'] = true;

/*******************************/
/* Enables ConfirmEdit Captcha */
/*******************************/
#wfLoadExtension( 'ConfirmEdit/QuestyCaptcha' );
#$wgCaptchaQuestions = [
#  'What animal' => 'dog',
#];

#$wgCaptchaTriggers['edit']          = true;
#$wgCaptchaTriggers['create']        = true;
#$wgCaptchaTriggers['createtalk']    = true;
#$wgCaptchaTriggers['addurl']        = true;
#$wgCaptchaTriggers['createaccount'] = true;
#$wgCaptchaTriggers['badlogin']      = true;

/*******************************/
/* Disable UI error-reporting  */
/*******************************/
#ini_set( 'display_errors', 0 );
#
--------------------------------------------------------------------
CHANGE FROM OFFICIAL RELEASE
$wgServer = 'https://my.host';
-------------------------------------------------------------------
#$wgUseCdn = true;
#$wgCdnServers = array();
#$wgCdnServers[] = "192.168.128.1";

Hi!

Thank you for looking into this. I do not understand why this is closed though. Basically you are saying that you provide quickstatement as part of Wikibase, but at the same time you are saying that it does not work on any deployment that is not using localhost. This is very strange to me. We are currently working with Smithsonian where this feature is a must have on the long term ....

Cordially
D063520

Hi D063520 !

In a release coming out in the next week or two there is a fix to the QuickStatements Docker image distribution, but not the QuickStatements configuration in the Docker Compose example configuration. The example configuration will receive substantial updates, including more clear documentation in a release which can be expected not long after this one.

The changes you show above from the provided example are all astute, and in fact the right way to make things work. These same changes, and more, will be reflected in the updated example configuration once it is released.

The "fix" in the release about to go out (WMDE15, 16, and 17) simply deprecates the WIKIBASE_SCHEME_AND_HOST variable, and corrects the documentation to reflect the working configuration. However, without waiting for or upgrading to these releases, QuickStatements should OAuth correctly in the current releases with the following configuration:

1. Set the WB_PUBLIC_SCHEMA_AND_HOST and WIKIBASE_SCHEME_AND_HOST both to the publicly accessible Wikibase URL. It seems from above that you have already gotten there.

2. Remove the network alias to WIKIBASE_HOST from the wikibase service, which again as you have already done.

The issue you highlight with the reverse proxy returning a 302 is from what I see, the only remaining issue keeping OAuth from working properly in your setup.

As noted, the provided nginx configuration does appear to respond with a 301 when proxying to Wikibase. That stands out to me, and I'm curious why it is setup that way. The reverse proxy should be effectively transparent, passing along the HTTP status codes and headers from the actual Wikibase server. Is there a reason you're needing this 301 response from nginx?

I'm not seeing the 302 in the proxy configuration provided, but wherever that is coming from, it will definitely cause an issue for OAuth. If the 302 or 301 in the proxy or any other layer in-front of Wikibase is necessary for some reason, then I don't think there is a workable configuration to OAuth QuickStatements to Wikibase without something along the lines of what Adam suggested with custom headers and modifications to the core Magnus Tools / QuickStatements code.

However, if the 301 or 302 responses to the Wikibase public URL can be and are eliminated, then I think OAuth is going to work.

Is there a reason that the 301 or 302 responses or needed? I apologize ahead of time if I'm missed the answer to that in the details above.

Hi @lojo_wmde,

thank you for your answer!

About the 302 code. We do not configure anything actively in nginx. In fact I think it is the wikibase itself. We set in the Localsettings.php:

$wgServer = 'https://si-wikinames.si.edu';

when we go on the container of the Wikibase and call:

curl 'http://localhost:80/w/index.php?title=Special:OAuth/token&format=js ......

we get:

HTTP/1.1 302 Found
Location: https://si-wikinames.si.edu/w/index.php?title=Special....

note, this is happening only for this particular path, for example:

curl localhost/wiki/Main_Page -v

is directly responding with the corresponding page, no redirect. That is why the wikibase is working fine in general.

So I'm pretty sure that it is the wikibase that creates the 302. The problem I guess is that with nginx proxy_pass nginx is calling de facto localhost, this is what the wikibase sees.

Any idea?

Maybe I could reformulate the problem as following. How is it possible to make the OAuth extention work behind nginx using the proxy_pass clause?

Got it. Thank you for your patience and the additional clarifications @DD063520. I think we have everything we need here to reproduce your setup and get to the bottom of this. We'll be back with you shortly!

@lojo_wmde any updates on this? I saw that in the latest wikidata release pipeline you made some changes. But I'm not sure this is addressed yet ...

with these changes, QS authentication and the search bar works fine with the new wikibase interface, but the input box to add statements and the search bar in the old interface trigger this error

jquery.js:9940  Mixed Content: The page at 'https://host/wiki/Item:Q1?wprov=acrw1_4' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://host/w/api.php?action=wbformatvalue&format=json&datavalue=%7B%22value%22%3A%221951-1964%22%2C%22type%22%3A%22string%22%7D&generate=text%2Fplain&property=P9&errorformat=plaintext&uselang=en&options=%7B%22lang%22%3A%22en%22%7D'. This request has been blocked; the content must be served over HTTPS.

Apologies for the long delay in looping back! There has been a lot of movement over here, but not a lot to report until recently.

1. We are in fact working on a significant update to our Docker images and Example Docker Compose configuration, including updating and adding some additional documentation. I'm hopeful that a few of these revisions will be helpful to resolving any remaining issue you're having. We anticipate releasing these updates within the next month.
   
   Some of the work in progress is available here: https://github.com/wmde/wikibase-release-pipeline/pull/665 (the T348742-better-localsettings-handling Git branch). The changes there would be hard to utilise as there are not yet Docker image builds for this branch on DockerHub. The changes may also be difficult to digest until we catch the documentation up to them. That all said, it may be worth taking a look at the example/docker-compose.yml and template.env to see the direction we're going. Feedback is welcome...
   
   I am currently trying to reproduce your configuration as closely as possible to see if I can answer some of your earlier questions directly. I will loop back once I have more useful.

2. @Felipemr, this is really good information! Do I understand correctly that you are using the current configuration found at https://github.com/wmde/wikibase-release-pipeline (the main branch)? Which template are you needing to use for your project?

Yes, I've been using the latest release tags/wmde.20 following these instructions https://www.mediawiki.org/wiki/Wikibase/Docker (I'm not sure about what you mean by template)
I've tried changing the values of $wgServer to a protocol-relative URL and $wgCanonicalServer to an absolute URL in LocalSettings.php but it didn't change much (Running a mixed-protocol wiki - https://www.mediawiki.org/wiki/Manual:HTTPS)

Ah sorry @Felipemr, by template I meant to say "interface", and I had thought you were speaking about the MediaWiki skin you were using. I'm not sure now if we're talking about the same thing yet. When you say the "old interface", what do you mean? Like the 2nd search box on the search page?

BTW-- In our configuration we don't currently do anything with $wgCanonicalServer, only $wgServer as it is our understanding that this is all that is needed in the majority of cases. We could be wrong. Do you need to $wgServer to be different than $wgCanonicalServer for your use case?

Also--the upcoming release I'm mentioning is here: https://github.com/wmde/wikibase-release-pipeline/pull/665, but until it's released there won't be a build published up to DockerHub so it is just a preview of what is coming-up. This fairly substantial update is expected to be released officially sometime in June.

oh, I see. By "old interface" I was referring to the Vector legacy (2010) skin where none of the search boxes work for me (the browser console shows the mixed content error). With the new Vector (2022) skin, I can use the search box at the top to look for items, but the search box or input box, to look for and add statements doesn't work.

As for the $wgServer, it's about the same issue the author mentioned. Setting it to my complete URL path allows me to use the search box, but I can't use services like QuickStatements, where I'm having trouble logging in. Using $wgServer with WebRequest::detectServer() I'm able to log in on QS, but I'm having trouble with the search box. I'm a bit confused here, maybe I need to make the request through HTTPS instead of HTTP to avoid the mixed content error, but I don't know how to make that happen.

Thanks for the info about the upcoming update btw!

@DD063520 if you're still tuned in here I wanted to let you know that our next release may solve the issues you were having. An improved Docker Compose example configuration is central to this release, and unlike before, this version of our example is designed specifically as basis for production. It adds, among other things, a reverse proxy and SSL cert generation service (Traefik).

Both QuickStatements OAuth and search are working as expected for us using this configuration, and we're hopeful you'll have the same experience. If you are up for trying this pre-release before our official release in June, then follow the instructions below and let us know your findings:

1. Clone the repository (if you don't still have you previous copy):

git clone https://github.com/wmde/wikibase-release-pipeline.git
cd wikibase-release-pipeline

2. Checkout the testing/pre-release branch for this issue:

git checkout T315916-quickstatements-behind-reverse-proxy
cd example

3. Update your example environment variables:

Copy example/template.env to example/.env, then update the values in the example/.env file to your needs.

cp template.env .env
# edit .env and update settings to your needs

Note: You will need 3 public-facing URLs corresponding to the 3 frontend services (MediaWiki / Wikibase, WDQS, and QuickStatements). Each of those addresses will need to be DNS mapped to the IP address of the server. Given the configuration you've already shared, I expect your existing DNS entries should work fine as long as you are running on the same server:

docker compose down --volumes
docker compose up --wait

4. Reset configuration, data, and run:

Reset any existing data and configuration from previous installs such that the new Docker images and settings in the .env file are used, and start the services up again to complete the installation with the new Docker images and settings:

docker compose down --volumes
docker compose up --wait

Hopefully those instructions are clear enough and everything boots-up in the expected way for you with this configuration, if not please do reach back here right away and we will do our best to offer timely support. If you do get things running on this pre-release, please let us know if the QuickStatements OAuth and search functionality issues clear-up for you. This new configuration, along with updated documentation, we expect to officially release sometime in June following the next MediaWiki update.

Good luck, and let us know how it goes.

Thank you!

@lojo_wmde thank you for the update! currently due to time constrains we are not able to test this pre-release, but we are looking forward to it!

@DD063520 thanks for the ping back! Totally understand. We will comment here once the release is out, which we expect sometime in late this month or in July. What is coming is a pretty big change, and the documentation will be there to hopefully make it more clear how to get things going on HTTPS with everything working as expected out-of-the-box.

@DD063520 finally the new release of Wikibase Suites Images and the example (now called Deploy) configuration is out. Things are quite a bit different than what was there before, and I think you'll find the Deploy configuration more useful for getting things going in production. Foremost I think the configuration is easier to understand, and better documented, but also we now include some needed pieces like a reverse proxy configuration, SSL certs generation, etc. When you get a chance please read through the deploy/README.md, and see what you find. We'd love to know how it goes for you, any thoughts you have, and if anything blocks you from moving forward with this.