Thanks - I was hoping I could convince you :) As for the GUI, I personally disable the code and can never see a need for MFC code.
Why didn't you implement an operating-system agnostic GUI in HTML instead of using windows-specific MFC code? Hard-code the GUI HTML and logic in htmlgui.c This not only solves multi-platform issues, but also Provides another example for developers to look at to figure out how to use it. I mean, it isn't as if you would have to write a HTML server from scratch to provide this feature ;) -----Original Message----- From: Sergey Lyubka [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 4:18 PM To: David Lethe Cc: Fred; shttpd-general Subject: Re: [shttpd-general] [1.38 Win] How to encrypt .htpasswd? Sure. Config file is back :-) Are you guys have strong feelings about the GUI as well? I already removed it, and plan to patch in winnt service support. On 12/02/2008, David Lethe <[EMAIL PROTECTED]> wrote: > There are also a few issues in general with command-lines & windows that > I did not mention before > - command-line arguments won't propagate if you are in a cluster and > program fails. You will be stuck using a batch command file that sets > service parameters. I have got to believe this violates numerous > best-practices for windows. (and for all I know, it might be a > deal-killer for MSFT certification) > > - Unless you write a completely different executable that spawns > shttpd with appropriate parameters, then you won't be able to insure > appropriate path environment is passed; you won't be able to use an > icon; you will have to do extra work to digitally sign the executable. > (If you are in active directory environment, then is common practice for > sysadmin to set group policy that prevents non-signed programs -- > including batch files from running on any PC in the enterprise. > > - If you are running Vista or Win2008, then you must digitally sign as > it is a requirement to get around the UAC warnings. You won't be able > to get around this by using a .bat file, especially if you want an > autostart/autorun on removable media. (You can sign a .VBS script but > not a .BAT script) > > - Of course there are work-arounds for everything .. but bottom line, I > can't imagine that this product could be used in a windows environment > for any embedded application unless the developer writes a front-end > program that parses a configuration file, then launches shttpd as a > thread. We'll have to go down our own paths adding logic to get this to > work. > > I can't emphasize security enough. A configuration file can easily be > protected by developer using native unix/windows crypto library calls, > and this insures that nothing can be mucked with. Parameters are decoded > in RAM and safe from prying eyes, and they can't be mucked with unless > the hacker is really, really good. > > Take the config file away, and you force security-conscious developers > to re-invent the wheel you already invented. Ignore all arguments > related to windows-centric anomalies, and just consider security risk > alone with runtime parms. It is easy for hackers to create buffer > overflows in command-line programs. Unless program is statically linked > with libraries that are patched to protect such exploits then there is > risk. This program has potential to kill any host running any IP port > (web server, ftp server, mail). I for one will not be able to deploy > this program at any end-user site unless I can protect and control what > port(s) it uses. > > Convinced ? > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fred > Sent: Tuesday, February 12, 2008 11:57 AM > To: Sergey Lyubka > Cc: shttpd-general > Subject: Re: [shttpd-general] [1.38 Win] How to encrypt .htpasswd? > > At 14:09 12/02/2008 +0000, Sergey Lyubka wrote: > >and then call shttpd like this: "shttpd `cat my_config.txt`" > > I also prefer to use a configuration file. Having to call shttpd.exe > from a > batch file, and finding a way not to display a DOS box under Windows... > is > just not worth it. I think shttpd is OK as is. > > One thing that could be changed in shttp.conf, is being able to use a > relative path instead of an absolute path: I didn't have time to look > into > how to build an installer and have it write this information on the fly, > so > had to ask the user to manually edit this line so that it would point to > > C:\shttpd\php\php-cgi.exe since .\php\php-cgi.exe wouldn't work. > > Thanks. > > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > shttpd-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shttpd-general > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ shttpd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shttpd-general
