Currently I'm following the thread "RoundCube session aborting" very attentively for one reason: It's the main show stopper why we can't finally kick Squirrel from our server yet.
I'm using RC intensively (I do not even have a local mail client installed), and I had to face lots of aborted seesions and lost server connections during "normal" usage of RC, in the worst case even in the middle of composing a message (losing most of the already written text, as the "Automatically save draft every x minutes" function does sometimes also not work too reliable - in the beginning it's working, but after a while - I'm sometimes writing longer messages which may take an hour or more - it often seems just to quit it's job).
I can't describe every single scenario here, as they are simply too many and hard to replicate. It happens just out of the blue, and you can't predict when.
But: My impression in the meantime is that this might be an issue between RC and the browser (in my case IE8). And no hints such as "use FF" or the like, please, this wouldn't solve the problem.
One interesting scenario that I had (and that's why I believe that it may be an RC<->Browser issue):
After sending a message (from a new window, compose_newwindow 3.00 plugin installed, option activated), RC did not react at all anymore to any click or key after I tried to change from the INBOX to the Sent folder. After a while the error message "Request timed out!" was thrown. From this point on, RC was completely unusable.
I'm skipping some details now:
Even worse, I couldn't load the RC login page again. Entering the appropriate URL, IE8 did not even attempt to contact the server (no progress bar in the status bar seen at all), displayed a blank page, and said "Finished" or "Ready" in the lower left corner of the status bar (not sure how the term for the German term "Fertig" in an English version of IE is).
Even more worse: I couldn't even load ANY web page of the domain in question anymore. So if your webmail URL is www.do.main/webmail/, and your home page is accessible under www.do.main/, even the latter one could not be loaded.
BUT: Then, for the first time in my life and just for testing purposes, I used the "InPrivate" mode of IE8. What can I tell ... it worked instantly, I could load the RC login page and all other web pages of the same domain, could login into RC and work with it (while the still open parallel IE window in standard mode was still not attempting to contact the server).
Huh...?
Any comments and input welcome.
TIA, Michael
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 04/20/2012 02:45 PM, Michael Heydekamp wrote:
Currently I'm following the thread "RoundCube session aborting" very attentively for one reason: It's the main show stopper why we can't finally kick Squirrel from our server yet.
It doesn't sound like the same issue, but a couple of our users were experiencing timeouts a while ago while composing messages.
The settings in Roundcube's main.inc.php looked correct (based on what browsers are actually supposed to do), but I set,
$rcmail_config['keep_alive'] $rcmail_config['session_lifetime'] $rcmail_config['min_keep_alive']
back to their default values just to ease troubleshooting. Then, the timeouts stopped happening. *shrug*
On 04/20/2012 14:21, Michael Orlitzky wrote:
On 04/20/2012 02:45 PM, Michael Heydekamp wrote:
Currently I'm following the thread "RoundCube session aborting" very attentively for one reason: It's the main show stopper why we can't finally kick Squirrel from our server yet.
It doesn't sound like the same issue, but a couple of our users were experiencing timeouts a while ago while composing messages.
The settings in Roundcube's main.inc.php looked correct (based on what browsers are actually supposed to do), but I set,
$rcmail_config['keep_alive'] $rcmail_config['session_lifetime'] $rcmail_config['min_keep_alive']
back to their default values just to ease troubleshooting. Then, the timeouts stopped happening. *shrug*
I'm experiencing the compose time-out/error, it stems from a failure in the draft autosave routine. I opened a ticket on this issue, but it was closed as 'worksforme' with a comment to disable plugins. Still happens with all plugins disabled. My settings for the three params listed above are all at the defaults. I have been looking at this problem for several weeks now, it is evident in the trunk (svn) version, but not in 0.7.2 or the pre-packaged 0.8-beta. Still looking at it.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
On 20.04.2012 23:21, Michael Orlitzky wrote:
On 04/20/2012 02:45 PM, Michael Heydekamp wrote:
Currently I'm following the thread "RoundCube session aborting" very attentively for one reason: It's the main show stopper why we can't finally kick Squirrel from our server yet.
It doesn't sound like the same issue,
I agree, but the thread reminded me in some way to the several and different problems I had to encounter. Even here not each of the aborted sessions and lost server connections is identical to the next and previous one.
but a couple of our users were experiencing timeouts a while ago while composing messages.
The settings in Roundcube's main.inc.php looked correct (based on what browsers are actually supposed to do), but I set,
$rcmail_config['keep_alive'] $rcmail_config['session_lifetime'] $rcmail_config['min_keep_alive']
back to their default values just to ease troubleshooting. Then, the timeouts stopped happening. *shrug*
Hmm, to my best knowledge we are running the defaults (you didn't state what your defaults exactly are).
We have:
$rcmail_config['keep_alive'] = 10; $rcmail_config['session_lifetime'] = 10; $rcmail_config['min_keep_alive'] = 60;
These ARE the defaults, right?
I'm not sure what these values are doing exactly and why they are needed at all, so I didn't touch them.
And I hate to say that: I'd really like to get rid of Squirrel, but I have never ever seen any session timeouts, lost server connections, app hangs or the like with it (unless the Internet connection itself had been dropped). It's ugly, it's lacking of UTF-8 support upon quoting a message (therefore, it's almost impossible to reply to mails of web.de users in a right and readable way), but it's stable in the sense that it doesn't throw me back to scratch while composing a message or doing other tasks.
OTOH, I must admit: This is the first evening where I did not encounter any such timeout/connection/hang problems with RC 0.7.2, so I'll check with my main admin if he has changed anything (I asked him to make sure that all plugins are current, which was not the case with each of our used plugins before).
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 21.04.2012 00:20, Arne Berglund wrote:
I'm experiencing the compose time-out/error, it stems from a failure in the draft autosave routine. I opened a ticket on this issue, but it was closed as 'worksforme' with a comment to disable plugins. Still happens with all plugins disabled.
Well, apparently I'm not the only one. That's a bit of a relief.
But nonetheless it still puzzles me how I can run into the the situation that the browser does not even attempt to contact the server and is displaying a white page without any error message, upon "restarting" RC via the appropriate URL after such any session abort or server connection loss (while doing it properly in the "InPrivate" mode parallel and at the same time)...
And I agree, the draft autosave routine seems to be the key issue here. I'm just repeating what my stomach is telling me.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 04/20/2012 06:27 PM, Michael Heydekamp wrote:
Hmm, to my best knowledge we are running the defaults (you didn't state what your defaults exactly are).
We have:
$rcmail_config['keep_alive'] = 10; $rcmail_config['session_lifetime'] = 10; $rcmail_config['min_keep_alive'] = 60;
These ARE the defaults, right?
These are the defaults in 0.7.2:
$rcmail_config['keep_alive'] = 60; $rcmail_config['session_lifetime'] = 10; $rcmail_config['min_keep_alive'] = 60;
If those don't work for you (they /should/ be equivalent to yours), you can try the brute-force method and set session_lifetime to something much higher like an hour (60).
In that case you don't care whether or not the keepalive works, but sessions will potentially hang around long after the user has closed her browser.
Am 21.04.2012 02:35, schrieb Michael Orlitzky:
On 04/20/2012 06:27 PM, Michael Heydekamp wrote:
Hmm, to my best knowledge we are running the defaults (you didn't state what your defaults exactly are).
We have:
$rcmail_config['keep_alive'] = 10; $rcmail_config['session_lifetime'] = 10; $rcmail_config['min_keep_alive'] = 60;
These ARE the defaults, right?
These are the defaults in 0.7.2:
$rcmail_config['keep_alive'] = 60; $rcmail_config['session_lifetime'] = 10; $rcmail_config['min_keep_alive'] = 60;
I must either have been blind or too tired - these are exactly the values we have set. No idea why I stated '10' for 'keep_alive'.
If those don't work for you (they /should/ be equivalent to yours), you can try the brute-force method and set session_lifetime to something much higher like an hour (60).
In that case you don't care whether or not the keepalive works, but sessions will potentially hang around long after the user has closed her browser.
Thanks for the advice, will probably try this later on, but for the time being will stay with the defaults. My feeling is that it is more a browser issue and/or an issue of the autosave routine, but I have no idea what I can do about it.
I do not fully understand the discussion "Roundcube session aborting", where the User-Agent header seems to be an issue. Should I do something in this regard, and if so, what exactly?
I just responded to an e-mail in the users list (which doesn't appear there yet, so I'm not sure if it has really been sent, although it's in the sent folder), and then ran exactly into one of the scenarios again which I described below. Probably a screenshot helps, see attached.
In this state, RC is not only unusable anymore, it is completely stuck and I even can't relogin, as the browser doesn't load any web page of this domain anymore. It doesn't even throw an error message, but just displays a white page.
To send this message, I had to use the "InPrivate" mode of IE8 (this at least works). But what does this tell us? Temp files, cookies, what can be the issue here?
As long as we don't get that solved, we can't roll out RC as our production webmailer.
And just again the same thing: Message sent, RC unusable/stuck, server error, exactly the same screen (also note the missing buttons!) as in the screenshot attached to my post quoted below.
Sending messages definitely is a key issue here, in the meantime I'd say that in almost 50% of all sent messages I'm encountering this same problem afterwards.
One new thing: Only once confirmed yet, but it seems that after ten minutes of waiting I'm able to relogin again in the same Browser tab (without being forced to use the "InPrivate" mode in a new browser session as described below). Most likely related to one of the several 'keep_alive' settings.
But this still doesn't explain why other web pages of the same domain can't be loaded during this period.
Am 21.04.2012 23:29, schrieb Michael Heydekamp:
But this still doesn't explain why other web pages of the same domain can't be loaded during this period.
normally this happens only as plong a php-script has a session open - the same client with the same session-id can not make another request until session_write_close() happened in the first script or it is finished
since session-cookies are domainwide this could explain PARTLY the problem
Am 21.04.2012 23:50, schrieb Reindl Harald:
Am 21.04.2012 23:29, schrieb Michael Heydekamp:
But this still doesn't explain why other web pages of the same domain can't be loaded during this period.
normally this happens only as plong a php-script has a session open - the same client with the same session-id can not make another request until session_write_close() happened in the first script or it is finished
since session-cookies are domainwide this could explain PARTLY the problem
Probably, but if, then indeed only partly:
Thew whole issue getting more and more mysterious. Since yesterday evening the browser is in a "stable" state in so far as I can't load Roundcube at all anymore. Not even if I wait for hours. The wheel in the browser tab is spinning and spinning, no progress bar can be seen, the status in the lower left corner says "Fertig" (Finished/Ready). After a few minutes the browser is throwing the typical message that it can't display the web page and the Roundcube favicon appears in the browser tab instead of the spinning wheel.
I also can't load other web pages of the same domain (at least some of them, didn't check with all).
I really wonder what the hell is going on here. For the moment I'd like to keep the browser in this strange state as I'm hoping that somebody can give some hints and advices how to track down the problem.
The only way to load Roundcube is to start IE in "InPrivate" mode. This works absolutely flawlessly and raises the question what these session cookies are good for if everything is working without them (or even better than with them).
The only downside of the InPrivate mode is that I have to resize the panes every time I'm loading Roundcube. So these settings are apparently stored in cookies as well...? Surprising.
Any help appreciated.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 22.04.2012 16:36, schrieb Michael Heydekamp:
Am 21.04.2012 23:50, schrieb Reindl Harald:
Am 21.04.2012 23:29, schrieb Michael Heydekamp:
But this still doesn't explain why other web pages of the same domain can't be loaded during this period.
normally this happens only as plong a php-script has a session open - the same client with the same session-id can not make another request until session_write_close() happened in the first script or it is finished
since session-cookies are domainwide this could explain PARTLY the problem
Probably, but if, then indeed only partly:
I also can't load other web pages of the same domain (at least some of them, didn't check with all)
and that describes exactly what i said
if you can open a page on ANOTHER DOMAIN on the same server then it is a open session file which can only be accessed by one connection at the same time
Am 22.04.2012 16:52, schrieb Reindl Harald:
Am 22.04.2012 16:36, schrieb Michael Heydekamp:
Am 21.04.2012 23:50, schrieb Reindl Harald:
normally this happens only as plong a php-script has a session open - the same client with the same session-id can not make another request until session_write_close() happened in the first script or it is finished
since session-cookies are domainwide this could explain PARTLY the problem
Probably, but if, then indeed only partly:
I also can't load other web pages of the same domain (at least some of them, didn't check with all)
and that describes exactly what i said
You deleted the more important part of the quote, as it is only a side issue, that I can't load other web pages of the same domain - more important to me is that I can't load Roundcube at all (and why I ran into this situation at all).
But just for my understanding (I'm not an expert in this area as you may see, sorry):
If you're saying that an still open session is the problem (see above) - will this session stay open forever...?
Yesterday it took only 10 mins or so until I could load Roundcube again, now I'm waiting almost 20 hours already.
And if I send the laptop into hibernation, wake it up again hours later, open a new browser tab - does this session then still have the same session ID as the one hours before? Sounds pretty unlikely to me.
if you can open a page on ANOTHER DOMAIN on the same server then it is a open session file which can only be accessed by one connection at the same time
Hmm. I'm not sure I get you right, but why can I open Roundcube then in the InPrivate mode of IE8? Because it's a new browser session (= a new browser window)?
This might indeed be the case, as I just realize if I open a new browser window (in standard mode, NOT in InPrivate mode), I can load Roundcube there as well.
So how can I get this apparently still open session get closed? Shouldn't it close automatically after some time (session_lifetime in main.inc.php)?
Am 22.04.2012 18:58, schrieb Michael Heydekamp:
Am 22.04.2012 16:52, schrieb Reindl Harald:
Am 22.04.2012 16:36, schrieb Michael Heydekamp:
Am 21.04.2012 23:50, schrieb Reindl Harald:
normally this happens only as plong a php-script has a session open - the same client with the same session-id can not make another request until session_write_close() happened in the first script or it is finished
since session-cookies are domainwide this could explain PARTLY the problem
Probably, but if, then indeed only partly:
I also can't load other web pages of the same domain (at least some of them, didn't check with all)
and that describes exactly what i said
You deleted the more important part of the quote, as it is only a side issue, that I can't load other web pages of the same domain - more important to me is that I can't load Roundcube at all (and why I ran into this situation at all).
becaue what i said
if there is some active session with a script running forever on the server this is the symptom - but usuaully this should not happen
If you're saying that an still open session is the problem (see above) - will this session stay open forever...?
Yesterday it took only 10 mins or so until I could load Roundcube again, now I'm waiting almost 20 hours already.
10 minutes is normal 20 hours is not normal, but on the other hand if there are ajax requests hanging around it is not impossible
And if I send the laptop into hibernation, wake it up again hours later, open a new browser tab - does this session then still have the same session ID as the one hours before? Sounds pretty unlikely to me.
no, the session on the server should have timeouted
if you can open a page on ANOTHER DOMAIN on the same server then it is a open session file which can only be accessed by one connection at the same time
Hmm. I'm not sure I get you right, but why can I open Roundcube then in the InPrivate mode of IE8? Because it's a new browser session (= a new browser window)?
session != browser window
session is at least a id sent via cookie switching to "private mode" will stp sending this cookie
This might indeed be the case, as I just realize if I open a new browser window (in standard mode, NOT in InPrivate mode), I can load Roundcube there as well.
internet explorer is a beast years ago as i used windows a saw IMSIE with different windows having different sessions affecting in some weird error cases even popups from web applications with all sort of wondering effects
So how can I get this apparently still open session get closed? Shouldn't it close automatically after some time (session_lifetime in main.inc.php)?
yes and no
if there is some ajax thing speaking in backround with the server it could keep alive the session on both sides - difficulty to debug and it makes me scary because i am webdevloper, but we advise our customers to not use MSIE since years because many hard to explain troubles
Am 22.04.2012 19:14, schrieb Reindl Harald:
Am 22.04.2012 18:58, schrieb Michael Heydekamp:
You deleted the more important part of the quote, as it is only a side issue, that I can't load other web pages of the same domain - more important to me is that I can't load Roundcube at all (and why I ran into this situation at all).
becaue what i said
if there is some active session with a script running forever on the server this is the symptom - but usuaully this should not happen
The situation I was talking about and which I ran into is that RC gets stuck and unusable pretty often after sending a message. That I can't load it afterwards again, is "just" a successive problem, but obviously connected to the previous one.
The initial problem may probably have been caused by this User-Agent issue (see other thread), but I'm not sure. It sounded a bit as if it were IE9 specific, but again: not sure.
And if I send the laptop into hibernation, wake it up again hours later, open a new browser tab - does this session then still have the same session ID as the one hours before? Sounds pretty unlikely to me.
no, the session on the server should have timeouted
Right, that's what I thought and why I doubt that my specific and current problem is connected to a still open session.
I'm pretty sure that if I would close the instance of IE which has the problem of not being able to load Roundcube, then the problem is gone - till next time. My impression is that it must have to do with temp files, cookies or whatever on my local machine.
Hmm. I'm not sure I get you right, but why can I open Roundcube then in the InPrivate mode of IE8? Because it's a new browser session (= a new browser window)?
session != browser window
Ok. There is a menu item "Neue Sitzung" (= new session), that's why I thought it may have to do with it.
And because: As a matter of fact, I can currently load Roundcube in a new window/session/instance of IE (be it InPrivate or not), but not in a new tab of the same (first) IE window/session/instance.
session is at least a id sent via cookie switching to "private mode" will stp sending this cookie
And that has exactly which consequences?
Surprisingly, InPrivate mode currently seems to be the only mode in which I can run Roundcube without these kind of problems at all. At least I haven't seen any such yet, even not after sending messages.
And this arises the question: What's this session and cookie thingy all about, if RC is running perfectly without them (except that the pane sizes are not saved)?
internet explorer is a beast years ago as i used windows a saw IMSIE with different windows having different sessions affecting in some weird error cases even popups from web applications with all sort of wondering effects
Well, IE "years ago" has to be contemplated differently to IE8/9 (which you will know a lot better than me).
Anyway, a sophisticated application such as Roundcube is for sure not meant to be one of those "best viewed with browser xyz".
What's really and still puzzling me, is that I haven't seen any of those problems with Squirrel for years (also under IE). And I really and finally would like to get rid of it.
Am 22.04.2012 20:00, schrieb Michael Heydekamp:
session != browser window
Ok. There is a menu item "Neue Sitzung" (= new session), that's why I thought it may have to do with it.
depends on the point of view and implementation in MSIE6 it was really a new session after MSIE6 i switched completly to linux
in all other browsers if you open a new window it is simply a new window but having all session cookie
in the world of browser/webservr/web-application a session is defined by a session cookie and some storage on the server (in case of PHp normally the session-file) with the depending server side data identified by the session ID which is usually sent via cookie or in unsecure applications even via GET (PHPSESSID param)
And because: As a matter of fact, I can currently load Roundcube in a new window/session/instance of IE (be it InPrivate or not), but not in a new tab of the same (first) IE window/session/instance.
yes because as said MSIE tends to trhow away existing session cookies if you start a new window
session is at least a id sent via cookie switching to "private mode" will stp sending this cookie
And that has exactly which consequences?
that if a script called with a ession-cookie doing start_session() in php is locking the session-file on disk until the script has finished or sessin_write_close()
this means as example if you are seinding a large file with fpassthru() and did session_start() and not session_write_close() before starting send data EACH connection from the same cient to a script which calls session_start() has to wait until the previous one has finished his operations (the download in example)
you can notice this also in framesets all using php-sripts with start-session() - if you are doing session_write_close() as soon as possible from the point where you are sure that you do not need write any session variable all frames will appear much faster
Surprisingly, InPrivate mode currently seems to be the only mode in which I can run Roundcube without these kind of problems at all. At least I haven't seen any such yet, even not after sending messages.
maybe it does not braindead switch the user-agent
as far as i understood the html-editor for message-coompose seems to trigger a user-agent change in some cases - if this is true the component has a major bug
And this arises the question: What's this session and cookie thingy all about, if RC is running perfectly without them (except that the pane sizes are not saved)?
it does NOT work without them
without them you would have to enter your userdata for each request - you can not write any application with login without sessions
the private mode is also accepting session cookies but it seems not to change stupidity his user agent
as far as i understand someone has to patch the html-editor shipped with roundcube and the problem may go away!
Well, IE "years ago" has to be contemplated differently to IE8/9 (which you will know a lot better than me).
things got better but MSIE is still bullshit
Anyway, a sophisticated application such as Roundcube is for sure not meant to be one of those "best viewed with browser xyz".
true
What's really and still puzzling me, is that I haven't seen any of those problems with Squirrel for years (also under IE). And I really and finally would like to get rid of it.
it scares me too because we are about replacing horde currently
Am 22.04.2012 20:15, schrieb Reindl Harald:
Am 22.04.2012 20:00, schrieb Michael Heydekamp:
Thanks for all the in-depth explanations.
the private mode is also accepting session cookies but it seems not to change stupidity his user agent
For now it's just an assumption that the problems I'm seeing are related to the User-Agent header.
And if you're saying...
as far as i understand someone has to patch the html-editor shipped with roundcube and the problem may go away!
...then this assumption must be wrong as I did never compose any HTML messages at all. So if the User-Agent header issue should be related to the HTML editor only, then it must be something else that makes RC unusable/stuck that often after sending a message (with IE only?).
Also here I should note again that we have the compose_newwindow plugin 3.00 installed and activated. No idea, if this might be part of the issue.
But given the fact that the InPrivate mode of IE did not make the symptom appear yet, we (or more the core devs) should turn their focus in this direction.
Am 22.04.2012 20:46, schrieb Michael Heydekamp:
Am 22.04.2012 20:15, schrieb Reindl Harald:
Am 22.04.2012 20:00, schrieb Michael Heydekamp:
Thanks for all the in-depth explanations.
no problem, it's my job and sometimes i like to help others understand partly, sometimes not :-)
So if the User-Agent header issue should be related to the HTML editor only
i have not looked deeper nor got any complaint now that roundcube has any problem in our setup
but since users often do not say a single word and way too late come up with "since 6 months problem xyz.." i was a little alarmed and liked to give some possible hints
but only guessing this time
Also here I should note again that we have the compose_newwindow plugin 3.00 installed and activated. No idea, if this might be part of the issue.
if you have the option to disable this it would be a good idea yeah plugins generally can do any damage
But given the fact that the InPrivate mode of IE did not make the symptom appear yet, we (or more the core devs) should turn their focus in this direction.
this might be only what you see but not the root cause
maybe wahtever problem is only triggered in context of MSIE because i know not a single other browser changing it's useragent and until two days ago i was even not aware taht MSIE does this in some situations because doing tis in the client is braindead
protecting sessions from hijacking by remember the user-agent at start and abort each request with the same session ID and a different user-agent is common sense and some implementations are also including the client IP
but - using the client IP is braindead these days seeing imap users on mobile devices chaging their IP all day long and kill them the web-application because they switched the mobile-cell is not a good idea
Am 22.04.2012 20:46, schrieb Michael Heydekamp:
Am 22.04.2012 20:15, schrieb Reindl Harald:
For now it's just an assumption that the problems I'm seeing are related to the User-Agent header.
And if you're saying...
as far as i understand someone has to patch the html-editor shipped with roundcube and the problem may go away!
...then this assumption must be wrong as I did never compose any HTML messages at all. So if the User-Agent header issue should be related to the HTML editor only, then it must be something else that makes RC unusable/stuck that often after sending a message (with IE only?).
Also here I should note again that we have the compose_newwindow plugin 3.00 installed and activated. No idea, if this might be part of the issue.
But given the fact that the InPrivate mode of IE did not make the symptom appear yet, we (or more the core devs) should turn their focus in this direction.
Ok, now we can forget about this theory as well. Right after sending the message above, I encountered the same problem also in IE's InPrivate mode: Message sent (in new window), clicked on INBOX folder, RC stuck (endless spinning wheel, missing buttons, RC doesn't react to anything, see screenshot attachment some messages ago).
Closed the IE window, opened a new one, could login into RC normally.
I'm prepared to see this scenario again pretty soon.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 22.04.2012 20:54, schrieb Reindl Harald:
Am 22.04.2012 20:46, schrieb Michael Heydekamp:
Also here I should note again that we have the compose_newwindow plugin 3.00 installed and activated. No idea, if this might be part of the issue.
if you have the option to disable this it would be a good idea yeah plugins generally can do any damage
Sure, I can disable it any minute (the option is user-configurable anyway, but I can also disable the plugin completely), but as I'm also heavily USING Roundcube myself, it's a bit inconvenient as I need to have access to my message base while composing a message (looking things up here and there).
But well, I can also read the message in a new window and reply from there
- dunno if that will make a difference, but at least the plugin would be
disabled then. Ok, will try that.
But given the fact that the InPrivate mode of IE did not make the symptom appear yet, we (or more the core devs) should turn their focus in this direction.
this might be only what you see but not the root cause
See my previous message - as the problem did now appear after my latest post in IE's InPrivate mode as well, we have to drop this theory anyway.
Apparently I was somehow mislead by the fact that I could load RC in InPrivate mode, but not in a new tab of the initial IE window/session/instance. But the reason that I could load it in InPrivate mode was not the mode itself, but just the fact that a new window/session/instance of IE was started.
protecting sessions from hijacking by remember the user-agent at start and abort each request with the same session ID and a different user-agent is common sense and some implementations are also including the client IP
Didn't know that. But how can a different user on a different machine have the same session ID (if not by random)? Is there any way to a) get hold of the ID of any other user's session, and b) to take influence on his own session ID in a way that he would identify himself with the same ID?
but - using the client IP is braindead these days seeing imap users on mobile devices chaging their IP all day long and kill them the web-application because they switched the mobile-cell is not a good idea
Right.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 22.04.2012 21:38, schrieb Michael Heydekamp:
protecting sessions from hijacking by remember the user-agent
at start and abort each request with the same session ID and a different user-agent is common sense and some implementations are also including the client IP
Didn't know that. But how can a different user on a different machine have the same session ID (if not by random)? Is there any way to a) get hold of the ID of any other user's session, and b) to take influence on his own session ID in a way that he would identify himself with the same ID?
what do you think how long it takes to write a cookie like this? the only interesting is "roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905"
beeing in a open WLAN without ssl and anybody can fake it in seconds
Cookie: mailviewsplitterv=244; mailviewsplitter=262; composesplitterv=175; prefsviewsplitter=195; folderviewsplitter=300; addressviewsplitter=250; addressviewsplitterd=200; identviewsplitter=300; tl_webmail_sessid=vpxiRqxOLDa%2CM7gMP81eB2hPPc1; roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905
Am 22.04.2012 21:49, schrieb Reindl Harald:
Am 22.04.2012 21:38, schrieb Michael Heydekamp:
Didn't know that. But how can a different user on a different machine have the same session ID (if not by random)? Is there any way to a) get hold of the ID of any other user's session, and b) to take influence on his own session ID in a way that he would identify himself with the same ID?
what do you think how long it takes to write a cookie like this? the only interesting is "roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905"
beeing in a open WLAN without ssl and anybody can fake it in seconds
Ok, typing it is not a big deal, but how can he get hold of the ID of any user in the same WLAN within seconds?
And: If he can do that, isn't faking the User-Agent even an easier deal?
Cookie: mailviewsplitterv=244; mailviewsplitter=262; composesplitterv=175; prefsviewsplitter=195; folderviewsplitter=300; addressviewsplitter=250; addressviewsplitterd=200; identviewsplitter=300; tl_webmail_sessid=vpxiRqxOLDa%2CM7gMP81eB2hPPc1; roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905
This looks as if the pane sizes (= splitters) would indeed be saved in a simple cookie. That explains why they sometimes get lost here. Is there no way to save them permanently (machine-specific, of course)? Could be a database entry connected to the NIC, IMHO.
Am 22.04.2012 22:06, schrieb Michael Heydekamp:
Am 22.04.2012 21:49, schrieb Reindl Harald:
Am 22.04.2012 21:38, schrieb Michael Heydekamp:
Didn't know that. But how can a different user on a different machine have the same session ID (if not by random)? Is there any way to a) get hold of the ID of any other user's session, and b) to take influence on his own session ID in a way that he would identify himself with the same ID?
what do you think how long it takes to write a cookie like this? the only interesting is "roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905"
beeing in a open WLAN without ssl and anybody can fake it in seconds
Ok, typing it is not a big deal, but how can he get hold of the ID of any user in the same WLAN within seconds?
jesus christ you simply start the hijacked session in your browser - the session is nothing other than sending this header with each reequest
And: If he can do that, isn't faking the User-Agent even an easier deal?
yes, but he must fake BOTH at the same time it's both easy, 100% security does not exist you can things only make as difficult as possible without encryption
Cookie: mailviewsplitterv=244; mailviewsplitter=262; composesplitterv=175; prefsviewsplitter=195; folderviewsplitter=300; addressviewsplitter=250; addressviewsplitterd=200; identviewsplitter=300; tl_webmail_sessid=vpxiRqxOLDa%2CM7gMP81eB2hPPc1; roundcube_sessauth=S1168d2474c3b543053461d00f9c8b1a1b1764905
Am 22.04.2012 20:54, schrieb Reindl Harald:
protecting sessions from hijacking by remember the user-agent at start and abort each request with the same session ID and a different user-agent is common sense and some implementations are also including the client IP
but - using the client IP is braindead these days seeing imap users on mobile devices chaging their IP all day long and kill them the web-application because they switched the mobile-cell is not a good idea
Probably you've hit a point here:
Just for testing purposes, I just killed the WLAN connection and established a new connection with my Vodafone stick (while RC still being loaded in IE8):
It didn't take long until RC was again unusable/stuck - same scenario as can be seen in the screenshot some messages ago. Didn't have the patience to wait for any error messages.
Could login in a new IE window/instance/session without any problems, though.
So is RC using the client IP...?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Addition to the post below: With Squirrel, such scenarios are not a problem at all. It just continues to do it's job.
Can we have the same with RC - pleeeze?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 23.04.2012 01:15, schrieb Michael Heydekamp:
Am 22.04.2012 20:54, schrieb Reindl Harald:
protecting sessions from hijacking by remember the user-agent at start and abort each request with the same session ID and a different user-agent is common sense and some implementations are also including the client IP
but - using the client IP is braindead these days seeing imap users on mobile devices chaging their IP all day long and kill them the web-application because they switched the mobile-cell is not a good idea
Probably you've hit a point here:
Just for testing purposes, I just killed the WLAN connection and established a new connection with my Vodafone stick (while RC still being loaded in IE8):
It didn't take long until RC was again unusable/stuck - same scenario as can be seen in the screenshot some messages ago. Didn't have the patience to wait for any error messages.
Could login in a new IE window/instance/session without any problems, though.
So is RC using the client IP...?
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 23.04.2012 01:15, Michael Heydekamp wrote:
but - using the client IP is braindead these days seeing imap users on mobile devices chaging their IP all day long and kill them the web-application because they switched the mobile-cell is not a good idea
Probably you've hit a point here:
Just for testing purposes, I just killed the WLAN connection and established a new connection with my Vodafone stick (while RC still being loaded in IE8):
It didn't take long until RC was again unusable/stuck - same scenario as can be seen in the screenshot some messages ago. Didn't have the patience to wait for any error messages.
Could login in a new IE window/instance/session without any problems, though.
So is RC using the client IP...?
Yes. Check if you have ip_check option enabled in Roundcube config. If so, it can be some incarnation of this bug http://trac.roundcube.net/ticket/1488056 and you should update to r6049 or just disable this setting. This of course might be not the same, but IP change may confuse IE browser (I wouldn't be surprised).
Am 23.04.2012 08:21, schrieb A.L.E.C:
On 23.04.2012 01:15, Michael Heydekamp wrote:
[...]
So is RC using the client IP...?
Yes. Check if you have ip_check option enabled in Roundcube config.
I'd have been happy to confirm that we've enabled it, but no: It's set to false (which is the default, looking at main.inc.php.dist). Damn.
If so, it can be some incarnation of this bug http://trac.roundcube.net/ticket/1488056 and you should update to r6049 or just disable this setting. This of course might be not the same, but IP change may confuse IE browser (I wouldn't be surprised).
And no again, IP changes don't confuse IE (at least not IE7/8). I often drove home from my restaurant (just a few minutes away), woke the laptop up from hibernation, esatblished a new connection and could continue reading/composing messages even without logging in again (if I was fast enough). Well, that was with Squirrel, though...
-
A.L.E.C -
Arne Berglund -
Michael Heydekamp -
Michael Orlitzky -
Reindl Harald