Project

General

Profile

Actions

Bug #55307

closed

Undefined error message -> [newlog()] Attempt to delete records from disallowed tables

Added by d.ros no-lastname-given almost 11 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2014-01-24
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Reproducability:

  • create page as admin
  • put a TS Template on that page
  • push all possible rights to a certain usergroup
  • give groupaccess with all flags to that group
  • login as groupuser and try to delete the page

does not work. Error message appears -> [newlog()] Attempt to delete records from disallowed tables

  • You must delete the TS Setup from that page as Admin. Then the usergroup can delete the page

Expected Behaviour

  • Give an error message that is understandable.

Files

Schermata 2017-03-18 alle 17.31.13.png (18.8 KB) Schermata 2017-03-18 alle 17.31.13.png Riccardo De Contardi, 2017-03-18 17:33

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #15204: In some cases BE users unable to delete pagesClosedSebastian Kurfuerst2005-11-15

Actions
Actions #1

Updated by Markus Klein almost 11 years ago

@Sec-Team: Would it be ok to display the table name that failed here?

Actions #2

Updated by Martin Terber over 10 years ago

Also happens in 4.5.33.
Is there any workaround?

Actions #3

Updated by Riccardo De Contardi over 9 years ago

  • TYPO3 Version changed from 6.1 to 6.2

The bug is also present in 6.2.12

The error message is:

Exception
[1.0.-1]: [newlog()] Attempt to delete records from disallowed tables

I can understand what happened, but is somehow cryptic: what does "[1.0.-1]: [newlog()]" mean?

Adding the table of the forbidden record could be a good suggestion.

Actions #4

Updated by Riccardo De Contardi about 9 years ago

still present on 7.6-dev (latest master) with the same error message

Actions #5

Updated by Mathias Schreiber about 9 years ago

  • Target version deleted (6.2.0)
Actions #6

Updated by Wiebke Lauke about 8 years ago

Still present in TYPO3 6.2.25. Access rights ok and group rights are set for deleting. Editors cannot delete pages below a specific page. All rights for editing are set. Just admins can delete.

Actions #7

Updated by Helmut Hummel almost 8 years ago

Markus Klein wrote:

@Sec-Team: Would it be ok to display the table name that failed here?

Sure it would be ok. But Imho the der facing message should not contain the table name but some hint to contact an admin
and maybe a time. in the log the table (and/or any other useful info) should be listed

Actions #8

Updated by Markus Günther almost 8 years ago

Hi,

had the same issue today and after some investigation time, I just figured out that the error message is just incomplete.
People think that they have all permissions on the user and group for the page and so the user should be able to delete the page.

BUT sub records can also be a problem. And TYPO3 is also checking the permissions of subtrees and sub records on the page. The user maybe don`t see the record that is breaking
the expected behavior.

So the real problem is that TYPO3 is not responding with a good error message. If the user gets a message like 'You are not permitted to delete the records of table "foo". '
It will be much easier to understand for integrators, whats going wrong.

I am not sure if the code will be changed when the DataHandler gets overhaul. So maybe it is not needed to add a patch here because the core team will overhaul the datahandler at all.

Actions #9

Updated by Markus Günther almost 8 years ago

@helmut But deletePages() does not log informations like tablename and so on. Only the error message that will be returned from canDeletePage(), which is a string, will be saved to the log.

So this is maybe the point for a patch. But I would prefer a correct error message with table name as well.

Actions #10

Updated by Riccardo De Contardi over 7 years ago

Tested again on both 7.6.16 and 8.7-dev (latest master) On both cases the error message is the one shown on the attached file

Actions #13

Updated by Susanne Moog over 4 years ago

  • Category changed from Backend User Interface to DataHandler aka TCEmain

This happens in datahandler:

        if (!$this->checkForRecordsFromDisallowedTables($pagesInBranch)) {
            return 'Attempt to delete records from disallowed tables';
        }

Problem is, that we already return false on the first disallowed table. To show all disallowed tables that check would need to be adjusted (which might have performance implications).

Actions #14

Updated by Gerrit Code Review over 4 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65175

Actions #15

Updated by Gerrit Code Review over 4 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65175

Actions #16

Updated by Gerrit Code Review over 4 years ago

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65165

Actions #17

Updated by Benni Mack over 4 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #18

Updated by Sybille Peters about 4 years ago

  • Related to Bug #15204: In some cases BE users unable to delete pages added
Actions #19

Updated by Sybille Peters about 4 years ago

Is there any chance to get this fixed for 9.5?

Actions #20

Updated by Benni Mack about 4 years ago

  • Status changed from Resolved to Closed
Actions #21

Updated by limeflavour almost 4 years ago

I just added the code change to a v8.7 - it worked there too and I found out why the message appeared in the first place. Maybe someone finds this helpful to fix the permissions configuration.

So should be working in v9.5 also.

Actions

Also available in: Atom PDF