[Mailman-Users] Somebody could not subscribe to pypy-dev at python.org
lac at openend.se
Thu Apr 23 00:11:15 CEST 2015
In a message of Wed, 22 Apr 2015 14:34:00 -0700, Mark Sapiro writes:
>It is a stretch, but the HTML for the form tag and it's input tags look
> <FORM Method=POST ACTION="../subscribe/pypy-dev"><input type="hidden"
><INPUT type="Text" name="email" size="30" value="">
><INPUT type="Text" name="fullname" size="30" value="">
><INPUT type="Password" name="pw" size="15">
><INPUT type="Password" name="pw-conf" size="15">
><input type=radio name="digest" value="0" CHECKED> No
> <input type=radio name="digest" value="1"> Yes
><INPUT type="Submit" name="email-button" value="Subscribe">
>It is conceivable that some browser could corrupt the sub_form_token
>value upon submission if and only if the password fields are empty, but
>as I say, it's a stretch.
And this is upside-down from his experience. Things go _fine_ when
the password fields are empty, it is just when he fills them out
that things did not work.
>When did this issue occur? I have looked at the web server logs back to
>March 30, and every POST to mailman/subscribe/pypy-dev in those logs is
>from a bot attempting to subscribe to many lists.
At Tue, 21 Apr 2015 18:05:56 -0000
he sent a mail to pypy-dev-owner (me) complaining about his problem
and asking if we could fix it, so sometime before but close to then
I would guess.
>There is another possibility. The digits left of the colon in the token
>are the Unix time of when the token was generated and the stuff to the
>right is a hex digest of a sha-1 hash of the time, listname, remote IP,
>and a 'secret'.
>There's probably a bug here, but if the token is missing, the user gets
>the 'Please take a few seconds to fill out the form before submitting
>it.' message. (It would be better I think to issue the 'The form is too
>old. Please GET it again.' message in this case)
>The only way the 'You must GET the form before submitting it.' message
>is issued is if the time is within the 1 hour >= time >= 5 seconds
>window and the hash doesn't match. This could occur if the user is
>accessing the site through some kind of proxy or other device which
>submits the form from a different IP than the one that got it.
I will ask about this. He is using stock chrome with no adblocking
plugins -- no plugins at all, as this is a new machine and he hasn't
got around to installing anything yet.
More information about the Mailman-Users