Problems with CFIMAGE writetobrowser

[WolfShade]

Hello, all,

I've got a problem with CFIMAGE that I could use some wisdom with.

We have a page that has a query that pulls article data from a content table and it uses a LEFT OUTER JOIN to pull media (pic or video) from a media table.

When displaying the article, if there is an associated image we insert the BLOB into an ImageNew() tag, resize it, and then display it.  Except it's not displaying.  We just get the ALT content.  Inspecting the source via browser, I can see where the CF generated IMG tag is, but there's no picture.

<cfoutput query="getarticlesbyyear">
...
     <cfif photoID neq "">
          <cfset myImage = imageNew("#thumbnail#") />
          <cfset imageResize(myImage,"150","","bilinear",2) />
          <cfimage action="writetobrowser" source="#myImage#" title="#caption#" alt="#caption#" />
     </cfif>
...
</cfoutput>

This will display in View Source:

<img src="/CFFileServlet/_cf_image/_cfimg7233696009169197587.PNG" alt="{REDACTED}" title="{REDACTED}">

Any thoughts on why this isn't working greatly appreciated.

V/r,

^ _ ^

[WolfShade]

In a normal corporate environment, or personal dev environment, that will work.  But this is DoD, and the STIG has security settings so high that we can't use CFIMAGE.  At all.  For anything.  So, I unfortunately have to use hack-ish methods to get things done.  (I call it hack-ish, not that I'm hacking anything.)

V/r,

^ _ ^

[Charlie Arehart]

That sounds curious. I mean, cfimage can do a lot of things that I can’t see all being related to possible security issues.

More important, I don’t see any mention of anything related to “image” at all (the tag or functions or just that term) in the online STIG:

https://www.stigviewer.com/stig/adobe_coldfusion_11/

Is what you’re being told about the details of some one there? If so, which one. This is just interesting to hear about, and you seem firm in your conviction about it. Then again, sometimes people are told things by folks they work with and they accept those as facts. If this may help you press the case and find a better solution for your need, then perhaps my asking this will have helped you.

/charlie

PS Can you tell us how you prefer us to refer to you? I am always torn about whether to address you as “wolf” or “wolfshade” or “ws” or I’d use your name if it was shown, but I know some people prefer not to show their names in their profile (such that appears on each reply, like mine does). If you shared it, I would try to remember it, but I will understand if you prefer not to share it here. Apologies if you’ve told me before and I have just forgotten.

[WolfShade]

Hi, Charlie, always good to see you online.

Yes, I am blaming the STIG without _FULL_ knowledge of everything involved, but I've been here long enough that it would not surprise me one bit if the STIG is responsible.

But there are so many layers of security that I am not familiar with that any of them could be the culprit.  It could be a CF security setting, or it could be the security of just about any stack layer involved.  I only just recently learned that our security is as thick, wide, and tall as it is because we are the most targeted organization within DoD.  So it really doesn't come as a surprise.

I've been here long enough that when stuff like this happens, I just count to ten, let out a soft sigh, and start to figure out a workaround, because there's nothing I can do to change it.  As the old addage goes, "It is what it is."  The PTB are an unmovable object, and I am not an unstoppable force.

As far as referring/addressing me, I don't really have a preference.  Wolf, WolfShade, ws, it's all good.  And, yes, for a variety of reasons, not the least of which is because I am a federal contractor, I prefer to remain as anonymous as possible.

V/r,

^ _ ^

[Dave Watts]

I think you may well be safe to blame the STIG! My recommended workaround would be for you to mimic the functionality of CFIMAGE WRITETOBROWSER by writing the image to a temporary location on your filesystem, serving it as a static file, then deleting the image a while later, maybe through a scheduled task.

Dave Watts, Fig Leaf Software

[BKBK]

A hack:

you could bag the contents into files, then continue from there.

<cfquery name="getImageAsBinary" datasource="cf_db">

select image

from imagetable1

</cfquery>

<cfquery name="getImageAsBase64" datasource="cf_db">

select image

from imagetable2

</cfquery>

<cfset fileWrite(expandpath('myImage1.png'),getImageAsBinary.image)>

<img src="myImage1.png" alt="Image1">

<cfset fileWrite(expandpath('myImage2.png'),BinaryDecode(getImageAsBase64.image,"base64"))>

<img src="myImage2.png" alt="Image2">

[WolfShade · Accepted solution]

Dave Watts​ and BKBK, thank you guys for taking the time, but what both of you are suggesting would be a lot of disk I/O.

While not thrilled with using <img src="data:image/*;base64,{blob}" />, it works.  I feel as though I've spent too much time, already, on getting CFIMAGE to work in an environment that the PTB aren't willing to allow.  So, I'm just going to move on to the next item.

Thank you to everyone who used brain power and made decent suggestions.  I do truly appreciate all the wisdom.

V/r,

^ _ ^

[asif34378787]

hy everyone,

i am also encountering same problem, but i think the reason of this error is CF is installed in another drive of which drive the site is placed in. As for me on Dev server it was working fine because both site and CF was installed in same directory. But on Prod it stopped working because of different directories.

/CFFileServlet is a folder in CF temp where it save the image for 5 minutes. so i need to access this folder while writing. but i am not sure how to set it in configurations

Any idea would be appreciated.

Thanks

[WolfShade]

As I understand it, /CFFileServlet is not a physical path, but rather something that exists in RAM, so there are no settings or sandbox options for it.  We, too, have installed CF on a different partition, so maybe that's the issue.  But as hackish as my solution is, it works.

V/r,

^ _ ^

[Charlie Arehart]

Well, it's a servlet mapping. And cf uses a combination of mechanisms to serve and manage them which are not well-defined/documented.

To @asif who resurrected this thread, what exactly is the "same" for you, regarding wolf's original post? Maybe there's a solution for you while there was none for him, due to his security needs. I don't expect yours are the same, just this desire to run with cf and your site on different drives.

Honestly, the drive location for your site should have nothing to do with the drive for cf. As long as your web server knows about and is authorized to access what it needs in CF, and vice versa, the drives being different shouldn't matter for any cf processing, let alone cf image processing.

I think you'd do better to state what is failing, and maybe the solution will be unrelated to all the above.