Bug #63931: Manipulating the id parameter leads to 503 error - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #63931

closed

Manipulating the id parameter leads to 503 error

Added by Marco Zanter over 9 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Frontend

Target version:

Start date:

2014-12-16

Due date:

% Done:

Estimated time:

TYPO3 Version:

6.2

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

I.e. http://typo3.org/index.php?id=.22

Locally testet with 6.2.9 and id=.79 shows the following strange error:

#1294587217: The page is not configured! [type=79][]. This means that there is no TypoScript object of type PAGE with typeNum=79 configured.

This issue should better leads to an 404 response.

Actions

Copy link

Updated by Mathias Schreiber over 9 years ago

Status changed from New to Needs Feedback

Hi Marco,

in general the Exception is correct here.
See, this is what happens:
Having a . in the ID will instruct TYPO3 to use the part after the . as the type of the page.

Let's take your example:
id=79 translates to: "Show me the Page with the uid 79"
id=79.22 translates to "Show me the Page with the uid 79 in type 22"
id=.22 translates to "Show me the first Page for this domain in type 22"

So you see, 404 is indeed wrong here, because the page itself is there, the type is not defined (which is a server error, thus 500).

You can easily adapt the ExceptionHandler to catch these Exceptions and give the user a 404, if that is the behavior you desire.

If this helped you with your problem, just give me a short note and as always: feel free to discuss things.

Cheers
Mathias

Actions

Copy link

Updated by Marco Zanter over 9 years ago

Thanks for your fast answer.
I don't know nothing about this "magic dot logic" for the id parameter ;-)
That makes things clear for me.

But we have already the type parameter.
Why is this mixed up with the id parameter ?

Actions

Copy link

Updated by Mathias Schreiber over 9 years ago

Marco Zanter wrote:

Thanks for your fast answer.

Well, it took a little longer this time. Sorry about that

I don't know nothing about this "magic dot logic" for the id parameter ;-)
That makes things clear for me.

But we have already the type parameter.
Why is this mixed up with the id parameter ?

That is what I'd call legacy :)
Back in the days Kasper built the function this way.
While I agree that in general this is "unexpected behavior" (to say the least :)) I think that most sites nowadays run with something like realURL enabled.
So I don't think we will touch this too soon.

Without any offense meant.. may I close the issue?
I try to get forge into a manageable size :)

Actions

Copy link