[TYPO3-core] RFC: Bug 5704: IRRE - Children on the table pages get the pid of the parent page in pagetree

[Oliver Hader]

Hi Franz,

Franz Holzinger schrieb:
> Hello Oliver,
>>> if (t3lib_div::testInt($this->inlineFirstPid)) {
>>> Add here a check to the pid field of the current record.
>>> $calcPRec = t3lib_BEfunc::getRecord('pages', $this->inlineFirstPid);
>>> Check the parent record. And if he has no permissions for the parent
>>> record then nothing shall continue from here.
>>
>> Yes, and exactly this insn't possible, because the pid of the new child
>> record is "NEW12345678" in this case an cannot be checked. The creation
>> of new child records is done via AJAX call. The only possibility would
>> be to forward also the data of the parent record with each AJAX call
>> concerning only child records.
> 
> I think a child record will always be created on the same page as the
> parent record. Or is it possible to put the child records on different
> pages than the parent record?
> Maybe it would be fine to provide the uid of the parent table and the
> parent table's name as a parameter for the client record. Then the pid
> could be fetched from the database. The pid must already be inside of
> the parent record.

In this special case we are creating a new page and new children on that
new page. Thus we have the following secenario:
1) Record of 'pages' {uid:13, pid:0}
2) Record of 'pages' {uid:NEWa12345, pid:13}
3) Record of 'tx_myext_child' {uid:NEWe56789, pid:NEW12345}

The inline TCEform for the 'tx_myext_child' record will be rendered with
the following AJAX call (this is standard in IRRE, nothing new):
typo3/alt_doc_ajax.php?ajax[0]=createNewRecord&ajax[1]=data[NEW12345][pages][NEWa12345][children][tx_myext_child]

The identifier given by the parameter "ajax[1]" tells TCEforms_inline
which child record to create for which parent record, the BNF is:
<irre-ident>    ::= 'data[' <pid> ']' <level-ident> { <level-ident> }
                    [ <level-role> | <partial-ident> ]
<level-ident>   ::= '[' <tablename> '][' <uid> '][' <field> ']'
<level-role>    ::= '_records'
<partial-ident> ::= '[' <tablename> '][' <uid> ']' <partial-role>
<partial-role>  ::= '_' ( 'div' | 'header' | 'label' |
                          'disabled' | 'fields' )

Thus, it's known that the new child record should get the pid
"NEW12345". But, this record of the table 'pages' isn't saved yet and
cannot be checked.
The table you suggested to check is in this case the grand parent
(pages:13). If we would now use also the uid of the grand parent for the
check, it would be nice, but won't prevent from calling the AJAX handler
directly with a grand parent the user has access to. Thus, it's still
possible to get the result of TCEforms for the new child record and
you're suggestion would have had no effect.

The only way to avoid this is to integrate a new table, e.g.
'unsaved_records' which could have the following data:
{table:'pages', uid:'NEW12345', be_user:10}
TCEforms will determine if the non-integer pid that is requested to be
used for the new child record is set in the 'unsaved_records' table.
Furthermore it has the be ensured that records on the table will be
cleared after a given time period or when the unsaved record was finally
correctly saved.

>> In exactly this case, the check will be done by TCEmain. If the parent
>> (here a new record on the table pages) could not be create, because of
>> missing access rights, the child records won't be stored because the pid
>> with the value "NEW12345678" could not be substituted by a proper
>> integer.
> This could be avoided if the pid would have been read from the parent
> record. The child records should be put on the current page in the
> backend, or not?

So what could happen if this check isn't done in this special case (new
child record on a new unsaved page record)? The back-end user could send
directly a HTTP POST request to alt_doc_ajax.php and will get an empty
form for a child record...

If the back-end user doesn't have access to edit the table with the
child records at all, the will be nothing rendered. This also means,
that if the back-end user has access to the child table, he can look at
the rendered forms on any other page he has access to.

Furthermore, nothing is saved in this situation because we're still
talking about TCEforms! And it is possible for every back-end user to
call alt_doc.php with a data array in HTTP POST directly. TCEmain has to
handle this - there is nothing TCEforms/TCEforms_inline can do against.

*Result:*
If the TYPO3 back-end is used in the normal way (just using the back-end
user interface) there is nothing bad that happens during editing. If a
back-end user tries to forge queries and sends requests directly to
alt_doc.php or alt_doc_ajax.php he might only see an empty input form -
provided that he has access to the table he is trying to forge. If he
doesn't have access to that table, he'll see nothing. Fine!
If the back-end user tries to modify/save data he has no access to, this
is caught by TCEmain. And this patch doesn't tocuh TCEmain at all!

So, if you still have objections please share them and it would be real
great if a solution could be provided then with a new patch! Thanks!


olly
-- 
Oliver Hader
http://inpublica.de/