Project

General

Profile

Actions

Bug #104190

open

restrict "Unsafe captching group regex"-message to only used replacements

Added by Mordamir 5 months ago. Updated 13 days ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Link Handling & Redirect Handling
Target version:
-
Start date:
2024-06-24
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
13
PHP Version:
Tags:
Complexity:
no-brainer
Is Regression:
Sprint Focus:

Description

Currently the replaceRegExpCaptureGroup function inside the RedirectService is generating a warning message for every capture group which contains a question mark.

The problem is, that this message is generated for every captured group, even if it is not used. Especially for capturing group zero, which always contains the whole matched string.

Alternatives:
- throw away match zero (unset $matches0) (is it allowed to use $0 in the target url?)
- check if replacement string is used (does the target url contain a $0 placeholder?)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #102176: Missing error suppression for preg_match in RedirectServiceClosed2023-10-16

Actions
Actions #1

Updated by Garvin Hicking 5 months ago

  • Related to Bug #102176: Missing error suppression for preg_match in RedirectService added
Actions #2

Updated by Garvin Hicking 5 months ago

  • Status changed from New to Needs Feedback

I think https://review.typo3.org/c/Packages/TYPO3.CMS/+/84872 is related to this and probably will soon be merged; does this solve your issue?

Thanks for your report!

Actions #3

Updated by Mordamir 5 months ago

No, this is a different problem. Its not about suppressing errors from wrong preg-expressions.

It is about the match zero value from the preg_match-function, which always contains the question mark if the redirect has the "Respect GET Parameters"-flag set. If the target url does not contain a $0-placeholder, the redirectService should not write the "Unsafe captching group regex..."-warning in the log file.

Actions #4

Updated by Garvin Hicking 5 months ago

Actually the other patch would suppress all preg_match errors, not only from "wrong" ones.
But thank you for the reply, will try to reproduce and analyze

Actions #5

Updated by Stefan Bürk 14 days ago

@Mordamir Can you provide some example ?

The used regexp string and the url/request matching that request but triggering the error ? (one or two examples) ?

Actions #6

Updated by Mordamir 13 days ago

As Source Path

#^/partner\?tx_extension_clients.+client(?:%5D|\])=([A-Z0-9]+)#

And as Target
/partner/$1

Its mainly to redirect some old urls (example.com/partner?tx_extension_clients[controller]=Clients&tx_extension_clients[client]=ACME1) to the new shorter form of (example.com/partner/ACME1

Actions

Also available in: Atom PDF