Jump to content

"Allow HTML" in not fully functional for the editor / tag getting replaced by <span>


Recommended Posts

Posted

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 🙂

 

Posted

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.

Posted

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!

 

Posted
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/

Posted

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.

❤️

Posted

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.

🙂 

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...