Item1507: PersonalInfoAddOn GET problem

PersonalInfoAddOn no longer works

after editting the data and pressing the "Save" button, i received the following error message:

Bad Request: GET denied for save

though it does seem to have updated my topic anyway!

-%META:FIELD{name="HomePage" attributes="" title="<nop>HomePage" value=""}%
+%META:FIELD{name="HomePage" attributes="" title="<nop>HomePage" value="http://biohack.net/"}%

which seems to point to a core issue, in addition to the update(s) required for PersonalInfoAddOn

-- WillNorris - 24 Apr 2009

I see something even worse... When trying to edit my personnal data on 1.0.5 using; http://test.foswiki.org/Main/OlivierRaginel?editUserData=on the email text is "cut":

<th> Email </th><td> <input type='text' name='Email' id='Email'  class='foswikiInputField' size='40' <a href="mailto&#58;value&#61;&#39;wiki&#64;babar">value='wiki&#64;babar</a>.us' /> </td>

This works just fine on 1.0.0 using: http://foswiki.org/Main/OlivierRaginel?editUserData=on

But I can't seem to reproduce the core issue reported by WillNorris here.

-- OlivierRaginel - 30 Apr 2009

I cannot find any forms with GET in PersonalInfoAddOn

Are you sure the issue is from PersonalInfoAddOn and not from some self made extra stuff in a topic or in a skin?

-- KennethLavrsen - 26 May 2009

i'm pretty sure i did this with a virgin ("beta") release with PersonalInfoAddOn. i almost certainly also had AttachContentPlugin and ImagePlugin installed as well. i will try and retest tonight.

-- WillNorris - 26 May 2009

Because this bug makes my new installation impossible, I investigated this a little and found:

• Edit data: the error message is appearing at save of the topic PersonalInfo cause of update of XML data (createPhoneListXMLAttachment) and directsearch (createDirectSearchAttachment) by the AttachContentPlugin. I disabled the AttachContentPlugin and the error message disappeared. It seems that AttachContentPlugin cannot deal with the new CSRF-securing mechanism in Foswiki 1.0.5.
• Set active/inactive: the error message appearing at selection of this link is because the save script is called with GET, I think: .../bin/save/Main/UserName?WorkStatus=Former.

-- WolfgangRaus - 05 Jun 2009

I am a bit confused now.

• This bug was originally raised against PersonalInfoAddOn. And we could not find any GET in that plugin
• This bug is given as the reason why foswiki.org is still on 1.0.0 and still exposed to a severe security vulnerability
• This bug has now been reclassified to AttachContentPlugin
• AttachContentPlugin is not installed on foswiki.org!!

So - forgive me - but I have totally lost the point now.

• Do we have a bug in PersonalInfoAddOn or not?

-- KennethLavrsen - 08 Jun 2009

And I just tested AttachContentPlugin. It is a plugin that saves everything between two tags as an attachment. It has nothing to do with GET and POST. It does not use any forms. It saves an attachment using the standard API in one of the plugin handlers. And it works fine. I just tested it on my 1.0.5 Foswiki.

I have reassigned this to PersonalInfoAddOn. But it could be the interaction of the two that is the problem. But I cannot see this as a roadblock to upgrading foswiki.org to 1.0.5 any longer.

-- KennethLavrsen - 08 Jun 2009

There are at least 2 bugs in PersonalInfoAddOn, today I stumbled on the third type of "GET denied for save"-error message with PersonalInfoAddOn: if you WYSIWYG-edit the user topic with TinyMCE (pattern skin), then you get this message at save or cancel. Raw edit is ok, NatEdit is ok.

Perhaps I misunderstand some concepts/names/words, my english is not the best. But in my source of HTML knowledge (http://de.selfhtml.org/) the difference between the methods GET and POST are good described. In short: If you append a data stream with a "?" to the URL, it is method GET. Only if you specify method=post in the form definition, it is POST.

In the Security Alert 2009-1434 I read "no data can be saved unless the change is submitted using an HTTP POST request." and "If you have implemented an application that generates links to the Foswiki save or view scripts, you will need to alter this application to instead display HTML forms with a submit button." - see Support.SecurityAlert-CVE-2009-1434#Resolution_in_1_0_5.

The three instances of the "GET error message" I got in coherence with the PersonalInfoAddOn, Foswiki 1.05 and user topics are:

1. If you edit your formular data, on save the error message occur, but the data was saved. This occurs only if the AttachContentPlugin is installed and activated (as recommended for the PersonalInfoAddOn in the docs).
   • I did not find the reason so far.
2. If you select the link "Set inactive/active" on a user topic with the view template PersonalInfoUserView enabled, you get the error message.
   • Reason seems to be the call of the save script with parameter in PersonalInfoModules:

     %IF{"$'FORMFIELD{WorkStatus}'!='Current'" then="<a href='%SCRIPTURL{save}%/%BASEWEB%/%BASETOPIC%?WorkStatus=Current'>Set active</a>" else="<a href='%SCRIPTURL{save}%/%BASEWEB%/%BASETOPIC%?WorkStatus=Former'>Set inactive</a>"}%</div>" }%

     Cause there is no form, there is no method=post.
3. If you edit the user topic with TinyMCE, then you get the error message at save or cancel.
   • Reason seems to be the call of the save script with the parameter redirectto=%TOPIC in the view template PersonalInfoUserViewTemplate.

I do not see this bugs as blockers for any upgrade. Only the second one ("Set active/inactive"-Link) will have an effect on foswiki.org. Is there a reason that test.foswiki.org cannot have the package outfit with patternskin? (Sure there will be a good reason, too few time )

-- WolfgangRaus - 09 Jun 2009

Fourth instance of the error message with PersonalInfoAddOn: In the topic PersonalInfo, if you click the link "update the directSearch javascript file now" (visible only if AttachContenPlugin is enabled), the error message ist displayed and no save of the attachment is done.

Reason: the script save is called without form method=post:

<a href="%SCRIPTURL{save}%/%WEB%/%TOPIC%?action_save=1">update the directSearch javascript file now</a>

Again: this can only happen if AttachContentPlugin is installed and enabled. No problem for foswiki.org.

-- WolfgangRaus - 10 Jun 2009

Affects me too in all the mentioned places:

1. Edit data
2. Set inactive
3. update the directSearch javascript file now

Since foswiki.org uses the plugin it it will also be affected in case of an upgrade.

-- IngoKappler - 26 Jun 2009

When save could be called in a redirectto parameter, the topic PersonalInfo would be saved, and hence the javascript file (using AttachContentPlugin).

Now when updating a personal topic, that javascript file won't get updated automatically. Now this needs to be done in a separate action, or with a cron job. This is quite unfortunate.

-- ArthurClemens - 27 Jun 2009

Now I removed the "Edit data" and "Set inactive" links from the home topic as both can be handled when normally editing the form data and I planned to disable at least the "Edit data" link anyway, since it caused some issues for me when using macros in the form data (http://foswiki.org/Tasks/Item1277).

To disable the links this was done in PersonalInfoModules:

%IF{"not defined editUserData" then="<div class='personalInfoFormDataActions twikiUnvisited'> <!-- [[%SCRIPTURL{view}%/%BASEWEB%/%BASETOPIC%?editUserData=on][Edit data]] <span class='twikiSeparator'>|</span> --> [[%SCRIPTURL{view}%/%BASEWEB%/%BASETOPIC%?template=PersonalInfoPictureView][Change picture]] <!-- <span class='twikiSeparator'>|</span> %IF{"$'FORMFIELD{WorkStatus}'!='Current'" then="<a href='%SCRIPTURL{save}%/%BASEWEB%/%BASETOPIC%?WorkStatus=Current'>Set active</a>" else="<a href='%SCRIPTURL{save}%/%BASEWEB%/%BASETOPIC%?WorkStatus=Former'>Set inactive</a>"}% --> </div>" }% %IF{"defined editUserData" then="<div class='personalInfoFormDataActions'><input type='submit' class='twikiSubmit' name='action_save' id='save' value='Save' /> <input type='submit' class='foswikiButton' name='action_cancel' id='cancel' value='Cancel' /></div>" }%" }% </form></div><!--/pIparagraphFrame-->%ENDSECTION{"personalInfo"}%

-- IngoKappler - 22 Jul 2009

Could anyone suggest an appropriate workaround for the error with TinyMCE on save/cancel? I understand that this is caused by the redirectto in the view template PersonalInfoUserViewTemplate (from WolfgangRaus). We are attempting to migrate from T* 4.0.5 - should I be using a skin other than PatternSkin to avoid this issue? Advice welcome.

-- SteveJones - 19 Nov 2009

The error still happens when you click on the bottom edit link. In contrast to the top edit pencil, this one has got a redirectto link in it which is a redirect into a save script. This basically is a GET. However save does not allow GET anymore. Suggestion: hook into the edit form's submit process and do an ajax post to the save url before continuing on the normal save on the current topic.

For now I disabled the extra edit_topic_link definition in PersonalInfoUserViewTemplate

-- MichaelDaum - 09 Dec 2009

Has there been any update to this? I am experiencing the same issues..

-- PadraigLennon - 19 Jan 2010

Ok, it seems I fixed the email parsing on the foswiki.org branch, but nowhere else. As this branch is not used (yet), I've hacked Rev 3788 not found directly onto foswiki.org, so this somehow works again. It should be pretty safe to commit this change, but...

-- OlivierRaginel - 25 Jan 2010

I've checked in to svn a partial fix (will defo need to be reworked) for the GET denied error..

-- PadraigLennon - 26 Jan 2010

In our company no one reported the error and therefore I wasn't aware. I looked at the PersonalInfoUserViewTemplate and there is the redirect, that is causing the problems after clicking Edit and then Save or Cancel. I do not know why the redirect is there in the first place so I just renamed the "edit_topic_link" to "edit_topic_link_old" and everything is working just fain (taking the default "edit_topic_link"). No more "Bad request" after save or cancel.

In our company editing the fields only displayed by the addon was not enough so I changed the url to one used to edit only form data of any topic "edit/Main/User?action=form". So that fixed the editing problem.

Problem with "Set Inactive" I ignored, because thanks to the above fix I can quickly change it anyway, so I deleted this functionality. Also not if it is a function any user uses, usually used by me when user leaves, so no big deal.

Hope this helps a little.

-- PetrMatejka - 02 Aug 2010

The functionality was there to 'automatically' save the PersonalInfo topic, thereby creating an attachment with user data. The attachment reads much faster than a query. But it might be possible to use a cron job as well to generate this attachment - I haven't tried that.

-- ArthurClemens - 02 Aug 2010

Fixed with addon release 1.6. Now this version needs to get installed on this site.

-- ArthurClemens - 15 Aug 2010