On Mon, May 27, 2013 at 2:20 PM, till <[email protected]> wrote: > > On Sunday, May 26, 2013 at 5:59 PM, Thomas Bruederli wrote: > > Hello! > > I'm trying to ignore all the rants and personal accusations and get > back to the a constructive conversation about a technical problem. > First, let's start a new thread since it has actually nothing to do > with the 0.9.1 update. > > Second, there are reasons that Roundcube comes with a custom session > handler and those are still valid. We didn't do this just for fun, > believe me! > > The main reason are concurrent http request which alter session data. > Image the following scenario: > > A) [r]----------- big file being uploaded ------------[w] > B) [r]----- fast upload ----[w] > > In PHP, session data is read when the process starts and written when > the process ends. With the scenario from above, the session changes of > request B) would be lost when A) finishes. > > I'm not a 100% sure I understand the example.
OK, here's another try. Imagine the following steps in chronological order: Request A) read session data on start => $_SESSION['A'] == undefined => $_SESSION['B'] == undefined Request B) read session data on start => $_SESSION['A'] == undefined => $_SESSION['B'] == undefined Request B) $_SESSION['B'] = 'B'; writes session data when process ends => $_SESSION['A'] == undefined => $_SESSION['B'] == 'B' Request A) $_SESSION['A'] = 'A'; writes session data when process ends => $_SESSION['A'] = 'A' => $_SESSION['B'] == undefined Observed result: the entry 'B' in $_SESSION is lost after request A) wrote the session data because A) applied the changes to an outdated version of $_SESSION. > Can point out where this issue bubbles up in RoundCube? It's a race condition that isn't simple to reproduce. > > I just haven't heard of this issue either. But I'd like to understand. > > It doesn't sound like databasing the sessions would be a solution either if > one process wipes out another process' data. I never said that using the database solves the issue. The main problem persists no matter what backend we would use. > > Until now I don't know of > any solution with default PHP session handlers that would be able to > handle such a case properly. Another more performance related reason > for you custom handler is the check if session data actually changed > before issuing a (useless) update query. > > Sure, we could store file upload information somewhere else than in > session but the underlying problem of concurrent requests overlapping > each others still persists and can happen in other cases, too. > > As far as I understand, what happens in a request, stays in a request. I > don't see how one request would override another. It's not about two requests overriding each others memory but two requests reading and writing the same block of session data (either on disk or in the database). > > The backend shouldn't matter. Databased sessions can have some advantages as > they make scaling infrastructure easier but of course they could be > considered overhead in a single-server setup. Scalability was the main idea behind choosing the database to store session data. And since Roundcube requires a database connection anyway I don't see why this should be an overhead compared to file-based session storage. > > I think the backend (file storage, database, memcache, redis) etc. should > not have an impact unless we delete all data and re-save it every time. But > anyway, let me know if you can explain this in more details. As said, it's not mainly a backend issue here. What exactly do you want me to explain. > > > On Wed, May 22, 2013 at 9:00 PM, till <[email protected]> wrote: > > I agree that session handling could be nicer in RoundCube — or maybe not at > all. ;-) If we wouldn't have customized session handling code we could let > people configure PHP directly to use the filesystem, memcache or database. I > think the least we could (or should) do is use an external library for > session handling because that doesn't seem our domain (which is an email > client). > > Not sure if we could use something from Symfony2 or ZF2. They each provide > wrappers — PHP 5.3, et all. Are people ready to move/upgrade yet? > > > We're open for suggestions to get rid of the custom session handlers > but please keep the above scenario in mind. Switching to an external > library might be a solution but don't they use custom save handlers, > too? > > They do — but RoundCube's session handling does something else which makes > it incompatible with Suhosin. And it would be very interesting to find out what we do wrong or different. The API for registering session save handlers is rather simple and I can't find anything we could change or improve when reading the docs again and again. ~Thomas _______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
