let's get rid of {S_FORM_TOKEN}

[code reader]

as one of the security measures resulted from the security audit, a new token was added: S_FORM_TOKEN.
iiuc, in principle, this token is supposed to appear in each and every form in the template (.html) file.
this does not make sense: if this token should appear in every form, the right place to implement it is in the template engine.
just have the template engine replace the </form> tag with the content of S_FORM_TOKEN, followed by </form>.

i thought so from the first time i saw this new token, but did not say anything because the probability that the dev team would even consider such a suggestion was very remote in the hectic days after the audit, with all the pressure to get to gold and the myriad of changes the audit created.

however, now, that 3.0 was branched, it makes perfect sense to correct the situation on the main development trunk.
of course, to make it as painless as possible, the template engine should still parse the {S_FORM_TOKEN}, replacing it with nothing, so the fix won't break existing templates.

[statm1]

Well, I dont think its such a good idea to let it automatically replace </form> with the token code. The html that {S_FORM_TOKEN} produces needs to be within a block level element if the author wants to remain standards compliant and if the author chooses to use XHTML Strict as is true with proSilver. If you used a subsilver based style and the DOCTYPE wasn't changed then it doesn't really matter. Plus it would restrict how the author codes his style. Inline tags are always more flexable than being hard-coded.

[Marshalrusty]

if this token should appear in every form, the right place to implement it is in the template engine.
just have the template engine replace the </form> tag with the content of S_FORM_TOKEN, followed by </form>.

But it doesn't appear in every form, and it shouldn't appear in every form.

[Kellanved]

It only applies for forms which do not use the confirm_box. The only clean solution would be using the form action, but that would leak the token via the referrer, so it can't be done without switching to db-based single-use tokens. It's something we consider, but it would be even more restrictive for the users and forbid things like clicking "back" after running into an error.

The template engine doesn't abstract over forms, so it isn't cleanly possible to just filter out the forms that need such a token. Also, as pointed out above, it would be very hard to create valid XHTML.

We are considering a design which would add form-level abstraction to the API, which could automagically take care of things like tokens and possibly AJAX, but that's still just a very early design sketch.

A step in-between would be a standarized hidden fields/form token template variable. That's something almost certain for 3.2.

[code reader]

It only applies for forms which do not use the confirm_box. The only clean solution would be using the form action, but that would leak the token via the referrer, so it can't be done without switching to db-based single-use tokens. It's something we consider, but it would be even more restrictive for the users and forbid things like clicking "back" after running into an error.

i may be in complete misunderstanding here, but let me try anyway:
iiuc, there is absolutely no harm in including the "token" even in forms that do not need them.
the </form> tag is always "</form>". there are no attributes, or any other variation.
using the template engine to replace </form> with something else is quite "clean", and the gain of getting rid of all the {S_FORM_TOKEN} in all the template files is meaningful.

think about the whole "templating" thing: the idea is to separate presentation from application logic (often referred to as "business logic"). the "form token" has nothing to do with the presentation, and has no place in the presentation .html files.
sometimes you have to put stuff where it doesn't "really" belong because of constraints, or practicality considerations.
this is not one of those times. it is more practical, clean, and convenient to place the security-enhancement attribute outside the presentation and back in the logic piece of the puzzle. you will have this thing buried in one place, not bothering anyone, rather than what you have now, which is this {S_FORM_TOKEN} sprayed like some grafitty all over the place with no apparent function, beauty or form.

[DavidMJ]

In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...

[JRSweets]

Does this token need to appear on all forms except when using the confirm_box function, or only forms that do not modify the database? It doesn't appear on the jumpbox, forum/topic sort/filter forms or the quick search box in viewforum/viewtopic.

[Highway of Life]

In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...

Hey David and Henry, just a thought; what are the reasons for using S_FORM_TOKEN instead of putting it in the S_HIDDEN_FIELDS var?

[Acyd Burn]

In the end, functionality wins. Without an alternative implemented here and now, {S_FORM_TOKEN} is here to stay...

Hey David and Henry, just a thought; what are the reasons for using S_FORM_TOKEN instead of putting it in the S_HIDDEN_FIELDS var?

Far easier codewise with one function handling the form token instead of having to modify every instance of hidden fields (also those forms not having hidden fields).