You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We burned a good deal of time on this issue, so I thought I'd post it here for folks who are trying to troubleshoot.
if your MEDIA_URL is set to something that starts with / - like /media/ , Wagtail transfer will try to make this a fully-qualified URL when serializing images, since it is setting things up to be pulled from another server and thus relative paths won't work.
To do this, it uses - very oddly - the WAGTAILADMIN_BASE_URL. And if that is not defined, a setting called BASE_URL, which is undocumented as far as I can tell.
For example if your MEDIA_URL is /media/, it will serialize the image path as http://source-server:source-port/wagtail/media/xxx.
I can't think of a typical set up where you would want to have your public media served under /wagtail, but that is how the code works:
# Prepend the BASE_URL to turn this into an absolute URL
ifADMIN_BASE_URLisNone:
raiseImproperlyConfigured(
"A WAGTAILADMIN_BASE_URL or BASE_URL setting must be provided when importing files"
)
url=ADMIN_BASE_URL.rstrip('/') +url
For most production set-ups, you'd want your media url to be fully-qualified anyway, but in our local and test environments, we were using MEDIA_URL of /media/ to keep things isolated to the test environment.
That causes the production server to try and pull images from a path that includes /wagtail, which results in an auth redirect, and the image is returned as the HTML of the auth redirect page and saved on the production server as the image file.
This causes every UI in wagtail that references that image to 500 error, since the image is corrupted and can't be loaded.
There are very likely security implications of this, since Wagtail transfer is saving the image without validating that it is a valid image, and not some malicious code that could be executed every time the corrupt image is loaded, both on the front-end and in Wagtail.
The simplest fix is to always use a FQDN for your MEDIA_URL when using Wagtail transfer.
I would recommend that this project at least remove the use of WAGTAIL_ADMIN_BASE_URL as a substitute for a FQDN, and perhaps create a new WAGTAIL_TRANSFER_BASE_URL setting instead.
Hope this helps folks!
The text was updated successfully, but these errors were encountered:
Hello -
We burned a good deal of time on this issue, so I thought I'd post it here for folks who are trying to troubleshoot.
if your MEDIA_URL is set to something that starts with / - like
/media/
, Wagtail transfer will try to make this a fully-qualified URL when serializing images, since it is setting things up to be pulled from another server and thus relative paths won't work.To do this, it uses - very oddly - the
WAGTAILADMIN_BASE_URL
. And if that is not defined, a setting calledBASE_URL
, which is undocumented as far as I can tell.For example if your MEDIA_URL is /media/, it will serialize the image path as
http://source-server:source-port/wagtail/media/xxx
.I can't think of a typical set up where you would want to have your public media served under /wagtail, but that is how the code works:
wagtail-transfer/wagtail_transfer/field_adapters.py
Lines 37 to 40 in fded12d
wagtail-transfer/wagtail_transfer/field_adapters.py
Lines 303 to 310 in fded12d
For most production set-ups, you'd want your media url to be fully-qualified anyway, but in our local and test environments, we were using MEDIA_URL of
/media/
to keep things isolated to the test environment.That causes the production server to try and pull images from a path that includes /wagtail, which results in an auth redirect, and the image is returned as the HTML of the auth redirect page and saved on the production server as the image file.
This causes every UI in wagtail that references that image to 500 error, since the image is corrupted and can't be loaded.
There are very likely security implications of this, since Wagtail transfer is saving the image without validating that it is a valid image, and not some malicious code that could be executed every time the corrupt image is loaded, both on the front-end and in Wagtail.
The simplest fix is to always use a FQDN for your MEDIA_URL when using Wagtail transfer.
I would recommend that this project at least remove the use of WAGTAIL_ADMIN_BASE_URL as a substitute for a FQDN, and perhaps create a new WAGTAIL_TRANSFER_BASE_URL setting instead.
Hope this helps folks!
The text was updated successfully, but these errors were encountered: