DReffects2 Posted May 30, 2022 Share Posted May 30, 2022 Hey IPS Team, I ran into a bug in reagards to the "Allow HTML" functionallity. Steps to reproduce: place an image tag within the source code editor like this: <img src="123.jpg"> if 123.jpg is not a full URL but a relative one like "/uploads/monthly_2020_01/xyz.jpg" the (fully working!) image tag gets replaced by a <span> upon submitting the form This also happens with (fully functional) base64 encoded images pasted directly into the html source code editor <img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" /> The above html exemple results in this after saving: <span>data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==</span> Please advise on how to circumvent this. Where in the source code is this content-filtering/modifying being done? Thanks 🙂 Link to comment Share on other sites More sharing options...
Jim M Posted May 30, 2022 Share Posted May 30, 2022 Sorry, relative URLs are not supported in the system, it will need to be a full URL. I have tagged a developer to this topic to review the base64. This may be intended as a part of the editor security or simply not supported at this time. Link to comment Share on other sites More sharing options...
DReffects2 Posted May 30, 2022 Author Share Posted May 30, 2022 Thanks for the clarification, this is rather unfortunate. I have a very strong need for base64 images that I need to work out asap. Can you provide me with the location in the code where the <img> tag filtering takes place? If this is not for the public eye please send me a DM 🙂 Thanks! Link to comment Share on other sites More sharing options...
Jim M Posted May 30, 2022 Share Posted May 30, 2022 47 minutes ago, DReffects2 said: Thanks for the clarification, this is rather unfortunate. I have a very strong need for base64 images that I need to work out asap. Can you provide me with the location in the code where the <img> tag filtering takes place? If this is not for the public eye please send me a DM 🙂 Thanks! Sorry, customizations are outside our scope of support. This includes indicating where specific items are in the code. You're more than welcome to post in our Community Support forum for this kind of information to receive help from your fellow administrators and 3rd party developers: https://invisioncommunity.com/forums/forum/406-community-support/ Link to comment Share on other sites More sharing options...
Management Matt Posted May 31, 2022 Management Share Posted May 31, 2022 Unfortunately this is caused by the CKEditor which is the basis of our editor. I'll have a look and see if there's a plug-in or other solution. DReffects2 1 Link to comment Share on other sites More sharing options...
DReffects2 Posted May 31, 2022 Author Share Posted May 31, 2022 Hey Matt, thanks! I was able to figure things out for the moment by modifying (\IPS\Text\Parser::isAllowedImageUrl()) a little bit to enable base64 encoded jpegs and filter out everything else base64 encoded but of course that's a hack. The filtering is really good in preventing harm even from experienced users but I'd like to see a "true" html option where nothing is filtered. For ckeditor the content filter is actually turned off entirely in IPS. ❤️ Matt 1 Link to comment Share on other sites More sharing options...
DReffects2 Posted May 31, 2022 Author Share Posted May 31, 2022 As a follow up here are my modifications: Please be aware that this is rather unsophisticated and not well tested but seems to work at least for my use case 😉 All modifications in in /system/Text/Parser.php Within function "isAllowedImageURL": static public function isAllowedImageUrl( $url ) { /* Mod by DReffects - we want to allow JPEG Base64 encoded Images */ if (base64_decode(str_replace('data:image/jpeg;base64,','',$url),true)==true) { return true; } This immediately returns 'true' if the 'data:image/jpeg;base64' can be removed from the $url string and then decoded by base64_decode in its strict mode. I guess this could be rather resource intensive if someone would post a 20MB jpeg thought 😉 i've come up with a method to compress (any) images during my preprocessing of the content I am adding with base64 encoding directly to the database. The following code snipped could probably be adepted into this function directly if necessary: $jpegquality="60"; #Jpeg Quality for compression $maxwidth="900"; # Rescale Threshold in px width $image = file_get_contents($imageurl); #Convert so space-saving JPEGs $temp = tmpfile(); # temporary image pointer #if too large scale down, otherwise recompress $imagesize=getimagesize($imageurl); if ($imagesize[0]>$maxwidth) imagejpeg(imagescale(imagecreatefromstring($image),$maxwidth),$temp,$jpegquality); else imagejpeg(imagecreatefromstring($image),$temp,$jpegquality); fseek($temp, 0); $image=fread($temp,10485760); #Reads up to 10MB of image return 'data:image/jpeg;base64,'.base64_encode($image); fclose($temp); // dies entfernt die Datei But for acceptance of base64 encoded images in general the above snippet is not necessary. Further down within /system/Text/Parser.php search for the phrase " /* If it's not allowed, remove the src */ " /* If it's not allowed, remove the src */ try { static::isAllowedImageUrl( $element->getAttribute( $srcAttribute ) ); } catch( \UnexpectedValueException $e ) { $newElement = $element->ownerDocument->importNode( new \DOMElement( 'span' ) ); /* mod by DReffects - remove content if it's a base64 non-jpeg image */ if (strpos($newElement,"data:image")!==false) { $newElement->appendChild( new \DOMtext("")); #AUSMERZEN } else { $newElement->appendChild( new \DOMText( $element->getAttribute( $srcAttribute ) ) ); } return $newElement; } This removes the whole "src" content from output. I would prefered this behaviour regardless of my modifictaion becaus if you paste a HTML code into the editor with a rather large image currently the WHOLE base64 code remains as plain text within <span> in the database which a) takes lots of space and b) its a continous string, therefor breaking every layout. 🙂 Link to comment Share on other sites More sharing options...
Recommended Posts