We have contextmenu 1.8 and keyboard_shortcuts 1.4 under RC 0.7.2 installed, and it appears that they are incompatible.
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
But, much more important: In the middle of composing this message, I've been thrown back to the RC login screen again because of an invalid or expired session for the %&"!§?= time (see other threads). And while writing this sentence, a red "Request timed out!" at the top of the screen came up.
This all is really frustrating and anything but stable.
Is there nothing we can do about it?? <deep sigh>
Ah, THIS might be of interest (I just realized that there is an error indicated in the lower left corner of the status bar of the compose window):
Details zum Fehler auf der Webseite
Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Zeitstempel: Tue, 24 Apr 2012 17:21:01 UTC
Meldung: 'rcmail' ist undefiniert Zeile: 16 Zeichen: 1 Code: 0 URI: http://www.xxxxxxxxx.de/webmail3/?_unlock=loading1335287591551
Although in German, I think the message is clear. Does that tell anybody anything?
Upon sending the message quoted below, the screenshot attached could be seen for a few minutes, but finally the message has apparently been sent (I didn't wait for it but had a cigarette outside instead).
Look at the message in the lower left corner. This "_unlock..." is irritating me.
And while typing this, I'm thrown back to the RC login screen again with a session timeout (the second time during the last 45 mins). What the heck is going on here...?
Need to finish this message quickly, before it happens again.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 24.04.2012 19:29, schrieb Michael Heydekamp:
We have contextmenu 1.8 and keyboard_shortcuts 1.4 under RC 0.7.2 installed, and it appears that they are incompatible.
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
But, much more important: In the middle of composing this message, I've been thrown back to the RC login screen again because of an invalid or expired session for the %&"!§?= time (see other threads). And while writing this sentence, a red "Request timed out!" at the top of the screen came up.
This all is really frustrating and anything but stable.
Is there nothing we can do about it?? <deep sigh>
Ah, THIS might be of interest (I just realized that there is an error indicated in the lower left corner of the status bar of the compose window):
Details zum Fehler auf der Webseite
Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Zeitstempel: Tue, 24 Apr 2012 17:21:01 UTC
Meldung: 'rcmail' ist undefiniert Zeile: 16 Zeichen: 1 Code: 0 URI: http://www.xxxxxxxxx.de/webmail3/?_unlock=loading1335287591551
Although in German, I think the message is clear. Does that tell anybody anything? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
I can reproduce this. Although context_menus isnt mine, i'll have a look at it.
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
This I cant reproduce. What browser?
Cor
On 04/24/2012 07:29 PM, Michael Heydekamp wrote:
Meldung: 'rcmail' ist undefiniert Zeile: 16 Zeichen: 1 Code: 0 URI: http://www.xxxxxxxxx.de/webmail3/?_unlock=loading1335287591551
This the response for draft auto-save request. The content of this response maybe would help.
On Apr 24, 2012, at 8:37 PM, Cor Bosman wrote:
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
I can reproduce this. Although context_menus isnt mine, i'll have a look at it.
This seems to be an issue with the context_menu plugin. It unbinds keypress, which also seems to unbind it for kb plugin. If I comment out line 138 in contextmenu, the issue disappears.
Maybe the author of cm can shed some light on it. Once i know whats up, i'll release a new version with fixed language keys. Guess they changed in roundcube core.
Cor
Am 24.04.2012 20:41, schrieb A.L.E.C:
On 04/24/2012 07:29 PM, Michael Heydekamp wrote:
Meldung: 'rcmail' ist undefiniert Zeile: 16 Zeichen: 1 Code: 0 URI: http://www.xxxxxxxxx.de/webmail3/?_unlock=loading1335287591551
This the response for draft auto-save request. The content of this response maybe would help.
Uh. How can I get hold of this content...?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 24.04.2012 20:37, schrieb Cor Bosman:
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
This I cant reproduce. What browser?
IE8. I had sent a reply already to the list with two screenshots to illustrate the issue, but it's waiting for mod's confirmation still (message 200k too big). I'm gonna send a copy to your personal address.
With regards to the below and all those threads concerning session timeouts and lost server connections, I've just encountered a new scenario:
Opened mail in a new window (using the "gear-wheel" button, selecting "Open in new window"), clicked the reply button, started to compose the message, after a while wanted to look up something in another message and switched back with Alt+Tab to the main window, selected a folder, and got: "Serverfehler! (Forbidden)" Selected a different folder, the same again. Selected a different folder, the same again. And so on...
See screenshot attached.
These things are really driving me crazy.
I should note that I have NOT applied the patch related to http://trac.roundcube.net/ticket/1488429 yet. Is it supposed to help in this respect?
On 24.04.2012 22:03, Michael Heydekamp wrote:
This the response for draft auto-save request. The content of this response maybe would help.
Uh. How can I get hold of this content...?
I don't know what has IE8, but newer browsers have development tools like Firebug for Firefox, where you can see the whole traffic in user-friendly way.
Am 24.04.2012 20:37, schrieb Cor Bosman:
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
I can reproduce this. Although context_menus isnt mine, i'll have a look at it.
Thanks!
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
This I cant reproduce. What browser?
IE8.
See screenshots attached. If you load them in a viewer and switch forth and back between them, you'll get a good imagination of the "flicker".
Missing strings are marked as well.
And as we are speaking: Can I convince you to assign cursor-left and cursor-right to [previousmessages] and [nextmessages]? "j" and "k" do not appear to be very intuitive...
HTH,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael
I understand that it must be frustrating for you having these session problems all the time and no solution to get rid of them. Various people tried to help with different approaches in various threads in this mailing list. We meanwhile discovered that changing user agents can be a problem since the user agent string is used to generate session hashes. That was meant as a security feature to prevent from session hijacking and we'll address that issue.
However, to be honest, your Roundcube installation still seems to be pretty fucked up :-)
In order to take another attempt to track down the issues of session timeouts, I suggest you to do the following:
- Install a recent version of Roundcube (preferably 0.8-beta) from scratch.
- Use the default configuration values where possible
- Do not install or activate any plugins
- Truncate database tables "session" and "cache"
- Start using that fresh installation of Roundcube with your IE8. If
you still experience session problems, try with other browsers such as Firefox or Chrome.
- Enable the config option 'log_session' and check
<roundcubedir>/logs/session if you ever loose a session.
Please keep on reporting, I'm sure we'll be able to find rational explanation for all the weird behavior you're experiencing.
Best, Thomas
On Tue, Apr 24, 2012 at 19:57, Michael Heydekamp listuser@freexp.de wrote:
Upon sending the message quoted below, the screenshot attached could be seen for a few minutes, but finally the message has apparently been sent (I didn't wait for it but had a cigarette outside instead).
Look at the message in the lower left corner. This "_unlock..." is irritating me.
And while typing this, I'm thrown back to the RC login screen again with a session timeout (the second time during the last 45 mins). What the heck is going on here...?
Need to finish this message quickly, before it happens again.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 24.04.2012 19:29, schrieb Michael Heydekamp:
We have contextmenu 1.8 and keyboard_shortcuts 1.4 under RC 0.7.2 installed, and it appears that they are incompatible.
The scenario is: Once you have "used" contextmenu just one time (that is, you have right-clicked on a folder or message), keyboard_shortcuts does not respond anymore to any key.
Another issue with keyboard_shortcuts (not related to contextmenu) is that if you press the "?" key to display the shortcut help, all of a sudden vertical and horizontal scrollbars do appear and cause a sort of "flicker" because of the screen redraw. And there are some missing strings, but that's a minor issue. All in all, keyboard_shortcuts looks a bit outdated. I've disabled it for now.
But, much more important: In the middle of composing this message, I've been thrown back to the RC login screen again because of an invalid or expired session for the %&"!§?= time (see other threads). And while writing this sentence, a red "Request timed out!" at the top of the screen came up.
This all is really frustrating and anything but stable.
Is there nothing we can do about it?? <deep sigh>
Ah, THIS might be of interest (I just realized that there is an error indicated in the lower left corner of the status bar of the compose window):
Details zum Fehler auf der Webseite
Benutzer-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Zeitstempel: Tue, 24 Apr 2012 17:21:01 UTC
Meldung: 'rcmail' ist undefiniert Zeile: 16 Zeichen: 1 Code: 0 URI: http://www.xxxxxxxxx.de/webmail3/?_unlock=loading1335287591551
Although in German, I think the message is clear. Does that tell anybody anything? -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Am 28.04.2012 18:20, schrieb Thomas Bruederli:
However, to be honest, your Roundcube installation still seems to be pretty fucked up :-)
Well, I wouldn't say so. ;) It's a pretty standard installation of the latest stable release - which is 0.7.2.
The only mistake we did in the beginning was that we copied some older plugins of our 0.5.x installation to the 0.7.2 installation. That indeed caused some problems here and there (e.g. with the address book), but they were not related to session timeouts or server errors. Now all plugins are current and compatible with 0.7.2.
In order to take another attempt to track down the issues of session timeouts, I suggest you to do the following:
- Install a recent version of Roundcube (preferably 0.8-beta) from scratch.
That would be our third RC installation then. I'll have a word with my main admin, but wouldn't it be more helpful to stick with the current 0.7.2 installation if we really want to track down this stuff? Because with this environment we are indeed seeing the problems.
If we would install 0.8-beta and the problems would seem (!) to be gone, we wouldn't still know why exactly. And we would never know if at some stage they wouldn't appear again. In some way I'm sort of "happy" to see those problems, as this is the only chance to track them down. Getting rid of bugs/problems by coincidence would be a somewhat, uh, sloppy way.
- Use the default configuration values where possible
I'd say we have a pretty default configuration already (or still, as you want). Well, I've enabled QP encoding for instance (dunno why the default is disabled), set the line length to 76 instead of 72, disabled 'format=flowed' temporarily (I remember that it was called 'format=flawed' when I was still developing our own mail client years ago, but I can't recall the reasons in detail anymore), and we had to set 'imap_force_lsub' to true due to dovecot
- all in all that's it, I'd say.
- Do not install or activate any plugins
Hmm, uh, some of them I/we really need. But for testing purposes, I may do it if it helps.
- Truncate database tables "session" and "cache"
This task I will have to assign to my main admin. I'm not touching this.
- Start using that fresh installation of Roundcube with your IE8. If
you still experience session problems, try with other browsers such as Firefox or Chrome.
Really...? If the problems (or a part of them) should be browser-related, how could we track them down then? RC should run with IE as well, shouldn't it?
Plus that I'm reluctant to scatter my system with all sorts of software and browsers. I'm not a fan of IE (not that I'm being misunderstood in this respect), but it's the browser I'm using, not more not less.
- Enable the config option 'log_session' and check
<roundcubedir>/logs/session if you ever loose a session.
Done. But just a few minutes ago (and two hours too late), as I had a session timeout again two hours ago. Hopefully next time I'll be able to report something meaningful.
Please keep on reporting, I'm sure we'll be able to find rational explanation for all the weird behavior you're experiencing.
Thanks, Thomas.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/01/2012 14:41, Michael Heydekamp wrote:
Am 28.04.2012 18:20, schrieb Thomas Bruederli:
However, to be honest, your Roundcube installation still seems to be pretty fucked up :-)
Well, I wouldn't say so. ;) It's a pretty standard installation of the latest stable release - which is 0.7.2.
But Michael, I've got several hundred users on 0.7.2 daily, with no session timeouts ever. I've been personally been using the latest svn (updated a couple of times per week), no timeouts there, either. I'm not certain what your environment is (haven't been following this all that closely), but it must be either your environment or your install as my instances have been rock stable.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 02.05.2012 00:05, schrieb Arne Berglund:
On 05/01/2012 14:41, Michael Heydekamp wrote:
Am 28.04.2012 18:20, schrieb Thomas Bruederli:
However, to be honest, your Roundcube installation still seems to be pretty fucked up :-)
Well, I wouldn't say so. ;) It's a pretty standard installation of the latest stable release - which is 0.7.2.
But Michael, I've got several hundred users on 0.7.2 daily, with no session timeouts ever.
You lucky one. :)
Serious question: Do you have several hundred users on your server and you have RC just installed but probably not widely used, because your several hundred users are mainly or exclusively using their local mail client (as most of the subscribers to this list, given the "User-Agent" and "X-Mailer" headers I'm seeing)...? Or are these several hundred users really using RC only and all day?
I'm using RC only and all day, no local mail client installed at all, that may be a difference.
And if all of your users should be using RC only and all day (which would surprise me), how can you be sure that they do not experience any session timeouts at all? Because your log files are telling you that, or just because they don't report anything? If the latter - well ... users, you know? ;)
At least, there have been several reports of session timeouts from several other users/administrators besides me here. So there seems to be an issue.
I've been personally been using the latest svn
Well, that's not 0.7.2 stable then, right?
(updated a couple of times per week), no timeouts there, either. I'm not certain what your environment is (haven't been following this all that closely), but it must be either your environment or your install as my instances have been rock stable.
JFTR of this list as of today:
Server-side:
- dedicated server i386/64bit under Debian GNU/Linux 6.0 (Squeeze)
- Dovecot 1.2.15
- Apache 2.2.16
- PHP 5.3.3
- All services running on the same machine, no encryption, no proxy
Locally:
Win7/64 IE8
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 05/01/2012 15:55, Michael Heydekamp wrote:
Serious question: Do you have several hundred users on your server and you have RC just installed but probably not widely used, because your several hundred users are mainly or exclusively using their local mail client (as most of the subscribers to this list, given the "User-Agent" and "X-Mailer" headers I'm seeing)...? Or are these several hundred users really using RC only and all day?
No, I have over 2,000 accounts total, 1600+ are webmail users, and typically 4-500 connected at any given time during the work day. We don't encourage local clients in the organization, so most use Roundcube exclusively.
I'm using RC only and all day, no local mail client installed at all, that may be a difference.
I also use RC exclusively, and have for more than three years now.
And if all of your users should be using RC only and all day (which would surprise me), how can you be sure that they do not experience any session timeouts at all? Because your log files are telling you that, or just because they don't report anything? If the latter - well ... users, you know? ;)
Trust me, my users are whiners. If there were timeouts, I'd know. But I've checked the logs to verify, no session timeouts.
At least, there have been several reports of session timeouts from several other users/administrators besides me here. So there seems to be an issue.
I'm not trying to imply there's no problem, but simply stating that these issues are far from universal, which would lead me to think about your environment.
I've been personally been using the latest svn
Well, that's not 0.7.2 stable then, right?
All of my normal users are on 0.7.2-stable, but I myself am currently testing the latest svn in preparation for roll-out once 0.8 goes stable.
JFTR of this list as of today:
Server-side:
- dedicated server i386/64bit under Debian GNU/Linux 6.0 (Squeeze)
- Dovecot 1.2.15
- Apache 2.2.16
- PHP 5.3.3
- All services running on the same machine, no encryption, no proxy
Locally:
Win7/64 IE8
Both 0.7.2 and svn are hosted on the same server (RHEL5, Apache 2.2.3, PHP 5.3.3). IMAP is on a separate server (also RHEL5, sendmail, Dovecot 1.1.4).
I'm testing mine against both Win7/32 & Mac OS10.7, using primarily Safari & Firefox (on both platforms).
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 02.05.2012 01:21, schrieb Arne Berglund:
On 05/01/2012 15:55, Michael Heydekamp wrote:
And if all of your users should be using RC only and all day (which would surprise me), how can you be sure that they do not experience any session timeouts at all? Because your log files are telling you that, or just because they don't report anything? If the latter - well ... users, you know? ;)
Trust me, my users are whiners. If there were timeouts, I'd know. But I've checked the logs to verify, no session timeouts.
Of course, I trust you.
At least, there have been several reports of session timeouts from several other users/administrators besides me here. So there seems to be an issue.
I'm not trying to imply there's no problem, but simply stating that these issues are far from universal, which would lead me to think about your environment.
Well, as you now know our environment - anything wrong with it?
Given what you're saying (sorry for having shortened the quote a bit), it brings me back to the assumption that it may be a browser-related issue (which I indicated in the subject of some of my previous messages). Have you got a clue which browser your users are using? You're talking about an "organization", so I assume that all of your users are being forced to use a specific browser? If so, which?
I'm testing mine against both Win7/32 & Mac OS10.7, using primarily Safari & Firefox (on both platforms).
So not IE... That's the main difference I'm seeing.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael Heydekamp wrote:
[...]
In order to take another attempt to track down the issues of session timeouts, I suggest you to do the following:
- Install a recent version of Roundcube (preferably 0.8-beta) from scratch.
That would be our third RC installation then. I'll have a word with my main admin, but wouldn't it be more helpful to stick with the current 0.7.2 installation if we really want to track down this stuff? Because with this environment we are indeed seeing the problems.
If we would install 0.8-beta and the problems would seem (!) to be gone, we wouldn't still know why exactly. And we would never know if at some stage they wouldn't appear again. In some way I'm sort of "happy" to see those problems, as this is the only chance to track them down. Getting rid of bugs/problems by coincidence would be a somewhat, uh, sloppy way.
We already tried to track them down with your current version but obviously without success. In the meantime we even made some changes to improve the session validation and they might already have solved your issue as well. Either you install the latest SVN in order to verify or we have to provide patches which you can apply and test again. I just wanted to make sure that you have a fresh installation without any hacking or patching being done so far.
- Use the default configuration values where possible
I'd say we have a pretty default configuration already (or still, as you want). Well, I've enabled QP encoding for instance (dunno why the default is disabled), set the line length to 76 instead of 72, disabled 'format=flowed' temporarily (I remember that it was called 'format=flawed' when I was still developing our own mail client years ago, but I can't recall the reasons in detail anymore), and we had to set 'imap_force_lsub' to true due to dovecot
- all in all that's it, I'd say.
- Do not install or activate any plugins
Hmm, uh, some of them I/we really need. But for testing purposes, I may do it if it helps.
I'm sure you need them but we're in the process of finding a bug. Therefore we first have to locate it and this is the way to do so. I'm not saying you'll never be able to use these plugins again.
- Truncate database tables "session" and "cache"
This task I will have to assign to my main admin. I'm not touching this.
- Start using that fresh installation of Roundcube with your IE8. If
you still experience session problems, try with other browsers such as Firefox or Chrome.
Really...? If the problems (or a part of them) should be browser-related, how could we track them down then? RC should run with IE as well, shouldn't it?
Again, we're trying to track down the problems here and one big factor in a web service is the browser. Sure, it has to work with IE8 or whatever browser but with this, I'd like to learn whether there are differences in session timeouts when using different browsers (from the same machine I forgot to mention).
Plus that I'm reluctant to scatter my system with all sorts of software and browsers. I'm not a fan of IE (not that I'm being misunderstood in this respect), but it's the browser I'm using, not more not less.
That's certainly up to you. But if you want to help investigating this problem, that's one thing I ask for. We cannot help you if everything is working fine for us with other browsers or even with IE8 but yours has some different settings or plugins installed which might cause some weird behavior. I'm just trying to locate the component which causes your session timeouts.
- Enable the config option 'log_session' and check
<roundcubedir>/logs/session if you ever loose a session.
Done. But just a few minutes ago (and two hours too late), as I had a session timeout again two hours ago. Hopefully next time I'll be able to report something meaningful.
I'm sure there'll be another session timeout to be logged :-)
Thanks, Thomas
On 05/01/2012 17:44, Michael Heydekamp wrote:
Well, as you now know our environment - anything wrong with it?
Not with the part I have seen. But the less obvious things like installed plugins, config options, database type and location, other web-apps hosted on the same server, etc. are part of the environment too.
So not IE... That's the main difference I'm seeing.
Longer explanation - while I use primarily Safari on a Mac, my "organization" provides aggregated services to numerous other autonomous agencies. My email system actually serves 13 different domains/agencies. My org has over 400 users, about 60/40% Mac/Windows. But the other 12 agencies are all over the map. A couple are mostly Mac, a few exclusively PC, and at least two of them use IE exclusively.
Doesn't mean your problem isn't browser related, but if so I suspect browser interaction with some other aspect.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
On 02/05/2012 16:13, Arne Berglund wrote:
On 05/01/2012 17:44, Michael Heydekamp wrote:
Well, as you now know our environment - anything wrong with it?
Not with the part I have seen. But the less obvious things like installed plugins, config options, database type and location, other web-apps hosted on the same server, etc. are part of the environment too.
So not IE... That's the main difference I'm seeing.
Longer explanation - while I use primarily Safari on a Mac, my "organization" provides aggregated services to numerous other autonomous agencies. My email system actually serves 13 different domains/agencies. My org has over 400 users, about 60/40% Mac/Windows. But the other 12 agencies are all over the map. A couple are mostly Mac, a few exclusively PC, and at least two of them use IE exclusively.
Doesn't mean your problem isn't browser related, but if so I suspect browser interaction with some other aspect.
I did get the following update on a bug raised, but have not had the time to checkout the SVN:
#1488449: Session invalid because of User-Agent change --------------------------------+------------------------ Reporter: alec | Owner: Type: Bugs | Status: new Priority: 5 | Milestone: 0.8-rc Component: Core functionality | Version: svn-trunk Severity: normal | Resolution: Keywords: | --------------------------------+------------------------
Comment (by thomasb):
User-Agent check removed and general improvements in sending and validating keep-alive requests made in r6134 and r6135. Please test with latest SVN checkout.
Am 02.05.2012 10:05, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
If we would install 0.8-beta and the problems would seem (!) to be gone, we wouldn't still know why exactly. And we would never know if at some stage they wouldn't appear again. In some way I'm sort of "happy" to see those problems, as this is the only chance to track them down. Getting rid of bugs/problems by coincidence would be a somewhat, uh, sloppy way.
We already tried to track them down with your current version but obviously without success. In the meantime we even made some changes to improve the session validation and they might already have solved your issue as well.
Uh, where...? Didn't know that. I was just aware of a fix in the autosave routine, which I haven't applied yet (but will do so most likely this evening). Hopefully this fix will be compatible with 0.7.2 (A.L.E.C said it should).
Either you install the latest SVN in order to verify or we have to provide patches which you can apply and test again.
Well, if you don't mind I would prefer this way for the time being. Simple reason: I can fiddle around with patches myself without having to bother my main admin. A new installation (for me) is a bigger task which I can't/won't do myself.
If you can send me those patches (off-list?), I'll be happy to apply them shortly.
With regards to "latest SVN": In a previous message you said we should install 0.8-beta, so this advice is now superseded with "latest SVN", right? Just wanna be sure...
- Start using that fresh installation of Roundcube with your IE8. If
you still experience session problems, try with other browsers such as Firefox or Chrome.
Ok, should the problems persist after appyling the patches (and/or installing the latest SVN), I'll try it with a different browser.
- Enable the config option 'log_session' and check
<roundcubedir>/logs/session if you ever loose a session.
Done. But just a few minutes ago (and two hours too late), as I had a session timeout again two hours ago. Hopefully next time I'll be able to report something meaningful.
I'm sure there'll be another session timeout to be logged :-)
Hopefully. :-) But we may have another issue here: Although I enabled 'log_session', there is still no file "session" in the logs directory. Are entries to this file written in case of any errors/timeouts only...? So far I haven't had another session timeout since I enabled this option, but I also haven't used RC heavily since then - due to the job I'm being paid for. ;) But now I'm waiting any minute for another timeout and it would be a pity if it would happen, but wouldn't get logged.
If there is anything else for me to do apart from just enabling the option, let me know.
Thanks for still being attentive,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 02.05.2012 20:06, schrieb Michael Heydekamp:
Am 02.05.2012 10:05, schrieb Thomas Bruederli:
I'm sure there'll be another session timeout to be logged :-)
Hopefully. :-) But we may have another issue here: Although I enabled 'log_session', there is still no file "session" in the logs directory. Are entries to this file written in case of any errors/timeouts only...? So far I haven't had another session timeout since I enabled this option, but I also haven't used RC heavily since then - due to the job I'm being paid for. ;) But now I'm waiting any minute for another timeout and it would be a pity if it would happen, but wouldn't get logged.
If there is anything else for me to do apart from just enabling the option, let me know.
Now I got it, apparently "session" is indeed just written when an error/timeout occurs. In the middle of composing a message (and if I'm not totally wrong, exactly in the moment the autosave routine should have saved the message), a session timeout just occurred again (grmpf!), and I found a log "session" with this content:
[02-May-2012 23:10:59 +0200]: Session authentication failed for dnoqrj84a3pds30sk9h3ib0410; invalid auth cookie sent [02-May-2012 23:11:00 +0200]: Aborted session dnoqrj84a3pds30sk9h3ib0410; no valid session data found [02-May-2012 23:11:01 +0200]: Aborted session dnoqrj84a3pds30sk9h3ib0410; no valid session data found
Does that help...? If not, what more can I do next time?
Searched the whole HD for a file containing "dnoqrj84a3pds30sk9h3ib0410" in the name, but with no success. A HD-wide search for a file containing the string "dnoqrj84a3pds30sk9h3ib0410" would have taken ages. In which directory should I look (Win7/64)? Wouldn't it be helpful to indicate the file name (and directory) of the relevant cookie in the session log? Then I could probably have attached it to this mail (although I don't know if this might help).
While I'm typing this, another session timeout in the middle of composing this specific message occured again. The session log says:
[02-May-2012 23:45:15 +0200]: Session authentication failed for 3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent [02-May-2012 23:45:17 +0200]: Aborted session 3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
So much for now,
Michael (being frustrated and "happy" at the same time)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Thu, May 3, 2012 at 12:01 AM, Michael Heydekamp listuser@freexp.dewrote:
Am 02.05.2012 20:06, schrieb Michael Heydekamp:
Am 02.05.2012 10:05, schrieb Thomas Bruederli:
I'm sure there'll be another session timeout to be logged :-)
Hopefully. :-) But we may have another issue here: Although I enabled 'log_session', there is still no file "session" in the logs directory.
Are
entries to this file written in case of any errors/timeouts only...? So
far
I haven't had another session timeout since I enabled this option, but I also haven't used RC heavily since then - due to the job I'm being paid
for.
;) But now I'm waiting any minute for another timeout and it would be a
pity
if it would happen, but wouldn't get logged.
If there is anything else for me to do apart from just enabling the
option,
let me know.
Now I got it, apparently "session" is indeed just written when an error/timeout occurs. In the middle of composing a message (and if I'm not totally wrong, exactly in the moment the autosave routine should have saved the message), a session timeout just occurred again (grmpf!), and I found a log "session" with this content:
[02-May-2012 23:10:59 +0200]: Session authentication failed for
dnoqrj84a3pds30sk9h3ib0410; invalid auth cookie sent
[02-May-2012 23:11:00 +0200]: Aborted session
dnoqrj84a3pds30sk9h3ib0410; no valid session data found
[02-May-2012 23:11:01 +0200]: Aborted session
dnoqrj84a3pds30sk9h3ib0410; no valid session data found
Does that help...? If not, what more can I do next time?
Searched the whole HD for a file containing "dnoqrj84a3pds30sk9h3ib0410" in the name, but with no success. A HD-wide search for a file containing the string "dnoqrj84a3pds30sk9h3ib0410" would have taken ages. In which directory should I look (Win7/64)? Wouldn't it be helpful to indicate the file name (and directory) of the relevant cookie in the session log? Then I could probably have attached it to this mail (although I don't know if this might help).
While I'm typing this, another session timeout in the middle of composing this specific message occured again. The session log says:
[02-May-2012 23:45:15 +0200]: Session authentication failed for
3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent
[02-May-2012 23:45:17 +0200]: Aborted session
3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
This has already been found and discussed. Alec created a new bug in trac and Thomas already created some bugfixes. There are other threads concerning session timeouts/keep-alive problems - I suggest you read them, too.
And yes, the bugfixes can be applied to your 0.7.2 installation without having to install a new (svn?) Roundcube. I'm currently parallel-testing stable 0.7.2 Roundcube, one with the patches, one without. But no results so far as these session failures occur randomly, at least on my installation.
So much for now,
Michael (being frustrated and "happy" at the same time)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Am 03.05.2012 09:11, schrieb Claudio Kuenzler:
On Thu, May 3, 2012 at 12:01 AM, Michael Heydekamp <listuser@freexp.de wrote:
[02-May-2012 23:45:15 +0200]: Session authentication failed for 3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent [02-May-2012 23:45:17 +0200]: Aborted session 3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
This has already been found and discussed. Alec created a new bug in trac and Thomas already created some bugfixes. There are other threads concerning session timeouts/keep-alive problems - I suggest you read them, too.
I believe that I've read all of them since I am subscribed to this list, but well, probably I may have missed something.
Can you provide a link to those "some bugfixes"? Or are you talking about these ones:
http://trac.roundcube.net/ticket/1488449 http://trac.roundcube.net/changeset/6134 http://trac.roundcube.net/changeset/6135
If so, these fixes are related to the change of the User-Agent header, as far as I understand (and the title of the ticket says). But can they be related to the scenario that I'm thrown back to the login screen in the middle of composing a message after say 10-20 mins. of composing? Can a browser change the User-Agent header even WHILE composing a message at all? And does the User-Agent header play a role in this situation at all..?
Sorry if I should be asking silly questions, I'm just trying to understand.
And if you should be talking about other fixes which I may have missed - then a link would come quite handy.
And yes, the bugfixes can be applied to your 0.7.2 installation without having to install a new (svn?) Roundcube.
Ah, THAT sounds good at least.
I'm currently parallel-testing stable 0.7.2 Roundcube, one with the patches, one without. But no results so far as these session failures occur randomly, at least on my installation.
Same here. Sometimes I can work for hours without hitting any problem, sometimes I'm hitting three or four in a row within less than 15 minutes.
BTW: Which mail client are you using? The text part of your message contained the ugly "Kammquoting" Outlook Express was, uh, "famous" for since ages. I had to manually repair it to make the quotes in this message correctly readable.
On Fri, May 4, 2012 at 12:05 AM, Michael Heydekamp listuser@freexp.dewrote:
Am 03.05.2012 09:11, schrieb Claudio Kuenzler:
On Thu, May 3, 2012 at 12:01 AM, Michael Heydekamp <listuser@freexp.dewrote:
[02-May-2012 23:45:15 +0200]: Session authentication failed for
3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent
[02-May-2012 23:45:17 +0200]: Aborted session
3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
This has already been found and discussed. Alec created a new bug in trac and Thomas already created some bugfixes. There are other threads concerning session timeouts/keep-alive problems - I suggest you read them, too.
I believe that I've read all of them since I am subscribed to this list, but well, probably I may have missed something.
Can you provide a link to those "some bugfixes"? Or are you talking about these ones:
http://trac.roundcube.net/ticket/1488449 http://trac.roundcube.net/changeset/6134 http://trac.roundcube.net/changeset/6135
Yes, those are the ones
If so, these fixes are related to the change of the User-Agent header, as far as I understand (and the title of the ticket says). But can they be related to the scenario that I'm thrown back to the login screen in the middle of composing a message after say 10-20 mins. of composing? Can a browser change the User-Agent header even WHILE composing a message at all? And does the User-Agent header play a role in this situation at all..?
Actually I've never had any problems while composing a message. But I'm asking myself the same question about the User-Agent header change.
Sorry if I should be asking silly questions, I'm just trying to understand.
We all try :-) As these errors are pretty random and not everyone is affected its pretty difficult to find the real reason.
And if you should be talking about other fixes which I may have missed - then a link would come quite handy.
And yes, the bugfixes can be applied to your 0.7.2 installation without having to install a new (svn?) Roundcube.
Ah, THAT sounds good at least.
I'm currently parallel-testing stable 0.7.2 Roundcube, one with the patches, one without. But no results so far as these session failures occur randomly, at least on my installation.
Same here. Sometimes I can work for hours without hitting any problem, sometimes I'm hitting three or four in a row within less than 15 minutes.
Call it mystery or coincidence - but since I installed the latest 0.7-svn and testing both versions parallel, I didn't have the Session Invalid error anymore on my "real" 0.7.2 installation. Still waiting to catch it sooner or later though.
BTW: Which mail client are you using? The text part of your message contained the ugly "Kammquoting" Outlook Express was, uh, "famous" for since ages. I had to manually repair it to make the quotes in this message correctly readable.
Gmail.
-- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
On 03/05/2012 23:05, Michael Heydekamp wrote:
Am 03.05.2012 09:11, schrieb Claudio Kuenzler:
On Thu, May 3, 2012 at 12:01 AM, Michael Heydekamp<listuser@freexp.de wrote:
[02-May-2012 23:45:15 +0200]: Session authentication failed for 3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent [02-May-2012 23:45:17 +0200]: Aborted session 3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
This has already been found and discussed. Alec created a new bug in trac and Thomas already created some bugfixes. There are other threads concerning session timeouts/keep-alive problems - I suggest you read them, too.
I believe that I've read all of them since I am subscribed to this list, but well, probably I may have missed something.
Can you provide a link to those "some bugfixes"? Or are you talking about these ones:
http://trac.roundcube.net/ticket/1488449 http://trac.roundcube.net/changeset/6134 http://trac.roundcube.net/changeset/6135
If so, these fixes are related to the change of the User-Agent header, as far as I understand (and the title of the ticket says). But can they be related to the scenario that I'm thrown back to the login screen in the middle of composing a message after say 10-20 mins. of composing? Can a browser change the User-Agent header even WHILE composing a message at all? And does the User-Agent header play a role in this situation at all..?
I think some plugins like Google Frame change the User-Agent header.
Best Regards, Giles Coochey, CCNA Security, CCNA NetSecSpec Ltd giles.coochey@netsecspec.co.uk Tel: +44 (0) 7983 877 438 Live Messenger: giles@coochey.net http://www.netsecspec.co.uk http://www.coochey.net
Michael Heydekamp wrote:
Am 03.05.2012 09:11, schrieb Claudio Kuenzler:
On Thu, May 3, 2012 at 12:01 AM, Michael Heydekamp <listuser@freexp.de wrote:
[02-May-2012 23:45:15 +0200]: Session authentication failed for 3bnr138hd6pj2p1sfbhm27uod1; invalid auth cookie sent [02-May-2012 23:45:17 +0200]: Aborted session 3bnr138hd6pj2p1sfbhm27uod1; no valid session data found
This has already been found and discussed. Alec created a new bug in trac and Thomas already created some bugfixes. There are other threads concerning session timeouts/keep-alive problems - I suggest you read them, too.
I believe that I've read all of them since I am subscribed to this list, but well, probably I may have missed something.
Can you provide a link to those "some bugfixes"? Or are you talking about these ones:
http://trac.roundcube.net/ticket/1488449 http://trac.roundcube.net/changeset/6134 http://trac.roundcube.net/changeset/6135
If so, these fixes are related to the change of the User-Agent header, as far as I understand (and the title of the ticket says). But can they be related to the scenario that I'm thrown back to the login screen in the middle of composing a message after say 10-20 mins. of composing? Can a browser change the User-Agent header even WHILE composing a message at all? And does the User-Agent header play a role in this situation at all..?
Changeset 6135 is not about user agents but makes Roundcube more stable when checking the validity of an active session. It tries to take connection problems into account. Please find attached the above mentioned changesets backported to the 0.7 release branch. You should be able to apply the patch to your installation.
~Thomas
-
A.L.E.C -
Arne Berglund -
Claudio Kuenzler -
Cor Bosman -
Giles Coochey -
Michael Heydekamp -
Thomas Bruederli