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.

The users cannot save their preferences anymore. They get t

Wed, 06 Oct 2010 04:39:29 +0000

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.

> The users cannot save their preferences anymore. > They g

Fri, 08 Oct 2010 00:38:33 +0000

> 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.

I have the same issue since I have upgraded my webmail to th

Fri, 08 Oct 2010 14:49:01 +0000

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 : by : Now, users can change their preferences, but the error message does not disappear.. Best regards.

Nice catch! Our server doesn't support the php short tag :)

Fri, 08 Oct 2010 17:18:42 +0000

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. > 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 : > > > by : > > > Now, users can change their preferences, but the error message does > not disappear.. > > Best regards. >

Changes have been made in CVS for this ticket: Bug: 9289 Do

Fri, 08 Oct 2010 17:24:32 +0000

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

Fixed the PHP short tag issue (in Horde 3.3.10).

Fri, 08 Oct 2010 17:25:27 +0000

Fixed the PHP short tag issue (in Horde 3.3.10).

Delete SyncML sessions fails Horde 3.3.9 in a similar manner

Sun, 10 Oct 2010 21:47:26 +0000

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...."

> Now, users can change their preferences, but the error mes

Sun, 10 Oct 2010 23:39:11 +0000

> 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.

Same issue here :( never encountered in v1.2.6...

Mon, 11 Oct 2010 00:11:24 +0000

Same issue here :( never encountered in v1.2.6...

BTW PHP.INI states ; NOTE: Using short tags should be avo

Mon, 11 Oct 2010 00:20:06 +0000

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

> BTW PHP.INI states > > ; NOTE: Using short tags should b

Mon, 11 Oct 2010 00:30:32 +0000

> 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.

> While php short tags added to the symptoms of this bug for

Tue, 12 Oct 2010 20:09:58 +0000

> 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.

> I added the supposed fix (long tags) and it didn't help.

Tue, 12 Oct 2010 20:21:51 +0000

> 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.

Changes have been made in CVS for this ticket: Bug: 9289 Fi

Tue, 12 Oct 2010 21:29:28 +0000

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

Fixed. Proper URLs: http://cvs.horde.org/diff.php/horde/

Tue, 12 Oct 2010 21:30:33 +0000

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

> Fixed. > > Proper URLs: Still couldn't get the URLs t

Wed, 13 Oct 2010 00:33:07 +0000

> 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.

I get the same error when I try to delete an identity. Is it

Fri, 15 Oct 2010 08:53:59 +0000

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

Not fixed: same problem in updating and deleting Only displ

Mon, 18 Oct 2010 08:54:13 +0000

Not fixed: same problem in updating and deleting Only displaying personal info was fixed

Changes have been made in CVS for this ticket: Be more stri

Tue, 19 Oct 2010 17:54:35 +0000

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

Changes have been made in CVS for this ticket: Sign link to

Tue, 19 Oct 2010 17:55:07 +0000

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

Correct links: http://cvs.horde.org/diff.php/horde/template

Tue, 19 Oct 2010 20:52:21 +0000

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

Does this fix things for everyone? We'd like to make a new r

Wed, 20 Oct 2010 10:41:04 +0000

Does this fix things for everyone? We'd like to make a new release with regression fixes.

looks like this works on two different setups of mine.

Wed, 20 Oct 2010 13:24:40 +0000

looks like this works on two different setups of mine.

> Does this fix things for everyone? We'd like to make a new

Wed, 20 Oct 2010 22:47:51 +0000

> 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.

the problem persist changing some in current default profile

Thu, 21 Oct 2010 09:57:46 +0000

the problem persist changing some in current default profile or creating a new one

> the problem persist changing some in current default profi

Thu, 21 Oct 2010 10:56:24 +0000

> 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?

>> the problem persist changing some in current default prof

Fri, 22 Oct 2010 00:57:20 +0000

>> 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?

>>> the problem persist changing some in current default pro

Fri, 22 Oct 2010 01:12:37 +0000

>>> 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

Patch was lost when I failed the spam protection test :D

Fri, 22 Oct 2010 01:13:38 +0000

Patch was lost when I failed the spam protection test :D

> Does this fix things for everyone? We'd like to make a new

Mon, 25 Oct 2010 20:52:50 +0000

> 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!

>> Does this fix things for everyone? We'd like to make a ne

Wed, 27 Oct 2010 20:24:48 +0000

>> 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"]

> Unfortunately after upgrade I still get "We cannot verify

Thu, 28 Oct 2010 22:35:22 +0000

> 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

> The users cannot save their preferences anymore. > They g

Mon, 07 Mar 2011 22:59:01 +0000

> 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.