Re: [Kolab-devel] Roundcube CSRF Patch and assets path

I've created a fix/patch proposal for the CSRF patch. It's documented 
and attached to this bug report:
https://issues.kolab.org/show_bug.cgi?id=3608

If someone would cross check this and approve it I would update the CSRF 
Patch in OBS. Feel free to forward this patch to the original source.

In the same moment I would suggest that the default 
$config['assets_path'] provided by pykolab should be 'assets/' and not 
'/roundcubemail/assets/' or whatever.

--
Regards
Daniel

------ Originalnachricht ------
Von: "Daniel Hoffend" <[email protected]>
An: "Kolab development coordination" <[email protected]>
Gesendet: 15.09.2014 12:24:16
Betreff: [Kolab-devel] Roundcube CSRF Patch and assets path

>I'm currently seeing problems with the CSRF Patch and the asset path 
>configuration option.
>
>The CSRF Patch introduced the $config['assets_path'] variable to 
>correctly link to css, scripts and images.
>
>Currently the pykolab package suggests to configure the assets_path to 
>'/roundcubemail/assets/'. But this results in URLs generated like this 
>(in the html code).
>http://kolab.example.org/roundcubemail/roundcubemail/assets/<something>
>
>When I set the assets_path to '/assets/' then the urls are expended to 
>hostname/roundcubemail/assets/... and everything seems to work fine. 
>But IMHO this is a very fundamental problem. An URL starting with a "/" 
>sounds to be like an absolute URL. An absolute URL shouldn't be 
>expended with the base directory. If I want to have a relative URL I 
>would configure 'assets/' and not '/assets/';
>
>btw. I don't see a Problem in the Apache Configuration. The Apache Conf 
>and the rewrites needed for the CSRF patch and support of old plugins 
>are working fine. I don't see any need to included rewrites that should 
>fix double'd assets paths like /roundcubemail/roundcubemail/ ...
>
>IMO i see 3 options
>
>1) Use /assets/ again as assets_path in the setup-kolab templates and 
>ignore the fact that /assets/ is not an absolute url.
>2) Use asset/ as assets_path (which seems to work but doesn't fix the 
>leading / problem)
>3) fix the CSRF patch that an assets_path with leading / does not get 
>the url expanded
>
>
>--
>Regards
>Daniel Hoffend