IE8: Sessions without cookies are broken

Hi, when using sessions without cookies and IE8, I can't

Thu, 14 Feb 2013 14:29:29 +0000

Hi, when using sessions without cookies and IE8, I can't even delete a message. The log is full with IMAP server authentication errors. Might be related to #11570. Thomas

Re-lowering priority - non-cookie sessions are expressly not

Sun, 17 Feb 2013 05:21:59 +0000

Re-lowering priority - non-cookie sessions are expressly not recommended by our docs since they are a security risk.

Can't reproduce.

Mon, 18 Feb 2013 02:16:44 +0000

Can't reproduce.

> Can't reproduce. Ok, I found out what's going on after

Tue, 19 Feb 2013 13:38:05 +0000

> Can't reproduce. Ok, I found out what's going on after adding debug traces to Horde_Secret. Remember Jan mentioning the invalid requests from broken CSS support in IE8? The requests without the session id cause the secret key in Horde_Secret::setKey() to be overwritten with the new session id. This also updates the value in "$this->_keyCache". Subsequent IMAP requests can't decrypt the password anymore and fail. -> One "broken" requests kills the whole session. Steps to reproduce: - Sessions without cookies in horde - Disable cookies in PHP - Clear all horde cookies - Mark a message - Hover "Delete" button -> new session id will be generated by invalid request What I'm wondering about: How does the value in "$this->_keyCache" survive between HTTP requests? When the next request with the original session id arrives, $this->_keyCache['horde_secret'] returns the new, invalid session id.

This is a problem with CSS theming/images, not IMP.

Wed, 20 Feb 2013 01:44:03 +0000

This is a problem with CSS theming/images, not IMP.

Changes have been made in Git (master): commit b31b393c5d79

Wed, 20 Feb 2013 05:50:15 +0000

Changes have been made in Git (master): commit b31b393c5d7952e4c7391cc41c0b91b24a593fa6 Author: Michael M Slusarz Date: Tue Feb 19 22:45:08 2013 -0700 [mms] Use csstidy library to parse CSS files when creating static CSS (Bug #12043). Should be more efficient, since we don't have to search for url parameters three different times. Also, should be more robust (fixes support for multiple urls in a single CSS style). Side effect: $conf['cachecssparams']['compress'] is no longer needed - since we are already necessarily parsing the CSS, there's no reason not to compress when saving. Will remove the option in Horde 5.1 for clarity. framework/Core/lib/Horde/Themes/Css.php | 98 ++++++++++++++++++------------- framework/Core/package.xml | 2 + 2 files changed, 58 insertions(+), 42 deletions(-) http://git.horde.org/horde-git/-/commit/b31b393c5d7952e4c7391cc41c0b91b24a593fa6

Does this help? Turns out that our CSS parsing was only a

Wed, 20 Feb 2013 05:52:13 +0000

Does this help? Turns out that our CSS parsing was only able to replace one url() within a CSS rule. Maybe this was what was confusing IE8 - having a relative URL and a data URL in the same rule. Now it will either be both data URLs or both relative URLs. At a minimum, the new CSS parsing should be more robust and possibly faster.

Changes have been made in Git (master): commit 9da6c272b7ec

Wed, 20 Feb 2013 07:41:19 +0000

Changes have been made in Git (master): commit 9da6c272b7ec9b23f87aae0ace04052166c86cc4 Author: Michael M Slusarz Date: Wed Feb 20 00:40:14 2013 -0700 IE8 doesn't support multiple background url definitions (Bug #12043) horde/themes/default/ie8.css | 24 ++++++++++++++++++++++++ 1 files changed, 24 insertions(+), 0 deletions(-) http://git.horde.org/horde-git/-/commit/9da6c272b7ec9b23f87aae0ace04052166c86cc4

Your latest change fixed the issue for IE8. Thanks! btw

Wed, 20 Feb 2013 13:10:03 +0000

Your latest change fixed the issue for IE8. Thanks! btw: It's a bit surprising that the Horde_Secret::getKey() function updates the cookie information in case the value is unknown. IMHO it's better if a getXXX() function works without side-effects.

> btw: It's a bit surprising that the Horde_Secret::getKey()

Sun, 24 Feb 2013 06:01:31 +0000

> btw: It's a bit surprising that the Horde_Secret::getKey() function > updates the cookie information in case the value is unknown. IMHO > it's better if a getXXX() function works without side-effects. This is the way it always has worked. And it makes sense to me: this is the only way of guaranteeing that the key returned from getXXX() function will be the same key returned on the next page access (if a session is currently active).