updated version to 1.99

any comments on this one?  It won't be fixed for the beta but seems important to
fix for the 2.0 release

Has this been verified?  I have never given execute rights to IUSR_<compname> on
cmd.exe for a Chameleon install ... this would be an immediate flag that
something is wrong.

Changed target to 1.99 RC 1.

Jason, please try to replicate this issues with the latest chameleon.

Daniel, what is the feasibility of modifying wmsparse to run as a cgi or php
extension?

I am hesitant to invest too much time into this issue because I really think the
wmsparse utility needs to be rewritten as follows:

1. use sqlite database
2. support wms and wfs
3. modify phpwms in php_utils to use sqlite
4. check for other dependencies introduced by this
5. extensive testing of all affected code, including:
- mapbrowser
- chameleon

When this happens, this issue becomes moot.

It's not technically difficult to modify wmsparse to run as a CGI (or even
support dual mode), I could do that easily, just let me know. 

The question is more whether it's a good idea to move this to a CGI since it's
not really a standalone service but a component of a larger system. For insance,
impromer calls could result in corruption of your WMS servers cache... I guess
we could try to restrict this CGI to calls from localhost, but that still
doesn't sound right.

It's really odd that with Windows you are forced to implement this kind of
workarounds to run a local program: where else in the world do you solve a
security issue by exposing your program through your web server? No wonder it's
not the safest platform around.

Oh... you also asked about the feasibility of making it an extension... well,
that's not too hard either, but extensions are harder to build (compile), so
that adds an extra painful requirement for those installing the software so I
would avoid it if we can.

Thinking out loud: Maybe it's time to start building the chameleon PHP extension
which would include this wms parser utility and other services that chameleon
needs and that don't fit anywhere else nicely.

I (still) have never come across this issue (as per comment#3) for either IIS 5
or 6.  

I will attempt to replicate.

Jason, you're the point man on this one :)

Verified: Win2K3, IIS6, Chameleon199b2, MS425.

Verified using the WMSBrowser widget in OGC Sample app.  Had to give cmd.exe
read/execute permission for the parsing to work.  Did not invesitage further as
it has already been suggested that modifying the wmsparse exe would be a
relatively simple process.

Perhaps this could also be addressed when executing the wmsparse exe in php.  eg:

common/phpwms/server_data_manager.php line 840: exec( $cmd, $a, $retval );

I'm not sure if passthru() or system() would have the same requirements (or
limitations)?

ok, so the original issue is valid.  IIS user requires execute privileges on
cmd.exe, which is considered a security issue.  What should be done about this
for version 1.99 and for future versions?  I'd like to see some sort of minimal
fix this time around as this would be an excellent candidate for including in
some sort of php_chameleon module (which won't be done for this version).

Perhaps the cgi model would be the easiest?  Or should it be a documented
limitation of working with IIS?

Reassigning to Daniel for comment on the cgi approach ...

After further discussions with Paul, taking this specific issue and things like
overall security concerns, and long term maintenance into account, we decided to
go with a Chameleon PHP DL Extension to solve this.

The external wmsparse will continue to be available for those who don't want yet
another PHP extension to compile, but prebuilt Windows packages will come with
that extension, so the current IIS issue will be solved.

Created bug 883 about the new extension. Marking it as a blocker.

Reassigned to Julien.

work has progressed on this but it won't be ready for RC1 ...

I think this needs to be pushed to 2.1/2.2 because of the risk of breaking
something at the last minute.

Bug 883 is about to be fixed, I think I should wait the 2.0
release/cvs-branching before modify the chameleon code to integrate the new php
extension.

sounds reasonable.  We'll have to create a branch for 2.0 I guess and then we
can start making this kind of modification.

targetting 2.2.

I commited the changes to CVS. I had hard time with the error handling. I ended
including the CPL library for error handling.  From now, if the chameleon is
loaded succesfully, the new php module will be used to parse the capability
document and modify the according dbf files.

Marking as FIXED