View Issue Details

IDProjectCategoryView StatusLast Update
0012169mantisbtscriptingpublic2011-08-05 02:12
ReporterlImbus Assigned Todhx  
PrioritynormalSeveritymajorReproducibilityrandom
Status closedResolutionduplicate 
Product Version1.2.1 
Summary0012169: "Add Note" issues ERROR_FORM_TOKEN_INVALID
Description

I (and my coworkers) have seen it several times now that submitting a new note to an issue raises the errormessage "Invalid form security token. Did you submit the form twice by accident?" when in fact I can be pretty sure now that I did not double-click or something else by each time.
Last time - I am pretty sure - I tabbed to the submit-button and hit "space", even less probable that it did hit twice.

What aggravates the problem is that each time then, the back button did brought me (and my coworkers) back to the unmodified issue view instead of prefilling the textarea with the message I was about to submit. This happened on Firefox 3.5.10 and others.

Additional Information

(excuse me if this is already recorded somewhere in the meta-mantis, but I could not find it.)

Why is my browser not saving what I was about to write ? As far as I know, they usually do so now, unless - of course - the page I am going back to was a response from a HTTP-POST command, in which case the browser is about to ask "the page you were coming from was an answer to a send form, do you want me to resend that information?". This is certainly not a problem by mantis in itself, but I'd be highly intrested in finding this out.

As for the actual problem, I had a look into the source of that page, as to find a reason why firefox might treat this differently. There I saw that the form element is a submit-button AND has the submit-method of the form called in the elements onclick-attribute. By this, depending on the browser, the form might very well be submitted twice by the browser. I've had this very problem a few months ago when I was developing a web application.

The "this.disabled=1" looks like somebody tried to disable the button to solve the problem of double-sending.

I am using mantis in different browsers, one of which is a Firefox with the popular extension "NoScript" which disables Javascript per default. Since the mantisbt works well without JavaScript, this is usually not of a problem, but could be the reason why this problem appears sometimes, and sometimes not.

TagsNo tags attached.

Relationships

duplicate of 0011680 closeddhx Mantis APPLICATION ERROR #2800 for Mantis 1.2.0 

Activities

dhx

dhx

2010-07-13 17:39

reporter   ~0026071

This is a CSRF protection feature. Please see 0011680 (and related duplicates) for more information on how to resolve your problem.

lImbus

lImbus

2010-07-14 08:51

reporter   ~0026076

I am responding here on one of the less "on-topic" aspects of this issue that are not discussed in any of the linked duplicates:

Does the CSRF protection consist of having the input-element of type submit beeing resubmitted by javascript, or is this still a possible issue? "bugnoteadd" is the only form with this behaviour.

Also, do you have any information on why browsers sometimes "forget" what the user had been entering in the form elements, whereas it seems to remember most of the time ? Or is it that I am wrong, and the usual behaviour of browsers is not not do so, cases where I see this happening is a common gesture of utilized javascript-frameworks ?

lImbus

lImbus

2010-07-14 09:36

reporter   ~0026077

I wanted to respond in 0011680, but I am not allowed to add a note there.

What about making mantis check (or even set (ini_set() ?)) the value of session.gc_maxlifetime and warn if that's too low (default in debian seems to be 24 minutes, which is obviously too short to write a proper issue/note)

Another idea is to reflect any text the user has written in the error-screen so that he can copy and paste the text to a safe place (or a second opened tab).

(oh, btw, while writing this note, took only a few minutes, I had this very problem, fortunately, chrome did save the contents and reoffered those after hitting "back")