Mailman module, Error: The form lifetime has expired. (request forgery check)

i have reported the same for centos 7. in centos 6, trying to make changes via the virtualmin mailman interface results in them being silently ignored.

this is a real problem for configs where there is no local website, so virtualmin is the only way to manage the mailman configs.

Just tested on a fully updated CentOS 7 system - I wasn't able to re-produce this problem at all, sorry.

i can easily reproduce it. what some screen shots?

Yes, screenshots would be very useful.

ok, here is what i see after trying to change the moderation bit for a user.

I'm getting this too, ubuntu 14.04 VM Pro version 6.02-2 driving me nuts

From: Mark Sapiro mark@msapiro.net To: mailman-users@python.org Subject: Re: [Mailman-Users] two problems with Mailman 2.1 Date: Thu, 1 Feb 2018 15:12:44 -0800 Sender: "Mailman-Users" mailman-users-bounces+geek=uniserve.com@python.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 02/01/2018 12:41 PM, Dave Stevens wrote:

I?m having a couple of problems with a Mailman 2.1 list.

I want to add several addresses as new subscribers so as a first step I added one of them using the mass subscription facility in membership management. Mailman accepted the data but when I subsequently checked the subscriber list it wasn?t there. This has been the case for two days now.

When you submitted the mass subscribe form the first time, did you get a response with a message at the top saying "successfully subscribed" or did it say something else.

Today I checked manually that the recipient address was in fact working and decided to resubscribe using the same method. I enter the data in the text box (I?ve done this several times) then click on the "submit your changes" button below and get this message, ?Error: The form lifetime has expired. (request forgery check)?

This happens without any special delay on my part, not more than a few minutes. Please advise.

You need to first get the form and then submit it within whatever the FORM_LIFETIME setting is in your installation. The default is one hour but could be different in your installation.

I suspect the issue is something else. I don't know what the issue might be, but one thing to check is to look at the HTML source of the admin/LIST_NAME/members/add page in your browser. The FORM tag in that source should be

If instead it is something like

And the URL in the address bar is different, i.e. a different domain or a different scheme (like https vs http) that might be an issue.

Is this your Mailman installation or a hosted installation?

Do other 'admin' and 'admindb' pages work? I.e. if you change something on the admin General Options page and submit, does it work or produce the same form lifetime error?

-- Mark Sapiro mark@msapiro.net The highway is for gamblers,

San Francisco Bay Area, California better use your sense - B. Dylan

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/geek%40uniserve.com

Jamie,

will this get addressed faster if I open a trouble ticket? My VMPro maoilman is suffering from this and client work can't go forward until it's corrected.

Dave

W

i just did some quick debugging and i can see that the csrf token is not getting passed into mailman, thus it is failing the test. i do see it being sent from the browser so it would appear to be getting eaten somewhere inside of the virtualmin mailman module. i'll go look there now.

hmm, one difference i see is that the membership page is using multipart/form-data and the other pages use the normal url-encoded format. i don't see logic in the virtualmin mailman module to cope with that. in fact it appears to be forcing the CONTENT_TYPE to be application/x-www-form-urlencoded so that would seem to be the source of the problem.

Hi Jamie, any progress on this??????????

does anyone know how I can get in touch with either Jamie Cameron or Joe Cooper? an email address would be great! TIA

Dave geek at uniserve dot com

This is the best place to get in touch with anyone on the Virtualmin team. Sorry for the delay!

We haven't made much progress on this issue yet, but will post any progress updates here as they happen.

thanks andreychek. I've been confused by the ui to open a trouble ticket, can you confirm if there's one open? or the correct url?

dave

This here is a trouble ticket :-)

So you're good, Jamie just hasn't had a chance to sort out what's going on yet.

I've been looking into this, but have been unable to re-produce the problem!

Which theme version are you running there? Also, which browser?

virtualmin framed theme, don't know what version or where to find out. Firefox 58.0.2 on Linux Mint, checked with xombrero same problem.

jamie can I send you login creds so you can see at first hand??

please look at my comment about the type of post data. admin.cgi doesn't appear to cope with multipart input and just assumes urlencoded. i haven't dug further, but that would certainly seem to be an issue.

update? progress? any news? what am I gonna tell my customers who need this functionality you broke?

Ok, I found the cause of this eventually - it will be fixed in the next release of the Mailman plugin.

The patch can be seen here : https://github.com/virtualmin/virtualmin-mailman/commit/3c7c71e10c31ea61...

i don't think this fixes the issue. the error doesn't display, but changes don't actually take effect. i just applied this patch and tried to moderate a user and the setting didn't stick.

-

not sure how this got closed...

yes, good point, how can it be closed if it's still not working?

@q7joey (or anyone else who's seeing this) - on what Mailman admin page are setting not being saved?

This is on the Member Subscription Pages, where you can set moderation, digest, Etc Flags.

I did some more testing, and with the latest patch I run into the same issue ... but only when using the Authentic theme. Ilia, can you take a look at this?

Jamie, I have tried to make Mailman work but it failed to work out of the box on both Ubuntu and CentOS.

It would take more time to do it.

The only reason why it wouldn't work is, either broken HTML or, possibly checkboxes/radios ids that are hardcoded and expected to be the same.

I had to make the patch after 19.09 release, to fix having elements with the same id on the page.

Could anyone please to check if the latest Jamies patches above would work with Authentic Theme 19.09 by installing it simply running ./theme-update.sh -release:19.09 from theme directory?

Clear browser's cache before trying please.

Afterwards you could run ./theme-update.sh to get the latest version.

Yeah, most of the HTML in the Mailman module actually comes from the Mailman CGI scripts - it isn't generated by Virtualmin code.

Do you think I should provide the fix around this problem?

yes certainly if you are able

I'm able to for sure, but it I need to make it run first.

Let me know when a new theme version is out that contains a fix for this..

I have managed to make Mailman work. I gotten to test it and it seems that the issue is not in the themes, as Virtualmin Framed Theme and other old themes also don't work.

To be more explicit, you can take a look at the video screen cast. Is that what others are getting? Videoscreencast.

It looks more like the bug in the Mailman itself.

I have applied the patch, by the way.

still having customers complain about this. also affect mass subscription.

i have done more digging and i think i have found another piece of the puzzle. it looks like the submit button value is not getting sent by the browser when wrapped by virtualmin. i see there is a submit event on the form and i'm guessing that is somehow stripping that value before it gets sent to the server. the mailman code is looking for the button value to determine what function to perform.

the previous fix of not stomping on the content-type header is also needed.

i'll continue digging, but maybe someone at virtualmin will be more familiar with that code and can quickly find the issue.

I'm familiar with this behavior - it's insane, in my humble opinion.

In case it's that, I will be able to fix it.

Okay, here is the thing. I ran Mailman UI from cPanel and it still doesn't work.

Example:

Going to Manage->Membership Management...->Mass Removals->Submit Your Changes - doesn't save the states of the radios (Send unsubscription acknowledgement to the user? and Send notifications to the list owner?).

It's not saved neither at Gray Theme nor at Authentic Theme, just as not in cPanel.

I also tried to send button text as value with the correspondent name - it doesn't work.

Is this Mailman bug?

Which part of the interface saves data at old themes that doesn't work under Authentic Theme? If there is such part of the UI, I will be able to fix it. Otherwise, I don't know what to fix. I'm not even sure that it's our bug.

mailman works fine in standalone mode. the example you use of mass removal isn't a place where state is stored. those radios only affect that submission. the places where things aren't working is on the membership management->membership list page when you try to change settings for an existing member. that is the page that is looking for the submit button value to be in the post data. there could be other pages with similar requirements. seems like the submit button should not be getting pruned in any case.

Oh, really. I see now.

It's easily doable, if so. When creating 19.00 I have created special work-arounds to deal with such odd cases, as they appear time after time in Webmin modules as well.

I will release 19.12 filixing it in few other very small things, in couple of days.

I'm not clear on this, version 19.12 of what?

Of the theme. I didn't test that part of the UI that Jamie stated that it worked.

Okay, first of all, I'm sorry that I didn't notice at once that you meant Management->Membership List section. I finally could reproduce an issue easily and fix that.

The issue wouldn't have happened at all, if Maillist developers didn't use non-standard uppercase value for type attribute, e.g. type="SUBMIT". Now, the check that I made long time ago to add submit button's text as a value is case insensitive, and will work just fine.

All that you need is to update the theme to the latest development version using theme's configuration. You will also need the latest version of Virtualmin Mailman module, that you can fetch by running git clone https://github.com/virtualmin/virtualmin-mailman.git. After cloning, you will have to find and replace #!/usr/local/bin/perl to #!/usr/bin/perl. You can do it by using File Manager replace feature. When done, replace it with your existing version of the module in Webmin dir (/usr/share/webmin).

Good luck.

how soon should we expect all these changes to show up as normal updates? a quick attempt to update the theme says it wants usermin 1.740, so there seems to be some dependency bits and i'd rather wait until everything has been tested together.

Ilia,

when you refer to "the theme" is that Authentic? and what about other themes? I'm using Virtualmin Framed

I referred to Authentic Theme. Jamie stated that it worked on his side, so that's the way it is, I bet.

We'll do our best to make new releases as soon as possible.

Please tell me what I could improve, from your point of view, on Authentic Theme to make it suitable for you?

it's not that it's unsatisfactory but it's different and by not changing I don't need to learn about it. I've got lots else to do that's all.

i tried the fixed version of bundle.min.js and it breaks the ui on my install. so i think there are some dependencies that we'll have to wait for.

the error is get_server_data() is undefined.

Go to Theme's Configuration, and disable the option to also update Usermin, when running theme updates. Then you will have no warning, when force updating.

i just updated to usermin 1.741, updated authentic theme, and manually patched the mailman module and things are looking pretty good so far.

hopefully the mailman module update can be pushed asap so everyone can easily fix this issue.

still waiting for the mailman module update to be officially released.

I've rolled the new Mailman module. Let us know if the problem persists or anything else is amiss.

But using Firefox 59.0.2 on Mac Os 10.13.4 and Firefox ESR 52.7.3 on Debian 9.4 the error message doesn't appear, but the changes are not saved. I tested it checking and uncheking subscriptor properties on the Mailman list members, like "mod" checkbox.

The only reason why this would happen is stuck cache. Make sure that you have latest Authentic Theme 19.12+ version installed as well.

Odd. I checked it in my Firefox stable it it saved the state same way it does in Chrome.

Okay, be kind adding the screenshot of the page that doesn't save?

I have tested Mailman Administration/Membership Management.../Membership List -- changed checkboxes, clicked Submit Your Changes - result was saved.

Are you sure that you have updated everything?

as of the most recent update to webmin virtuallmin mailman module my firefox changes take effect and save properly and persist and no errors. Thanks Jamie!

it looks like authentic theme has been rolled into the webmin package, so when can we expect that to be updated and pushed?

needing to go update systems manually is a pain, especially since git has to be installed. further, one system i tested on decided to update to a beta version even though i said release version.

I'll roll out 19.13 in a bit and ask Jamie, if he could build new Webmin/Usermin package.

Sorry for inconvenience.

saw a new virtualmin rpm roll out, but it doesn't include the new authentic theme...

Authentic Theme is part of Webmin package. Authentic Theme 19.14 will be shipped with Webmin 1.850 release.

I meant to say with Webmin 1.890. :)

I'll release a 1.882 devel version that also includes this theme fix.

Nothing significant has changed in version 6.9 of the plugin that could trigger this..