cf login wrapper to secure non-cf content (html, pdf, flv, swf)

[BrienMalone]

I have a large amount of html, pdf, swf, flv content that I am trying to protect on a coldfusion/IIS server. The content is generated by a non-technical department using a product called FlashForm. I am trying to avoid making extensive technical revisions to the code FlashForm produces because I will have to repeat my changes every time they edit the content.

Is there some way that I serve html and flash files under the protection of a coldfusion login wrapper?

I have been in google for hours researching the problem. Most people point to a product called iAuth by coolfusion.com, but the coolfusion website is a ghost town. The download links all point to one file (the wrong one) and email to support@coolfusion.com and info@coolfusion.com bounce... If coolfusion isn't dead, they are certainly circling the drain.

(Running CF MX7, IIS 6 and Helicon ISAPI Rewrite 3.0)

[mack_]

Rewrite all requests for html and flash files to go through a

ColdFusion file behind the scene. In that CF file check if the user is

authenticated, if not direct him to the login page. If the user is

authenticated serve the file using CFCONTENT (and the appropriate mime

type headers).

Mack

[BrienMalone]

Thanks Mack --

I've seen that mentioned a few times, too. I've used CFCONTENT to force a download of a file rather than using the browser's handlers, but I haven't really gone beyond that.

A quick google led me to this blog that had some useful example code:

http://www.leeftpaulnog.nl/2009/05/serving-html-files-with-cfcontent-using.html

Paul is serving HTML content through CFCONTENT using the character set specified in the HTML. I don't need to worry about that sort of thing.

Stripping his code down to what I would need, it becomes:

<cfset variables.filepath = "c:\bla.html" />
<!---use as default charset --->
<cfset contentType_str = "text/html;charset=utf-8" />
<!--- now output the contents.--->
<cfcontent type="#contentType_str#" reset="yes" file="#variables.filepath#" />

The idea is that the content (variables.filepath) exists outside of the web root and is called by the page, right?

Two things concern me. First, this content can be very large (50mb+), and I have heard that using CFCONTENT in this way can lock a thread until the content is served completely. Second, the html file uses an embed tag with a relative path to reach the SWF... and the SWF uses relative paths to load additional SWFs and other content. I'm pretty sure just delivering the HTML in this way will break links to those relative paths.

I'll put together some proof of concept work and post again when I have more info.

Thanks again for the jump start.

--B

[ilssac]

Just to guide you a bit on your exploration.  The relative paths inside the HTML file you serve up with the <cfcontent...> method will not care where the HTML file is read from by ColdFusion.  They will care where the browser thinks the file came from, which would be the URL of the CFML file.  So as long as the relative paths to the SWF files are correct from this location, all will work because it is the browser that resolves the path and requests the SWF from the path.

But since it is request the SWF files directly by name, ColdFusion would not be invloved in returning those files to the browser in a normal configuration.  To use a similar technique as you are experiementing with to serve up HTML, these embeded SWF objects in the HTML would have to be coded to request CFML files that would then work the same was as this HTML version does.  But, it sounds like this may not be a good solution for your requirements as the personal developing these HTML and SWF files would need to understand how to do that.

You could possible use somekind of URL rewrite functionality that intercepts these requests and changes them at the web server level so that they actually request a CFML file, not the SWF or HTML file actually requested.

You could also possible configure ColdFusion to process HTML and SWF files.  Then you would not need to necessarily use the <cfcontent...> process, but could just use normal Application.cfm|cfc logic to process permissions before serving the files.

HTH

Ian

[BrienMalone]

Thanks Ian. I 've got Helicon ISAPI Rewrite. Capturing and rerouting SWF and PDF requests was kind of what I had in mind...

Your last paragraph was interesting, though... How would I reconfigure the web server to send HTML and SWF through coldfusion? Would I add an application extension for .htm, .html and .swf in IIS that runs <CF>\runtime\lib\wsconfig\jrun_iis6.dll, or is there some other way?

[ilssac]

That's the rough idea.  I think there is a bit more to it, something that also has to be set in the ColdFusion web.xml file or something like that.

I've seen many step-by-step walk throughs all over the inter-webs.  A Google search should find many a good one.

Ian

[Chuck_ers]

> I've seen many step-by-step walk throughs all over the inter-webs.

I can't seem to find any more direction from Google on getting Application.cfm to run before a non-cf file is served.  It may be I'm just not searching right, but I tried everything I could think of.  Can you provide a link to one of the walk-throughs?

Thanks!

-Chuck

[ilssac · Accepted solution]

http://www.revolutionwebdesign.com/blog/index.cfm/2009/4/29/htmhtml-file-parsing-by-ColdFusion-8

That seems to be a pretty good blog on the configuraitons required to make ColdFusion server other file types.

Then anything that ColdFusion serves will have the Applicaiton.cfm|Applicaiton.cfc file run before the request.

[Chuck_ers]

OK, I see.  Thanks for the quick response!

Maybe my situation is different than the original poster's.  I would like to serve up PDFs to logged in users.  The process described in your link not only has the Application.cfm file run before serving the file, but also has ColdFusion parse the body of the PDF file looking for ColdFusion code.  Occasionally it will find something in the binary stream that it chokes on, so this won't work for me.

The reason I didn't want to use cfcontent was I was hoping to piggyback on IIS's already-implemented method for byteserving large PDF files (honoring "range" http requests with a Partial Content 206 response).  I suspect the Application.cfm method wouldn't achieve that anyway, even if I could make it work at all, which so far I haven't been able to.

Thanks again!

-Chuck

[ilssac]

Are you sure the <cfcontent...> solution does not work for you?

I have never bothered with this byteserving feature in IIS so I do not know.  But I do not see why using a ColdFusion <cfcontent...> tag would affect this one way or the other.  But hey, there are lots of things I don't know, so maybe it is true.

[Chuck_ers]

No, cfcontent doesn't do any of the "extra" headers that IIS (or Apache, or Netscape server, etc.) do.

Here's the response headers from cfcontent:

HTTP/1.x 200 OK
Connection: close
Date: Thu, 17 Sep 2009 19:16:09 GMT
Server: Microsoft-IIS/6.0
Content-Type: application/pdf

In contrast, here's IIS's headers (Apache's are more or less the same, though I don't remember if "Content-Location" was included, and I think it gzip compresses it by default, too iirc):

HTTP/1.x 200 OK
Content-Length: 17342226
Content-Type: application/pdf
Content-Location: http://portal.ers.org/content/657/5101%20Acceleration,%20Elementary%20Students.pdf
Last-Modified: Thu, 12 Mar 2009 15:51:55 GMT
Accept-Ranges: bytes
Etag: "bc7c8772aa3c91:2593"
Server: Microsoft-IIS/6.0
Date: Thu, 17 Sep 2009 19:21:42 GMT

Content-length, last-modified,  and etag are all easy enough to do yourself (the first lets the browser know how long it's going to take to download, the other two allow caching; all three make the process much more responsive for the web visitor).  But Accept-Ranges (aka byteserving, partial content 206, etc.) is just a touch harder to code yourself, since it will prompt the browser to drop the current connection and initiate another one (which starts the CFM template page all over of course) once the browser and PDF plugin have gotten enough info to know which byte range it needs first in order to show the first page of the PDF.

For long PDFs, being able to show the first (or any arbitrary) page before the whole document is downloaded can make a huge difference in user-perceived responsiveness of the site.  I believe flash movies can work this way, too.  Try skipping ahead on any Youtube video and that's probably what's happening (I've never coded those so I don't know for sure, but probably).  Byteserving also allows download pausing and resuming.  Not too relevant for my current application, but it's nice sometimes.

When I did similar things in perl and PHP awhile back, I found several explanations of how the process works on the web and sample code to make it happen.  Since ColdFusion and Acrobat are both Adobe now (and Adobe was the original push behind getting byteserving in common use 15 years ago), I thought perhaps they might have made it easier in ColdFusion, but they have not.  There are "servlets" for compression and cache-control headers, but (because it would require multiple connections which a simple servlet can't manage), there's nothing for byteserving, and surprisingly no one seems even to be talking about it in regards to ColdFusion.

Interestingly, some of the "open source" CFML implementations have an additional attribute for cfcontent which supposedly you can use to achieve byteserving (I think it's "ranges" or something like that; I've never used any of them), but not the Adobe product.

Thanks anyway, though.

-Chuck

[-__cfSearching__-]

... ColdFusion server other file types.

One thing to keep in mind if you are considering this technique is security implications. Especially if the site allows uploads or handles files from untrusted sources. Since CF will be handling the file types, the server may execute any cfml code contained within those files.  Potentially allowing unauthorized users to run any cfml code they wish on the server.  (Granted some file types are easier to hack than others).  While this is hardly a new issue, it is something to keep in mind.