Problem with Coldfusion 7.0.1, IIS6.0 and Perl

[Guest]

Hi,

I have somewhat of a wierd problem that I am unable to figure out. We
are running a coldfusion 7.0.1 application server

We are also using a custom built perl program which does authentication
on some of our pages and read/writes a cookie.

Following is an example of a URL that would redirect the user to the
perl script login screen, authenticate and send the user back to the
requested page specified in the URL

https://127.0.0.1/cgi/bluestem/lb_login.pl/cf/index.cfm

This URL will redirect the user to the path /cf/index.cfm after the
authentication by the perl program.

My problem is that the above URL used to work fine with Coldfusion 6.1
and IIS 5.0 and it also worked fine with Coldfusion 7.0.1 and IIS 5.0
but when I try doing this with IIS 6.0, it throws a missing template
error. I did some investigation and found out that instead of executing the Perl file, it is trying to find the CF file on the location /cgi/bluestem/lb_login.pl/cf/index.cfm which ofcourse, does not exist.

The most interesting thing is that this URL is the same thing as above but it works!

https://127.0.0.1/cgi/bluestem/lb_login.pl/cf/

It seems that the problem happens when there is a .pl and a .cfm extension in the URL.

Any ideas?

[primalx2003]

It is weird.. It should not work at all because IIS 6.0 works totally different now.

Instead of them making it better, it is worse off.

This is what it is seeing:
https://127.0.0.1/cgi/bluestem/lb_login.pl/cf/index.cfm

cgi ---- a folder >>> within the cgi folder >> it should find another folder called bluestem >>>> within this folder, another folder called lb_login.pl >>>> then another folder called cf >>>> finally the file index.cfm.

But that's not the case. What you need to do is run the lb_login.pl script first then within the script pass all the variables redirecting them to the index.cfm.

So it should look something like this within your lb_login.pl script >>>>> redirect to https://127.0.0.1/cgi/cf/index.cfm?variable1=a&variable2=b&variable3=c

This should work fine.

Hope it helps.

Sevor Klu

[wrmckinn]

Is this the definitive and final solution to this? I'm having the exact ame issue. The same coldfusion application works fine on two different Win2K servers, both IIS 5.0 One with CF5.0 and one MX. 6.0. Our new box is Win2K3, IIS 6.0, and CF MX 7.0 and it burps EXACTLY as has been described in this thread. So is it really IIS 6.0, MX7.0, or the combination of the two? Seems like a giant step backwards.

[Guest · Accepted solution]

I have found the solution to this problem. I have all my perl scripts in a virtual directory. That virtual directory does not have any Coldfusion files. What I did was that in IIS 6.0, I right click the virtual directory and go to properties. From there, I click configuration. You will see a "Wildcard application maps (order of implementation)" section here. There will be only one entry in it, something like C:\JRun4\lib\wsconfig\1\jrun_iis6_wildcard.dll.

This wildcard mapping should be removed for the perl scripts to redirect to the correct page. Removing this wildcard mapping will also remove the capability of executing ColdFusion templates in this virtual directory.

[wrmckinn]

ah..interesting. I found an alternate solution that works for us at least
Our authentication is called from a file called bluestemcookie.cfm with this format
<cflocation url="https://#CGI.HTTP_HOST#/bluestem/lb_login.pl#AGREEMENT_PATH##CGI.SCRIPT_NAME#" addtoken="No">

I was having the exact same problem, but notiece that if I changed lb_login.pl to lb_login.pl? it now understood that everything after was parameters and off it went to authenticate. Of course then upon return I had a /? in my url and it burped again. In looking at the construction of the URL to return in lb_login.pl

#---Construct Return URL------------------------------------
$ReturnURL = "https://$bluestem'R_ServerNamePort";
$ReturnURL .= $bluestem'R_PathInfo;
$ReturnURL .= "?$ENV{'QUERY_STRING'}" if $ENV{'QUERY_STRING'};

I noticed the ? in the beginning fo the third string concatenation. hmm.... removed that ? and now all our authentication with IIS6 CFMX7.1 Win2K3 work fine. Just food for thought as your solution appears to be better.