Hi,

I have been wrestling with IIS6 for some time now trying to figure out
my missing link.

I posted a question about 2 weeks ago, and the answer helped me get to
where I am now.

Our dBASE executable files (.DBW extension) were generating 404 Errors
before any Web Service Extensions were added.  For testing purposes, I
changed the default 'Prohibit' setting for 'All Unknown CGI Extensions'
to 'Allow' and the .DBW file executed perfectly.

Just to paint a more complete picture, the .dbw was generated by dBASE
to add records to a simple table and output an HTML result.
All the necessary files were placed into the wwwroot folder of the
Win2K3 web server.  Client browsers then pointed to
http://WEBSERVER/webtest.htm and users enter table data into a form.
This form then does a POST submission to 'webtest.dbw' in the same
wwwroot directory.

I would like to beef up the security by only allowing the dBASE runtime
to be executed.  When I add a web service extension pointing to the
dBASE runtime executable (D:\Program
Files\dBASE\PLUS\Runtime\PLUSRun.exe) and set it to 'Allow' after
restoring all the other CGIs to their default 'Prohibit' setting, I get
the same 404 error.

I'm definitely missing something, but not sure exactly what it could
be.

In the IIS Manager default web site properties, I did map the .dbw
extension to the specific target:
"D:\Program Files\dBASE\PLUS\Runtime\PLUSRun.exe" "%s"

for all verbs as specified in the dBASE web connection documentation.

So my best assumption here is that the .dbw invokes other executables
besides the PLUSRun.exe.  Since they are not listed in this web service
extension, it fails with the 404 error.  This is the only thing that
makes sense to me why this fails, and 'All Unknown CGI Extensions'
works fine.

Is there any way to dig deeper into IIS (log files somewhere?) that
could tell me what other executable files it may be looking for?

Any help would be greatly appreciated.

You can return to prohibit all CGI extensions and allow only the following
CGI extension:

"D:\Program Files\dBASE\PLUS\Runtime\PLUSRun.exe" "%s"

Yes, include the quotes and the %s.  It is because they are missing that
your existing Web Service Extension is not taking effect at all.

Yes, it is a quirky behavior that affects CGI EXE and not ISAPI DLLs because
you can give commandline parameters for EXEs and can affect behavior.

It unfortunately works this way because of security.  IIS doesn't attempt to
parse out the executable name from parameter before calling CreateProcess
since that action itself can potentially introduce a canonicalization issue.
So, you have to enable as Web Service Extension exactly what you gave as
Application mapping.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

news:1108573251.393098.210580@l41g2000cwc.googlegroups.com...
Hi,

I have been wrestling with IIS6 for some time now trying to figure out
my missing link.

I posted a question about 2 weeks ago, and the answer helped me get to
where I am now.

Our dBASE executable files (.DBW extension) were generating 404 Errors
before any Web Service Extensions were added.  For testing purposes, I
changed the default 'Prohibit' setting for 'All Unknown CGI Extensions'
to 'Allow' and the .DBW file executed perfectly.

Just to paint a more complete picture, the .dbw was generated by dBASE
to add records to a simple table and output an HTML result.
All the necessary files were placed into the wwwroot folder of the
Win2K3 web server.  Client browsers then pointed to
http://WEBSERVER/webtest.htm and users enter table data into a form.
This form then does a POST submission to 'webtest.dbw' in the same
wwwroot directory.

I would like to beef up the security by only allowing the dBASE runtime
to be executed.  When I add a web service extension pointing to the
dBASE runtime executable (D:\Program
Files\dBASE\PLUS\Runtime\PLUSRun.exe) and set it to 'Allow' after
restoring all the other CGIs to their default 'Prohibit' setting, I get
the same 404 error.

I'm definitely missing something, but not sure exactly what it could
be.

In the IIS Manager default web site properties, I did map the .dbw
extension to the specific target:
"D:\Program Files\dBASE\PLUS\Runtime\PLUSRun.exe" "%s"

for all verbs as specified in the dBASE web connection documentation.

So my best assumption here is that the .dbw invokes other executables
besides the PLUSRun.exe.  Since they are not listed in this web service
extension, it fails with the 404 error.  This is the only thing that
makes sense to me why this fails, and 'All Unknown CGI Extensions'
works fine.

Is there any way to dig deeper into IIS (log files somewhere?) that
could tell me what other executable files it may be looking for?

Any help would be greatly appreciated.

David,

Im sorry to harp on this issue - but I cannot seem to get IISext to
accept this syntax:
"D:\Program Files\dBASE\PLUS\Runtime\PLUSRun.exe" "%s"
for an allowable file.

Can you point me to an example of the exact syntax for this type of
command?
Here is what I have tried so far without any luck:

C:\WINDOWS\system32>iisext /AddFile C:\Program
Files\dBASE\PLUS\Runtime\PLUSrun.exe %s 1 PlusRun 0 PlusRun

{Produced a Type Mismatch Error}

Ill spare you the boring details of everything I tried next.

Finally, I figured the spaces between Program and Files and %s were
posing the problem, so I moved the runtime files to a new folder off
the root: C:\PLRun.  I also tried putting quotes and subquotes within
and around the entire string (including the %s)

C:\WINDOWS\system32>iisext /AddFile ""C:\PLRun\PLUSrun.exe "%s"" 1
PlusRun 0 PlusRun

And this "took".

When I looked at the Required Files list in the PlusRun Web Extension
in IIS, it read exactly as follows:
C:\PLRun\PLUSrun.exe %s

with no quotes whatsoever.

I still cannot get these .dbw scripts to run without Allowing All
Unknown CGI Extensions in IIS, and for the life of me I cannot get that
string to match that exact syntax with the quotes.

I did find one post where someone recommended doing a direct Metabase
edit, which I did try.  In the metabase.xml file, I found the location
of the PlusRun web extension.  I entered the above string using the
HTML " equivalent for the double quote, and managed to finally
"see it" listed in the IIS properties of this web extension, but it
still didnt work.  Im guessing that the metabase edit is purely a
display edit, and doesnt actually update any settings.

I wouldnt bother you again if I could find any help anywhere else, but
you're the only one who seems to really understand the inner workings
here.  I found one other Post in Usenet where someone had this same
problem, and he posted after a week that he solved his problem by using
the IISExt utility, but he did not specify a syntax.

Your help is very much appreciated.

I agree that the whole issue with Long File Names (especially spaces and
quotes, which are used as commandline argument separators) and IIS
commandline tools is confusing.  Here's the crux of what is going on --
there are three different namespaces with different rules:
1. XML for configuration
2. IIS Configuration data (invariant)
3. Script Host

Ultimately, you want certain values for #2, but you can only enter them
through #1 or #3.

Here are the combinations that work for you:
1.
In Application Mappings tab:
.dbw
"C:\Program Files\dBASE\PLUS\Runtime\PLUSrun.exe" %s

iisext /AddFile "C:\Program Files\dBASE\PLUS\Runtime\PLUSrun.exe %s" 1
PlusRun 1 PlusRun

2.
In Application Mappings tab:
.dbw
"C:\Program Files\dBASE\PLUS\Runtime\PLUSrun.exe" "%s"

iisext /AddFile "C:\Program Files\dBASE\PLUS\Runtime\PLUSrun.exe %s" 1
PlusRun 1 PlusRun

Then edit metabase.xml to include
C:\Program Files\dBASE\PLUS\Runtime\PLUSrun.exe "%s"

(note where you have " and where you do not)

#1 should suffice for your needs, unless you reference .dbw files that are
LFN themselves.

Editing metabase.xml requires either you enable Edit While Running, or you
run NET STOP /y IISADMIN, then make metabase.xml changes, then run NET START
W3SVC

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

news:1109189554.583415.232450@o13g2000cwo.googlegroups.com...
David,

Im sorry to harp on this issue - but I cannot seem to get IISext to
accept this syntax:
"D:\Program Files\dBASE\PLUS\Runtime\PLUSRun.exe" "%s"
for an allowable file.

Can you point me to an example of the exact syntax for this type of
command?
Here is what I have tried so far without any luck:

C:\WINDOWS\system32>iisext /AddFile C:\Program
Files\dBASE\PLUS\Runtime\PLUSrun.exe %s 1 PlusRun 0 PlusRun

{Produced a Type Mismatch Error}

Ill spare you the boring details of everything I tried next.

Finally, I figured the spaces between Program and Files and %s were
posing the problem, so I moved the runtime files to a new folder off
the root: C:\PLRun.  I also tried putting quotes and subquotes within
and around the entire string (including the %s)

C:\WINDOWS\system32>iisext /AddFile ""C:\PLRun\PLUSrun.exe "%s"" 1
PlusRun 0 PlusRun

And this "took".

When I looked at the Required Files list in the PlusRun Web Extension
in IIS, it read exactly as follows:
C:\PLRun\PLUSrun.exe %s

with no quotes whatsoever.

I still cannot get these .dbw scripts to run without Allowing All
Unknown CGI Extensions in IIS, and for the life of me I cannot get that
string to match that exact syntax with the quotes.

I did find one post where someone recommended doing a direct Metabase
edit, which I did try.  In the metabase.xml file, I found the location
of the PlusRun web extension.  I entered the above string using the
HTML " equivalent for the double quote, and managed to finally
"see it" listed in the IIS properties of this web extension, but it
still didnt work.  Im guessing that the metabase edit is purely a
display edit, and doesnt actually update any settings.

I wouldnt bother you again if I could find any help anywhere else, but
you're the only one who seems to really understand the inner workings
here.  I found one other Post in Usenet where someone had this same
problem, and he posted after a week that he solved his problem by using
the IISExt utility, but he did not specify a syntax.

Your help is very much appreciated.