Htmlawed crashes when Editor popup open longer than a few minutes
Htmlawed crashes when Editor popup open longer than a few minutes
When I create a new record using the Editor popup, and I keep the popup open for longer than a couple of minutes before saving, Htmlawed crashes when I try to save.
In Htmlawed.php it is this line that causes the crash. It seems to be passed an array which it apparently doesn't get passed when I save more quickly.
What can I do to fix this. I am using Editor 2.0.7
$t = explode('<', $t);
Fatal error
Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/HtmLawed/Htmlawed.php:189
Stack trace:
#0 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/HtmLawed/Htmlawed.php(189): explode()
#1 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/HtmLawed/Htmlawed.php(110): DataTables\HtmLawed\Htmlawed::hl_bal()
#2 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/HtmLawed/Htmlaw.php(82): DataTables\HtmLawed\Htmlawed::hl()
#3 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/Editor/Field.php(792): DataTables\HtmLawed\Htmlaw::filter()
#4 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/Editor/Field.php(681): DataTables\Editor\Field->xssSafety()
#5 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/Editor.php(1203): DataTables\Editor\Field->val()
#6 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/Editor.php(1031): DataTables\Editor->_insert()
#7 /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/Editor.php(701): DataTables\Editor->_process()
#8 /var/www/vhosts/lgfinance.eu/public_html/php/datatables/tblSubReg.php(992): DataTables\Editor->process()
#9 /var/www/vhosts/lgfinance.eu/public_html/actions.php(1708): tblSubReg()
#10 {main}
thrown in /var/www/vhosts/lgfinance.eu/public_html/DataTables/Editor-PHP/lib/HtmLawed/Htmlawed.php
on line 189
This question has accepted answers - jump to:
Answers
I'm not sure why the amount of time that the modal is open for would make any difference to the Ajax request that is being sent?
It might be worth updating the Htmlawed.php file with the content from here to see if that helps? It has moved on a few versions since the one I included in Editor 2.0.7.
Allan
Ok, will try that, Allan.
My preliminary fix is this one
Hi Allan,
tried the new version and guess what: It crashes immediately, don't need to keep the modal open long, at exactly the same point which this time is in line 391:
I'll try to figure this out with my debugger and will get back here.
HTMLawed gets passed this array which makes it crash:
This is the field in the client side Editor instance:
The field gets cleared and re-added on Editor "open" because it is not possible to update the options for a selectize field (I wrote about that before):
And this is the relevant part in PHP:
@allan, what do you think? What causes this issue?
Some more detail ... as you can see above I don't update "ctr_has_ctr" in the Field instance for "ctr_has_ctr". This is how I do it:
I use the raw() method to delete the existing links and reinsert new ones using Editor's insert() method. I would guess that the insert() method calls HTMLawed with an array instead of a string and hence causes the issue.
Is that so, Allan? I am only guessing
Actually no, HtmlLawed is only invoked by the
Field
class.Can you show me the HTTP parameters and values that are being submitted please?
Also, do you have a
Field
instance that refers tolinked_ctr_id
in its name?Allan
no, there is none. Only what I posted above.
I did this with my fix above implemented. So it didn't crash this time.
The values:
The headers:
General:
Request Headers:
Its a weird one! It has got to be that
data[0][ctr_has_ctr]
is being passed as a field somewhere and Htmlawed is tripping over that array.Could you perhaps email me the full PHP file? allan at this domain.
Thanks,
Allan
Will send you the file.
Just took a look at my debugger again. The $values parameter on "writeEdit" or "writeCreate" looks fine:
And what arrives from the server looks perfectly fine as well.
Could this cause the problem? (see the full code above). This field instance returns the above.
Many thanks for the file!
There is something peculiar going on - the backtrace makes it appear that it is this line which triggering the XSS formatting, that results in the failure. But your
ctr_has_ctr
field has->set(false)
. I don't recall any errors in 2.0.x which would result in a non-settable field being set!Is your debugger able to say what
$field->name()
is at that point immediately before the error? (Perhaps even just an echo statement might do).I have thought of a workaround (assuming it is that field which is failing) - add
->xss(false)
to it to bypass the Htmlawed stuff.Thanks,
Allan
The data you highlight is what is causing the issue - Editor is not expecting an array for the field value. Even if we resolve why it is being used on line 1203, there are a couple of other places that it might be needed, so that isn't a complete solution.
I could put a condition on the XSS function to see if it is given an array, but if I did, I'd want to throw an error since it is unexpected input and the result is undefined (currently an error!).
I'm thinking that
->xss(false)
is the correct way to handle this error you are seeing.Allan
Thanks for that Allan! Guess what I found in a different file for a different business solution that contains the exact same field linking contracts to eachother and vice versa. I ran into this issue years ago - and didn't remember it. Sorry.
I don't really understand my own comment, but anyway
Why should this have anything to do with "copy & new"? In the other solution it also crashed when I just did "New", not "copy & new". In fact I don't have "copy & new" in the other solution because it is much too complex. So the copying is done on the server.
This is the "copy & new" button I mentioned above:
Possibly different words for "duplicate" and "create" (which is what I tend to use for Editor - but either would work)? The second line of the comment is bob on though!
Glad to hear you got it working!
Allan
Hi Allan,
I still don't understand why the problem occurs here and not in other cases. Should HTMLawed be called at all in this case? I mean the field is "->set( false )"? Why is it called for a field that will not be set?
Could it be that HTMLawed is only called because I use Editor's db handler for the query? In most cases I use my own and have a function that returns the value. Never had any problem here for example:
As you can see here I am using this very often and only twice it causes issues:
Roland
Not for the main set - which is where the backtrace is happening, and I'm not sure why that is happening. I would need to be able to replicate the issue and debug it. I've made a note to look into it when I get a chance.
However, there are two other parts of the code which it could legitimately attempt to get the value, and that would trigger the XSS routine. So even if I did resolve the other one, then it could still happen under certain circumstances.
I think the key is that an array should not be passed as a field value, unless the field has a formatter that converts it in some way.
Allan
Well, I don't see me passing an array to the server. If I take a look at the server submission above. And I double checked it right now. Something else must pass the array to the XSS routine ... I am not calling it anywhere.
is it not?
Allan
I looked at those as individual strings ... Maybe I am wrong.
But: It is exactly the same as here:
And those are Editor Mjoins and have never caused any issues
Maybe you can figure this out some time when you get bored . Probably never going to happen. The only difference I can tell is that "id" gets passed instead of "linked_ctr_id". Is there an "exception" for "id"?
That one is okay because it is an Mjoin. Editor is expecting an array there and will handle it correctly.
The
ctr_has_ctr
field though is just a top level field, and it isn't expecting an array there - hence the error.Allan
Then there is no solution for this except to turn XSS off, I guess. Mjoin isn't flexible enough for me often times. In many cases I have a more complex data structure than an Mjoin could handle.
Agreed. The fields just aren't expecting an array - there are a number of things that would need to change for such a case. The closest thing to a "fix" in the short term would be to throw an error message saying that a field doesn't support arrays. If this crops up again I'll look at adding that in.
Allan
Ok, Allan but please allow to mitigate this by turning XSS off. Otherwise I'd be having a problem.
And finally I understand why the situation is different compared with my other "pseudo"-Mjoins: This one does send data back to the server, the others don't: They are only sending data in "Mjoin"-format from the server to the client. Nothing's sent back!
If you look at my post above that has the "writeCreate" and "writeEdit" in it, you see how I process the "ctr_has_ctr"-values coming from the client. (function processCtrLinkedContracts).
Learned something today
Yup, if I ever did throw an error for such a case, it would likely be the same place as where the current unhandled error is. So the
->xss(false)
current workaround would continue to work.Allan