listmonk icon indicating copy to clipboard operation
listmonk copied to clipboard

Back button doesn't navigate back to public subscription form

Open toontoet opened this issue 3 years ago • 14 comments

Version:

  • listmonk: 2.1
  • OS: Docker

Description of the bug and steps to reproduce:

  1. Add a public subscription form on your website
  2. Open the Listmonk admin or just open the main listmonk URL
  3. Fill in the form on your website & click Subscribe. The page /subscription/form will be shown
  4. Click 'Back'.

You won't be redirected to the page containing the subscription form. In my case I'm redirected to a empty browser tab (Firefox).

In my case history.length == 3, which causes the back button fire a history.go(-2). history.go(-1) does the job.

As a work around I added some custom javascript, checing the document.referrer and changing the button event handler.

toontoet avatar Mar 14 '22 09:03 toontoet

For me I remember this worked. So I guess this might be a special case, we have to investigate?

NicoHood avatar Mar 14 '22 10:03 NicoHood

Hi @toontoet. I followed the exact steps and am unable to reproduce this.

knadh avatar Mar 19 '22 05:03 knadh

I also have this problem.

Uzay-G avatar Jun 14 '22 20:06 Uzay-G

I also noticed, that the back button brought me 2 pages before, the page before the form.

Its like this:

  1. Any web page that links to the form
  2. Form, embedded on the webpage
  3. Listmonk Success message with back button
  4. Now jumps back to 1, not to 2

NicoHood avatar Jun 20 '22 10:06 NicoHood

@knadh can you reopen this?

NicoHood avatar Jun 20 '22 10:06 NicoHood

We have noticed that when the subscription is not completed (ie: the subscriber has not checked the checkbox), the back button does not return to the subscription form, but instead goes two pages back. It would be more user friendly if it went back to the form. Thanks!

buttle avatar Sep 27 '22 09:09 buttle

after subscription success the back button should kick you back to

tld.com/subscription/form ( where you can subscribe with another email for another list, whatever)

but kicks you back to

tld.com/ (the combined login & subscription page)

listmonk 2.4 (today)

les-les avatar Apr 14 '23 15:04 les-les

I have the same problem on macOS 16.5, Safari and Firefox.

apfatzgo avatar Jun 17 '23 09:06 apfatzgo

I'm having the same issue. Listmonk v2.5.1 Firefox on macOS or Windows, Safari on iOS, etc.

msklywenn avatar Oct 17 '23 10:10 msklywenn

I guess a nicer solution would be to be able to pass a redirect url to /subscription/form where it should lead after successful form submission and that should be used on the "Back" button. This way, developers could decide where they'd want to go when POST'ing from their websites.

If you want that (like me), this is the custom js to add:

const backBtn = document.querySelector("#btn-back");
if (backBtn) {
  backBtn.href = new URLSearchParams(window.location.search).get('redirect')
  backBtn.onclick = null
}

Afterwards you can post to .../subscription/form?redirect=[TARGET_URL]

boredland avatar Mar 30 '24 20:03 boredland

Without the URL being added to a safe list in the backend, this would lead to an open-direction vulnerability though.

knadh avatar Apr 01 '24 07:04 knadh

Without the URL being added to a safe list in the backend, this would lead to an open-direction vulnerability though.

While I agree that a configuration option in the backend would be preferable, I don't think this opens a new attack vector. If an attacker already manipulates the target of a form, he could easily replace that target with an address of his liking (with a redirect, data collection etc.). What am I missing?

boredland avatar Apr 01 '24 07:04 boredland

/subscription/form?redirect=[TARGET_URL]

An attacker doesn't have to compromise the form. They can send unsuspecting users to https://listmonk.legitsite.com/subscription/form?redirect=$malicious_url. Legit domain, legit form, legit signup, but malicious redirect after.

knadh avatar Apr 01 '24 07:04 knadh

/subscription/form?redirect=[TARGET_URL]

An attacker doesn't have to compromise the form. They can send unsuspecting users to https://listmonk.legitsite.com/subscription/form?redirect=$malicious_url. Legit domain, legit form, legit signup, but malicious redirect after.

Well, sure, no form needed for that. But also: I'd need to first have a user-trusted website to have this link on. In both cases, I don't see why I'd need listmonk at that point.

While still no server-validation, one could easily extend the js to have a little check:

const backBtn = document.querySelector("#btn-back");
const redirect = new URLSearchParams(window.location.search).get('redirect')

if (backBtn && redirect && /^(test.com|localhost)$/.test(new URL(redirect).hostname)) {
  backBtn.style.display = "inherit"
  backBtn.href = redirect;
  backBtn.onclick = null
}

boredland avatar Apr 01 '24 08:04 boredland