[TYPO3-core] JumpUrl restructuring

[Alexander Stehlik]

I got some feedback from Helmut Hummel in Gerrit:

 > Thanks for your work on this.
 >
 > By roughly looking at it I found some issues which would be easy to
 > resolve.
 >
 > Besides that I'm really not sure if we should do such a refactoring
 > of code for a concept that is inherently broken and (history showed
 > us) dangerous.
 >
 > I would rather (carefully) fix the issues in existing code or create
 > a concept for a new way to solve the features jumpurl (what a bad
 > name anyway) tries to solve.

What does the rest of you think of this feature? What are the 
alternatives? Removing the feature? Rewriting it from scratch?

I can not see how a feature without proper tests should be better than a 
better readable an well tested one (precisely because it had security 
issues in the past).

Another approach I was thinking about was implementing this feature in 
FAL. A SecureLocalDriver could return the path to an eID script in the 
getPublicUrl() method. The script could then check if the user has 
access rights to the file and put out the file contents.

Would be great to hear your opinion on this before putting more 
(senseless?) effort into this.

Cheers,
Alex

Am 26.09.2013 17:09, schrieb Alexander Stehlik:
> Hi Guys,
>
> in the last couple of days I spent some time looking into the jump URL
> feature. Originally I intended to supply a patch for
> http://forge.typo3.org/issues/52156 but I e ended up creating a new
> JumpUrlUtility class for bringing all the JumpUrl functionality in one
> place.
>
> The good thing about this rewrite is, that all places where jump URLs
> can be configured the same options are available. This was not always
> the case in the old integration.
>
> Another issue is tackled with this patch. When creating file links with
> the typoLink method the parameter that was expected needed to be created
> in a very special way so that everything works properly:
>
> str_replace('%2F', '/', $fileUrl);
>
> This is not very convenient. The new version simply expects a
> rawurlencoded version of the file URL which can be called by stdWrap. It
> will also make sure that files with special characters that are linked
> using their FAL UID will work (which is currently not always the case).
>
> I created a bunch of Unit Tests to make sure the system behaves the same
> before and after the patch. You can use the ContentObjectRendererTest
> class to test an unpatched master. The tests will be cleaned so that
> they only work in the patchted version when you are finished testing :)
>
> Would be great to get some feedback and hints for improvements or
> further tests.
>
> Cheers,
> Alex
>