Export button doesn't work on custom URL

[martinhellwagner]

Description

Similar to #4737, the export of entries is not working when using Craft CMS with a custom URL (e.g. https://cms.customurl.com/admin). When trying to export directly from the server URL (e.g. http://serverurl.com/admin), everything works as expected. I might be good to note that the custom URL has an SSL certificate, while the server URL does not.

Steps to reproduce

1. Export arbitrary entries by using the "Export" button.
2. After clicking the export button, the user is redirected either to the dashboard or to a random Channel / Structure etc.

Additional info

• Craft version: 3.3.20.1
• PHP version: 7.1.5
• Database driver & version: MySQL 5.7.25

[brandonkelly]

Hm, in this case it should definitely work correctly, since element exporting happens via control panel URLs (whereas in #4737, the real issue there is that GraphQL API requests are technically considered “site” requests – so site URLs are used for action URLs).

Try opening up your browser console and outputting the following things: Craft.baseCpUrl and Craft.actionUrl. What do they output?

[martinhellwagner]

@brandonkelly

The URLs seem to correspond to the custom URL of the dashboard:

[brandonkelly]

Yeah that looks right. Keep an eye on your Network tab when you click the Export button inside the export modal. Can you tell me which request is going to the wrong domain?

[martinhellwagner]

Seems like none of the request go to the wrong domain. However, the reload (without the export) seems to be happening after the entries request – and two requests don't come back with a 200 status code.

[martinhellwagner]

For what it's worth, the "reset password URL" button shows a wrong URL on our production environment. This doesn't happen on our staging environment (where exporting fails too) – but it is possible that some root URL / asset URL etc. is set incorrectly which causes both problems?

[brandonkelly]

In your console, what does this output?

Craft.getCpUrl('', {token: 'test'});

[martinhellwagner]

Also outputs the correct URL:

[brandonkelly]

Huh, I wonder why that is 301’ing then. Try running this from your terminal – what is returned?

curl -I https://kebap-1068.cms.staging.karriere.at/admin?token=test

[martinhellwagner]

Correct URL, but also 301 apparently. 🤔

[brandonkelly]

Very weird. That seems to be the root of your issue though.

Here’s how it’s supposed to work:

1. The JS receives the token to download the export CSV, and sets the window location to that:

cms/src/web/assets/cp/src/js/BaseElementIndex.js

Lines 1806 to 1809 in 4d11acc

	var params = {};
	params[Craft.tokenParam] = response.token;
	var url = Craft.getCpUrl('', params);
	document.location.href = url;

2. That causes the browser to send a request to https://kebap-1068.cms.staging.karriere.at/admin?token={token}, which should route to the ExportController, which will generate the CSV, and return it as the response body, along with a Content-Disposition: attachment header which instructs your browser to download the response body as a file, rather than open it in the main browser window, thus having no impact on the current request.

In your case though, instead of getting routed to the ExportController, something is causing that 301 response to come back instead, which is causing the browser to actually redirect itself, rather than downloading a file.

Is there anything in your web server config that could be causing that 301 to be returned, that you can think of?

[martinhellwagner]

Seems like the request fails in the first "step" of the cURL request – it's actually okay in the other "steps":

I've forwarded this issue to our DevOps.

[martinhellwagner]

Turns out the first "step" returns a 301 error because /admin is forwarded to /admin/ in the NGINX configuration:

location = /admin {
    return 301  /admin/;
}

DevOps changed that, and now the first "step" returns a 302 already:

Might be interesting to include the number of "steps" that Craft should try for a request before "giving up" as a config parameter? We're probably not the only ones running Craft with a custom URL and a specific NGINX configuration.

Anyways, thanks for much for the help @brandonkelly! Much appreciated.

[brandonkelly]

Turns out the first "step" returns a 301 error because /admin is forwarded to /admin/ in the NGINX configuration:

location = /admin {
    return 301  /admin/;
}

Ah, that makes sense. You might have better luck if you enable the addTrailingSlashesToUrls config setting, so Craft-generated URLs have trailing slashes to begin with.

Might be interesting to include the number of "steps" that Craft should try for a request before "giving up" as a config parameter? We're probably not the only ones running Craft with a custom URL and a specific NGINX configuration.

Yeah… currently it’s just relying on typical browser behavior of not redirecting the request if the link is for a file download. But there’s probably a better way.

[brandonkelly]

(Leaving this open as I do think we can improve it.)

[martinhellwagner]

Sorry! 🙈

[narration-sd]

n.b. am sure it's obvious, but curl's -L could be a good model - it's very useful in cases like this, for example when there's an http->https bump in the road...

[brandonkelly]

@martinhellwagner I believe I’ve just fixed this for the next release. Would you mind testing on your end?

To get the fix early, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "dev-develop#b6bd1c4148ea402059d5c0fe168382863cf7c30f as 3.4.3",
  "...": "..."
}

Then run composer update.

[brandonkelly]

Craft 3.4.4 is out now with that fix. Let me know if it works for you.

[martinhellwagner]

@brandonkelly Looks good! Thank you! 👍

[brandonkelly]

Sweet!