Dear Roundcube users
We're proud to announce the second service release to update the stable version 1.0 of Roundcube webmail. It contains some bug fixes and improvements we considered important for the long term support branch of Roundcube. See the full changelog here: http://trac.roundcube.net/wiki/Changelog
It's considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from http://roundcube.net/download.
Please do backup before updating!
Kind regards, Thomas
Trying to understand the new "security" rules in .htaccess
- deny access to files not containing a dot or starting with a dot
# in all locations except installer directory
RewriteRule ^(?!installer)(.?[^.]+)$ - [F]
This doesn't quite make sense, we have a help/ directory, which is not accessible because of this rule yet all files in that directory are foo.img or index.php, bar.php
change to
RewriteRule ^(?!(installer|help))(.?[^.]+)$ - [F] permits our help/ directory to be read, this is sub optimum because it will be overwrite at next update again, does someone with good knowledge of rewrite rules able to shed some light on this?
On 2014-07-21 07:45, Thomas Bruederli wrote:
We're proud to announce the second service release to update the stable version 1.0 of Roundcube webmail.
We upgraded from Roundcube 0.9.5 to 1.0.2 yesterday. Our helpdesk reports a steady trickle of reports of problems from people running Safari on MacOS and Mobile Safari on iPads and iPhones.
Experiments suggest that it has something to do with "Private Browsing" which is implemented by both Safari and Mobile Safari.
This is true of a completely vanilla Roundcube 1.0.2 installation: it isn't a consequence of any change that we have made locally.
Roundcube 1.0 uses Javascript local storage (http://hacks.mozilla.org/2009/06/localstorage/) to store some state on the client computer/device. I think that the original idea which to store draft messages. However it looks like preferences are also stored there.
All well and good, but Safari "Private Browsing" appears to disable local storage.
The Javascript code provided by Roundcube 1.0.2 throws an exception in line 7731 of app.js
this.local_storage_set_item = function(key, data, encrypted) { // TODO: add encryption return localStorage.setItem(this.get_local_storage_prefix() + key, JSON.stringify(data)); };
which is a consequence of the following in skins/larry/ui.js :
// write prefs to local storage
if (window.localStorage) {
rcmail.local_storage_set_item('prefs.larry', prefs);
}
The exception is:
QuotaExceededError: DOM Exception 22: An attempt was made to add something to storage that exceeded the quota.
and this stops Roundcube working at all.
Is this expected behaviour?
I was a little surprised that I couldn't find any tickets in the Roundcube bugtraq, although I suspect that this explains:
http://trac.roundcube.net/ticket/1489901
as this precisely describes the symptoms I see.
I'm happy to write up a ticket if this is something which can be fixed, but thought that I should ask here first.
On 07/23/2014 10:55 AM, David Carter wrote:
All well and good, but Safari "Private Browsing" appears to disable local storage.
// write prefs to local storage if (window.localStorage) { rcmail.local_storage_set_item('prefs.larry', prefs); }
Google confirms this, window.localStorage exists, but writing to it fails. We'd need to use better feature detection, e.g.:
try { localStorage.setItem('test', 'test'); localStorage.removeItem('test'); return true; } catch(e) { return false; }
Please, create a ticket.
On 07/23/2014 11:07 AM, A.L.E.C wrote:
Please, create a ticket.
As you pointed the ticket already exists. No need for another one, sorry.
On 2014-07-23 10:29, A.L.E.C wrote:
On 07/23/2014 11:07 AM, A.L.E.C wrote:
Please, create a ticket.
As you pointed the ticket already exists. No need for another one, sorry.
Too late:
http://trac.roundcube.net/ticket/1489996
Oh well, the tickets can always be merged or deleted.
Thanks for the quick response.
bump
On 7/22/14, Nick Edwards nick.z.edwards@gmail.com wrote:
Trying to understand the new "security" rules in .htaccess
- deny access to files not containing a dot or starting with a dot
# in all locations except installer directory
RewriteRule ^(?!installer)(.?[^.]+)$ - [F]
This doesn't quite make sense, we have a help/ directory, which is not accessible because of this rule yet all files in that directory are foo.img or index.php, bar.php
change to
RewriteRule ^(?!(installer|help))(.?[^.]+)$ - [F] permits our help/ directory to be read, this is sub optimum because it will be overwrite at next update again, does someone with good knowledge of rewrite rules able to shed some light on this?
-
A.L.E.C -
David Carter -
Nick Edwards -
Thomas Bruederli