"View in Browser" triggers log in popup

[jonathansnow]

Version:

• listmonk: v2.5.1

Description of the bug and steps to reproduce:
When users click "View in Browser" at the bottom of an email send, this loads a copy of the email and triggers the admin login popup. I don't recall this issue in a previous version (but I haven't tested it extensively in the past). The content loads fine, but end users should not see any option to log in.

I don't see any options in the admin settings that would be related to this.

[knadh]

Can you use the browser network inspector tab to see which particular request is triggering this on the e-mail page?

[candideu]

I had the same issue a while back and it was tied to the images: #540 (comment)

[jonathansnow]

Can you use the browser network inspector tab to see which particular request is triggering this on the e-mail page?

The issue appears to be with the tracking pixel for some reason. We had a couple of recipients mention this about our last send. No other images are in the email body. I also think we didn't notice because we tend to test in the browser where the admin user is already authenticated, so the email appears to load properly. I replicated this with a test send from the previous campaign, but historically, this will track opens properly (and seems to in this case as well).

We have a single <div>{{ TrackView }}</div> in our base template.

The request URL for the tracking pixel seems incorrect, too, but open tracking seems to be working properly.

https://{{domain}}/campaign/ce7c7863.../{{domain}}/campaign/ce7c7863.../5503a08a.../px.png

When checking the network tab when logged in, I get a 404 on the asset

[knadh]

The request URL for the tracking pixel seems incorrect, too, but open tracking seems to be working properly.

This shouldn't happen! The pixel URL is generated using the Root URL set in Settings. It should look like http://yourdomain.net/campaign/$campID/$subID/px.png

[jonathansnow]

The request URL for the tracking pixel seems incorrect, too, but open tracking seems to be working properly.

This shouldn't happen! The pixel URL is generated using the Root URL set in Settings. It should look like http://yourdomain.net/campaign/$campID/$subID/px.png

Perhaps it shouldn't, but it also seems that when you click view in browser while already in a view in browser window, you also get the same path duplication. Perhaps these are related somehow?

To confirm, I don't think we're having any open tracking issues, just some weird behaviour with View in Browser

[knadh]

Sorry, just got a chance to investigate this. Unable to reproduce either cases.

1. The domain that's configured in Settings -> General -> Root URL is correctly used in all links including the pixel link.

2. "View in browser" page has the correct links. The "View in browser" link on the same page simply points to the same link and there's no path duplication.

[jonathansnow]

Sorry, just got a chance to investigate this. Unable to reproduce either cases.

1. The domain that's configured in Settings -> General -> Root URL is correctly used in all links including the pixel link.
2. "View in browser" page has the correct links. The "View in browser" link on the same page simply points to the same link and there's no path duplication.

I'll review this again next week to see if we're still having problems!

[jonathansnow]

Sorry, just got a chance to investigate this. Unable to reproduce either cases.

1. The domain that's configured in Settings -> General -> Root URL is correctly used in all links including the pixel link.
2. "View in browser" page has the correct links. The "View in browser" link on the same page simply points to the same link and there's no path duplication.

So, I just reviewed this with a test send and both issues are still present for logged-out users.

• When clicking view in browser (or visiting the link in Incognito) the login popup shows up
• When clicking view in browser while viewing in browser, the path is duplicated.

How should I go about troubleshooting this further?

[knadh]

There's a 404 that's being triggered somewhere in your setup, which defaults to the login popup. This has been fixed here 53eb71a. Any 404s will now render an explicit 404 page instead of the auth popup. That should help debug. This will be available in the upcoming release shortly.

[jonathansnow]

Awesome, thanks!