Hello,
I’ve a problem with typo3 backend, some element used the bparams “|” but this character is forbidden for the standard “RFC 1738”, so our server don’t permit to used this character in url and I’ve an error “You don’t have permission to access this resource.”
Do you have an idea how I can changed the character “|” by the encoding “%7C” ?
Thx for your reply
You should avoid the “|” character in all names as it nearly everywhere has a special meaning. So don’t try to encode it properly but remove the origin of the need.
In TYPO3 the “|” is used as separator in wraps in typoscript. Maybe one of this wraps has gone weird and the wrap char is rendered instead of replaced by content. (you could redefine the wrap separation char)
Hello,
Thx for your reply.
Problem is not for typoscript url generation but directly on url typo3 core.
Please elaborate how the URL is generated and why it’s necessary to include the pipe char in the URL.
I suspect you misinterpreted the syntax for multidimensional array indexes: (manual)
lib.foo.data = TSFE : fe_user|user|username
in PHP means:
$TSFE->fe_user['user']['username']
or with GETparams: (manual)
lib.foo.data = GP : stuff|bar
means:
$_GP['stuff']['bar'] in PHP and ...?stuff[bar]=xyz in URL
no need for a | in the URL
Hello,
Problem is not on how I generate url but it’s directly on the typo3 generation.
Typo3 make a request like :
bparams=|||gif,jpg,jpeg,tif,tiff,bmp,pcx,tga,png,pdf,ai,svg|data-1-tt_content-1-image-sys_file_reference
When I try to open upload images popup
That looks very much like an error.
Maybe a configuration is misplaced (shift in parameters?).
Or the encoding has failed.
If that URL is generated by the core you should open a bug report. (https://forge.typo3.org)
With an example how you got that bad URL.
Even this post is quite old, it’s still relevant in TYPO3 v13.
When I open the Modal for browsing files in the backend, I get a URL like this:
/typo3/wizard/record/browse?token=93740c22813ef9f8938ab3082f302c3a037345d1&mode=file&bparams=%7C%7C%7Callowed%3Dgif%2Cjpg%2Cjpeg%2Ctif%2Ctiff%2Cbmp%2Cpcx%2Ctga%2Cpng%2Cpdf%2Cai%2Csvg%2Cwebp%2Cavif%7Edisallowed%3D%7Cdata-42-tt_content-231-image-sys_file_reference
The last part, translates to this when URL encoded signs are decoded:
&bparams=|||allowed=gif,jpg,jpeg,tif,tiff,bmp,pcx,tga,png,pdf,ai,svg,webp,avif~disallowed=|data-42-tt_content-231-image-sys_file_reference
So there are indeed pipe-signs used in the URL.
Currently I’m searching what these signs are separating and what they can be used for.
@skidoo as you can see, in TYPO3 v13 the signs are url-encoded already, and I suppose you’ve never to take care of the problem with the server anymore.
@piphi For a quick overview I searched for bparams, in an older TYPO3 Version (v10) though, but fundmentally it should be almost the same in current versions:
URLs for the backend filebrowser are using the parameter pbparams for configuration of the file-browser. pbparams is followed by several details that are separated by pipe-signs (|), those are url-encoded to avoid problems with browsers and URL-specifications.
The class FileBrowser.php is using the pipe-signs to explode (= separate) the different configuration parts and using the indexes 3 and 4 of the resulting array:
result[3] = $allowedFileExtensions
result[4] = combination of $pid, $table, $field, separated by -
The class DatabaseBrowser.php is using the following parts:
result[0] = $fieldPointerString
result[3] = $allowedTables
The ElementBrowser is using these parts:
[$fieldRef, $rteParams, $rteConfig, , $irreObjectId]
Hi! @david_bruchmann1!
Thank you for pointing out that this issue still seems to be present in TYPO3 v13. Did you open an issue on forge.typo3.org regarding this or do you know of an existing issue?
I recommend opening an issue if it doesn’t exist.
Feel free to post a link to the issue here and reference this thread in the issue. Then we have references both ways.
Hey @mabolek ,
as the pipe characters are encoded I don’t see that it’s an issue.
Reason of my post was to clarify that @skidoo wasn’t generally wrong, like @piphi wrote in other words. It was rather him who hadn’t enough knowledge to answer the question appropriate.
If anyone still has on issue even the characters are encoded, it would indeed be interesting to add here – beside creating an according ticket.
Thank you for the clarification.
I think everyone here are trying to contribute answers to the best of their ability. 
