Tickets :: [#9289] Cannot save preferences after upgrade to 1.2.7. We cannot verify that this request was really sent by you. It could be a malicious request.

6.0.0-alpha12

6/7/25

Summary	Cannot save preferences after upgrade to 1.2.7. We cannot verify that this request was really sent by you. It could be a malicious request.
Queue	Horde Groupware Webmail Edition
Queue Version	1.2.7
Type	Bug
State	Resolved
Priority	3. High
Owners	Horde Developers (at) , jan (at) horde (dot) org, slusarz (at) horde (dot) org
Requester	software-horde (at) interfasys (dot) ch
Created	10/06/2010 (5358 days ago)
Due
Updated	03/07/2011 (5206 days ago)
Assigned	10/20/2010 (5344 days ago)
Resolved	10/21/2010 (5343 days ago)
Github Issue Link
Github Pull Request
Milestone	1.2.8
Patch	No

03/07/2011 10:59:01 PM	twoodard (at) woodardenterprises (dot) com	Comment #33	Reply to this comment
[Show Quoted Text - 15 lines][Hide Quoted Text] The users cannot save their preferences anymore. They get the dreaded "We cannot verify that this request was really sent by you. It could be a malicious request. If you intended to perform this action, you can retry it now" It also happens without having to save anything, by just going to the page: services/prefs.php?app=imp&group=identities There is nothing in the Horde log, appart from IMAP errors: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN I've tried disabling tokens, cookies, nothing helped. The server is running a dual IP stack (v4 and v6). Net_DNS has been removed because it doesn't work with IPv6. We're using PHP sessions. Folks, I just had a new client call me about this issue when she logged into her webmail. I just wanted to attach my findings. In her case, when i had Virus Scan turned on to verify and check webpages, this error appeared, but when i turn it off the problem went away. So it looks like my issue is when a virus scan program is being utilized to verify webpages the error occurs. Basically you are creating your own personal proxy scanner, so this could be why it doesn't think it is coming from the same source. Don't know if this helps you at all, just wanted to share my findings.

10/28/2010 10:35:22 PM	Michael Slusarz	Comment #32	Reply to this comment
Unfortunately after upgrade I still get "We cannot verify that this request..." when trying to delete sync sessions from Horde/Options/SyncML. Moved to ~~Ticket #9349~~

10/27/2010 08:24:48 PM	peo (at) intersonic (dot) se	Comment #31	Reply to this comment
Does this fix things for everyone? We'd like to make a new release with regression fixes. Wow, there was already a v1.2.8 before I even found time to apply the patches for v1.2.7. Upgraded to v1.2.8 Solve the issues mention for us. Beter still it solve the Horde installation path issue when upgrading! :)) WELL done Horde team, THX! Unfortunately after upgrade I still get "We cannot verify that this request..." when trying to delete sync sessions from Horde/Options/SyncML. Oct 27 22:23:28 direwolf horde[8584]: [horde] Backend of class SyncML_Backend_Horde created [pid 8584 on line 287 of "/usr/local/www/horde/lib/SyncML/Backend.php"] Oct 27 22:23:28 direwolf horde[8584]: [horde] We cannot verify that this request was really sent by you. It could be a malicious request. If you intended to perform this action, you can retry it now. [pid 8584 on line 176 of "/usr/local/www/horde/lib/Horde/Notification.php"] Oct 27 22:23:28 direwolf horde[8584]: [horde] SQL Query by SyncML_Backend_Horde::getUserAnchors(): SELECT syncml_syncpartner, syncml_db, syncml_clientanchor, syncml_serveranchor FROM horde_syncml_anchors WHERE syncml_uid = ?, values: peo [pid 8584 on line 650 of "/usr/local/www/horde/lib/SyncML/Backend/Horde.php"]

10/25/2010 08:52:50 PM	cor3huis (at) gmail (dot) com	Comment #30	Reply to this comment
Does this fix things for everyone? We'd like to make a new release with regression fixes. Wow, there was already a v1.2.8 before I even found time to apply the patches for v1.2.7. Upgraded to v1.2.8 Solve the issues mention for us. Beter still it solve the Horde installation path issue when upgrading! :)) WELL done Horde team, THX!

10/22/2010 01:13:38 AM	software-horde (at) interfasys (dot) ch	Comment #29 New Attachment: megapatch.diff	Reply to this comment
Patch was lost when I failed the spam protection test :D

10/22/2010 01:12:37 AM	software-horde (at) interfasys (dot) ch	Comment #28	Reply to this comment
the problem persist changing some in current default profile or creating a new one Sorry? Can you try to explain again, I don't understand what you mean. And did you apply all patches? How many patches are there in the end? I counted 4 Applied megapatch.diff from the horde folder # patch -p0 < megapatch.diff Tested by creating and deleting an identity and it worked fine

10/22/2010 12:57:20 AM	software-horde (at) interfasys (dot) ch	Comment #27	Reply to this comment
the problem persist changing some in current default profile or creating a new one Sorry? Can you try to explain again, I don't understand what you mean. And did you apply all patches? How many patches are there in the end?

10/21/2010 10:56:24 AM	Jan Schneider	Comment #26	Reply to this comment
the problem persist changing some in current default profile or creating a new one Sorry? Can you try to explain again, I don't understand what you mean. And did you apply all patches?

10/21/2010 09:57:46 AM	mazzotti (at) netsitech (dot) com	Comment #25	Reply to this comment
the problem persist changing some in current default profile or creating a new one

10/21/2010 08:52:01 AM	Jan Schneider	State ⇒ Resolved

10/20/2010 10:47:51 PM	sam (at) australiaonline (dot) net (dot) au	Comment #24	Reply to this comment
Does this fix things for everyone? We'd like to make a new release with regression fixes. Updating from CVS with the specific revisons seems to have fixed the issues for my installations.

10/20/2010 01:24:40 PM	lang (at) b1-systems (dot) de	Comment #23	Reply to this comment
looks like this works on two different setups of mine.

10/20/2010 10:41:04 AM	Jan Schneider	Comment #22 Assigned to Jan Schneider State ⇒ Feedback	Reply to this comment
Does this fix things for everyone? We'd like to make a new release with regression fixes.

10/19/2010 08:52:21 PM	Jan Schneider	Comment #21	Reply to this comment
Correct links: http://cvs.horde.org/diff.php/horde/templates/prefs/deleteidentity.inc?rt=horde&r1=1.2.10.1&r2=1.2.10.2&ty=u http://cvs.horde.org/diff.php/horde/services/prefs.php?rt=horde&r1=1.19.2.19&r2=1.19.2.20&ty=u

10/19/2010 05:55:07 PM	CVS Commit	Comment #20	Reply to this comment
Changes have been made in CVS for this ticket: Sign link to delete identity with token (~~Bug #9289~~). http://cvs.horde.org/diff.php/horde/templates/prefs/deleteidentity.inc?rt=horder1=1.2.10.1r2=1.2.10.2ty=u

10/19/2010 05:54:35 PM	CVS Commit	Comment #19	Reply to this comment
Changes have been made in CVS for this ticket: Be more strict when to check for token (~~Bug #9289~~). http://cvs.horde.org/diff.php/horde/services/prefs.php?rt=horder1=1.19.2.19r2=1.19.2.20ty=u

10/18/2010 08:54:13 AM	mazzotti (at) netsitech (dot) com	Comment #18	Reply to this comment
Not fixed: same problem in updating and deleting Only displaying personal info was fixed

10/15/2010 08:53:59 AM	joseangeltome (at) gmail (dot) com	Comment #17	Reply to this comment
I get the same error when I try to delete an identity. Is it a new bug or the same? I have the doubt because this seems to be "resolved". Thanks! Fixed. Proper URLs: http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horde&r1=1.515.2.625&r2=1.515.2.626&ty=u http://cvs.horde.org/diff.php/horde/services/prefs.php?rt=horde&r1=1.19.2.18&r2=1.19.2.19&ty=u

10/13/2010 12:33:07 AM	sam (at) australiaonline (dot) net (dot) au	Comment #16	Reply to this comment
Fixed. Proper URLs: Still couldn't get the URLs to work. They provide a blank page. So I checked out the file 1.19.2.19 directly from CVS. The change fixes the malicious request error message when entering the preferences->personal information screens. However it doesn't allow an identity to be deleted. Users still get the malicious request error message when they try and delete an identity.

10/12/2010 09:30:33 PM	Michael Slusarz	Comment #15 State ⇒ Resolved Assigned to Michael Slusarz	Reply to this comment
Fixed. Proper URLs: http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horde&r1=1.515.2.625&r2=1.515.2.626&ty=u http://cvs.horde.org/diff.php/horde/services/prefs.php?rt=horde&r1=1.19.2.18&r2=1.19.2.19&ty=u

10/12/2010 09:29:28 PM	CVS Commit	Comment #14	Reply to this comment
Changes have been made in CVS for this ticket: ~~Bug: 9289~~ Fix errors introduced with the v3.3.9 prefs form token changes. http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horder1=1.515.2.625r2=1.515.2.626ty=u http://cvs.horde.org/diff.php/horde/services/prefs.php?rt=horder1=1.19.2.18r2=1.19.2.19ty=u

10/12/2010 08:21:51 PM	arjen+horde (at) de-korte (dot) org	Comment #13	Reply to this comment
I added the supposed fix (long tags) and it didn't help. Unfortunately the diff link to the commit message below is broken and the CVS web browse also doesn't seem to work. The '&' characters from the CVS links are missing. Corrected one is http://cvs.horde.org/diff.php/horde/templates/prefs/begin.inc?rt=horde&r1=1.13.2.7&r2=1.13.2.8&ty=u This started happening the beginning of September this year.

10/12/2010 08:09:58 PM	peter (dot) meier (at) immerda (dot) ch	Comment #12	Reply to this comment
While php short tags added to the symptoms of this bug for some servers, it doesn't appear to be the cause as adding the full tag does not change the symptoms for those who processed the short tag and it doesn't stop the error message from being displayed. +1 I added the supposed fix (long tags) and it didn't help. Unfortunately the diff link to the commit message below is broken and the CVS web browse also doesn't seem to work.

10/11/2010 12:30:32 AM	sam (at) australiaonline (dot) net (dot) au	Comment #11	Reply to this comment
BTW PHP.INI states ; NOTE: Using short tags should be avoided Clear While php short tags added to the symptoms of this bug for some servers, it doesn't appear to be the cause as adding the full tag does not change the symptoms for those who processed the short tag and it doesn't stop the error message from being displayed.

10/11/2010 12:20:06 AM	cor3huis (at) gmail (dot) com	Comment #10	Reply to this comment
BTW PHP.INI states ; NOTE: Using short tags should be avoided Clear ; For deployment on PHP servers which are not under your control, because short tags may not ; be supported on the target server. So true for Horde users on a normal webhoster plan ; For portable, redistributable code, be sure not to use short tags. PLZ

10/11/2010 12:11:24 AM	cor3huis (at) gmail (dot) com	Comment #9	Reply to this comment
Same issue here :( never encountered in v1.2.6...

10/10/2010 11:39:11 PM	sam (at) australiaonline (dot) net (dot) au	Comment #8	Reply to this comment
Now, users can change their preferences, but the error message does not disappear.. My server was processing the short form, so that likely explains why I was seeing the preferences save successfully. I added the full form and the symptoms didn't change. It still displays the warning in the personal information preferences screen.

10/10/2010 09:47:26 PM	peo (at) intersonic (dot) se	Comment #7	Reply to this comment
Delete SyncML sessions fails Horde 3.3.9 in a similar manner. Under Options/SyncML When trying to delete sync session data, I get the following response: "We cannot verify that...."

10/08/2010 05:25:27 PM	Michael Slusarz	Comment #6 State ⇒ Assigned Assigned to Horde Developers Milestone ⇒ 1.2.8	Reply to this comment
Fixed the PHP short tag issue (in Horde 3.3.10).

10/08/2010 05:24:32 PM	CVS Commit	Comment #5	Reply to this comment
Changes have been made in CVS for this ticket: ~~Bug: 9289~~ Don't use short tag. http://cvs.horde.org/diff.php/horde/templates/prefs/begin.inc?rt=horder1=1.13.2.7r2=1.13.2.8ty=u

10/08/2010 05:18:42 PM	software-horde (at) interfasys (dot) ch	Comment #4	Reply to this comment
Nice catch! Our server doesn't support the php short tag :) I can confirm that the error message doesn't go away. Also, I didn't find any other short tags in the code. [Show Quoted Text - 15 lines][Hide Quoted Text] I have the same issue since I have upgraded my webmail to the 1.2.7 version. In the templates/prefs/begin.inc file, I have change this line : <input type="hidden" name="horde_prefs_token" value="<? echo Horde::getRequestToken('horde_prefs') ?>" /> by : <input type="hidden" name="horde_prefs_token" value="<?php echo Horde::getRequestToken('horde_prefs') ?>" /> Now, users can change their preferences, but the error message does not disappear.. Best regards.

10/08/2010 02:49:01 PM	***.	Comment #3	Reply to this comment
I have the same issue since I have upgraded my webmail to the 1.2.7 version. In the templates/prefs/begin.inc file, I have change this line : <input type="hidden" name="horde_prefs_token" value="<? echo Horde::getRequestToken('horde_prefs') ?>" /> by : <input type="hidden" name="horde_prefs_token" value="<?php echo Horde::getRequestToken('horde_prefs') ?>" /> Now, users can change their preferences, but the error message does not disappear.. Best regards.

10/08/2010 12:38:33 AM	sam (at) australiaonline (dot) net (dot) au	Comment #2	Reply to this comment
The users cannot save their preferences anymore. They get the dreaded "We cannot verify that this request was really sent by you. It could be a malicious request. If you intended to perform this action, you can retry it now" Seeing the same message, except only on the "Personal Information" pages of both Global and Mail options. The user can save changes to their preferences though. The warning shows on each redisplay of the page from first entering it to saving changes. Deleting an identity doesn't appear to work.

10/06/2010 04:39:29 AM	software-horde (at) interfasys (dot) ch	Comment #1 Priority ⇒ 3. High State ⇒ Unconfirmed Patch ⇒ No Milestone ⇒ Summary ⇒ Cannot save preferences after upgrade to 1.2.7. We cannot verify that this request was really sent by you. It could be a malicious request. Type ⇒ Bug Queue ⇒ Horde Groupware Webmail Edition	Reply to this comment
The users cannot save their preferences anymore. They get the dreaded "We cannot verify that this request was really sent by you. It could be a malicious request. If you intended to perform this action, you can retry it now" It also happens without having to save anything, by just going to the page: services/prefs.php?app=imp&group=identities There is nothing in the Horde log, appart from IMAP errors: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN I've tried disabling tokens, cookies, nothing helped. The server is running a dual IP stack (v4 and v6). Net_DNS has been removed because it doesn't work with IPv6. We're using PHP sessions.