Was Creating a page using XXXXXXXXXX numbering fails when not logged in

When a new page is created using a HTML form that calls

<form name="newnews" action="%SCRIPTURLPATH%/save/%WEB%/" method="post">

using

<input type="hidden" name="topic" value="NieuwsBerichtXXXXXXXXXX" /> 

Works perfectly unless the user is not logged in on submission. In that case:

• the user is presented with a login screen (in my case Template)
• after succesful login, a "page not found" error is being reported
• going back in the browser, the user input is gone, but the login was succesful

---

Since my users are losing their input, I upped the priority to 'urgent'. I hope that's OK. -- JM

Possibly duplicated in Item2316 --JM

Hmmm, the application in the shipped Sandbox,

<form action='%SCRIPTURLPATH{"edit"}%/%BASEWEB%/TestTopicXXXXXXXXXX' name="createNewTestTopic">
%ICON{"newtopic"}% %MAKETEXT{"Create a new auto-numbered test topic:"}%
<input type="submit" class="twikiSubmit" value='%MAKETEXT{"Create <nop>TestTopic###"}%' />
</form>

Works fine, the problem occurs in my self-made example:

<form name="newnews" action="%SCRIPTURLPATH%/save/%WEB%/" method="post">
---+++ Titel nieuwsbericht:
<input type="text" name="titel" size="60" value="" />
---+++ Inhoud nieuwsbericht
<textarea name="inhoud" wrap="virtual" rows="15" cols="60" style="width: 99%"></textarea>
---+++ Bron (krant, website, wandelgang, ...):
<input type="text" size="60" name="bron" value="" />
---+++ Type Nieuws:
<select name="SoortNieuws"> %SEARCH{ "^\|[^\|]*\| *option *\|" topic="SoortNieuws" web="MTWat" regex="on" multiple="on" nosearch="on" nototal="on" format="<option>$pattern(^\| *(.*?) *\|.*)</option>" }% </select>
---+++ Vervaldatum nieuwsbericht:
<select name="Vervaldatum">
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),1,week),$year-$month-$day)}%"> 1 week (%CALC{$FORMATTIME($TIMEADD($TIME(),1,week),$day $mon $year)}% )</option>
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),2,week),$year-$month-$day)}%"> 2 weken (%CALC{$FORMATTIME($TIMEADD($TIME(),2,week),$day $mon $year)}%)</option>
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),1,month),$year-$month-$day)}%"> 1 maand (%CALC{$FORMATTIME($TIMEADD($TIME(),1,month),$day $mon $year)}%)</option>
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),3,month),$year-$month-$day)}%"> 3 maanden (%CALC{$FORMATTIME($TIMEADD($TIME(),3,month),$day $mon $year)}%)</option>
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),6,month),$year-$month-$day)}%"> 6 maanden(%CALC{$FORMATTIME($TIMEADD($TIME(),6,month),$day $mon $year)}% )</option>
<option value="%CALC{$FORMATTIME($TIMEADD($TIME(),1,year),$year-$month-$day)}%"> 1 jaar (%CALC{$FORMATTIME($TIMEADD($TIME(),1,year),$day $mon $year)}%)</option>
</select>

<input type="submit" value="Maak nieuw nieuwsbericht" /> 
<input type="hidden" name="topic" value="NieuwsBerichtXXXXXXXXXX" /> 
<input type="hidden" name="templatetopic" value="MTWat.NewNewsTemplate" /> 
<input type="hidden" name="topicparent" value="NieuwsCentrum" />
<input type="hidden" name="onlywikiname" value="on" />
<input type="hidden" name="onlynewtopic" value="on" />
</form>

I've tested some more, and the above form works fine with small messages, but as soon as the message is too big for method="get", the error message appears after logging in.

For my form, this can be easily circumvented by denying topicview to TWikiGuest, but unfortunately this same problem also applies to TWiki:Plugins/CommentPlugin

HTH

-- JM

---

The login screen isn't very good about keeping POST parameters. It could be a lot smarter.

CC

See TWiki:Codev.DeathByRedirect.

CC

I'm curious to how much time need to go into this to have it resolved - is it indeed a release blocker?

If a form is lengthy (and therefore must be posted) a workaround is to simply * Set DENYTOPICVIEW = TWikiGuest for the topic, thereby forcing people to be logged in up front to fill the form.

-- SP

No, it's not a release blocker. but it's also not that much effort to resolve; it's just a case of finding time. Item2314 is much more urgent, for example.

Dropped to Normal, though this really is a requirement and should be boosted again later.

CC

"Add Web" breaks if not logged in. (i.e. if it has to ask you to login during the creation process).

Instead of the web being created, you get: "Missing action command Please go back in your browser and try again." http://wiki.everythingsysadmin.com/twiki/bin/oops/ TWiki/ManagingWebs?template=oopsattention;def=missing_action

Test case:

To show the failure:

• Log out.
• Go to ManagingWebs page.
• Create a web.
• You will be asked to log in.
• Enter name and passowrd, click Submit.
• You will be given an error.

Compare to:

• Log in.
• Go to ManagingWebs page.
• Create a web.
• You will NOT be asked to log in.
• The web will be created.

-- TWiki:Main.TomLimoncelli - 10 Sep 2006

Recoded to cache the parameters to a POST when a redirect happens. There is still a "suboptimal behaviour" in that the target finally arrived at has the cache in the parameters, but refreshing the page will not give you what you expect because the cache has since been deleted. The alternative is to leave the caches lying around for a time; on balance, I thought it was better just to delete them.

I'd be grateful if reporters could test their various use cases to make sure that was really the problem.

CC

To avoid having usernames and passwords listed in the apache log files, it would probably be best to skip saving the "username" and "password" variables sent by the TemplateLogin form itself?

Testcase: If logging in with TemplateLogin on a page that has a table with sortable headers, these variables will be listed when sorting the table. (Actually, a lot of &amp's is also added for each sort click currently, but I don't suspect this feature to be the reason for that).

-- SP

I wish you'd added that as a new report. I missed it for ages, cos I thought this was done.

Filtered out those params so they don't get passed through. Please check your testcase. Thanks.

CC

---

This is not yet right. When doing a redirect invoked from the TWiki::Func::redirectCgiQuery all passed parameters are lost. This makes it impossible to leverage the new way of doing oops (such as on lease conflict) in a redirect. This is urgent to fix the problem in Bugs:Item2614.

We need to make sure that redirect, when the $passthrough parameter is set, really passes the parameters (maybe excluding some, as discussed above). -- TW

---

The redirect code is working correctly, though there may be issues remaining due to the legacy hacks used to try any achieve the same goals. In this case you are re-reporting the same issue as you reported in Item3066 (which is the right place to track), so I'm resetting status to Waiting for Release. Please raise new items for any problems you find. Thanks.

CC

---

On my installation, TWiki::redirect drops all parameters and therefore the oops dialog fails. Does the oops dialog work for you on lease conflict when you click the "Try again" button?

Setting to "wait for feedback" until I am able to check out your other suggestion about the "keep" parameters. -- TW

---

Is there a test case (ideally without the login screen, as this creates its one mess) for what this Item was originally trying to fix. I still believe that the way the cache handling is done is broken and causes the redirect with leases to fail. -- TW

I tried to replace the redirect on lease violation by a throw, but am running into the identical problem. -- TW

The cache mechanism is fine, but there are problems with oops redirects Item2614. Resetting this report to Waiting for Release.

CC

4.1.0 released

KJL