Webware for Python

Here is a suggestion for improvement of the Appserver script:

When debugging an application, I like to run the Appserver with unbuffered
Python output (Python option -u). Also, it might make sense to run it with
Python using optimization (Python option -O). However, you cannot give these
parameters to the Appserver script, since they would be passed on to the
ThreadedAppServer script, and not to Python. My suggestion is to catch these
two options if they are given in advance, and only pass the rest of the
parameters on to the ThreadedAppServer:

----------------- AppServer ------------------------------------

#!/bin/sh

# You may give the following Python parameters in advance
# followed by the parameters passed on to ThreadedAppServer
# -O with optimization (.pyo instead of .pyc)
# -u unbuffered output (useful for debugging)
unset OPTIONS
while getopts ":Ou" OPT; do
    case $OPT in O | u) OPTIONS="$OPTIONS -$OPT";; esac
done
shift `expr $OPTIND - 1`

RETCODE=3 # as long as the appserver returns a 3, it wants to be restarted
while test $RETCODE -eq 3; do
    /usr/bin/env python $OPTIONS Launch.py ThreadedAppServer $*
    RETCODE=$?
done

----------------------------------------------------------------

Also, I noticed a minor flaw in WebKit/ImportSpy.py. There, the line

if f[-4:] == '.pyc':

should be replace to

if f[-4:].lower() in ('.pyc', '.pyo'):

There is a similar line in MiscUtils/inspect.py which is already ok.

----------------------------------------------------------------

Christoph

Christoph Zwerschke wrote:
> Currently I am considering about delivering a Webware application to a
> customer without the source code ot the servlets, i.e. only handing out the
> *.pyo files. This may prevent a little bit from fiddling around with the
> sources, though I know it is not a real protection since it is possible to
> recompile. Anyway, the problem is: Webware will not work if you take away
> the *.py files. It will ignore the *.pyc and *.pyo files even if you remove
> them from FilesToHide. The reason is that '.py' is hardcoded as the (only)
> extension for the PythonServletFactory.
> 
> So, my question is: Is there a good reason why the class
> PythonServletFactory has only
> 
>  def extensions(self):
>   return ['.py']
> 
> and not
> 
>  def extensions(self):
>   return ['.py', '.pyc', '.pyo']
> 
> I suggest adding the two extensions.

I think the reason (if there was one) for not including .pyc and .pyo 
files is that it could be seen as a potential security hole, in that 
removing the .py file would not be sufficient to delete the servlet if 
the .pyc file had been created.  Though part of it was probably also the 
lack of cascading extensions -- i.e., you had to have one matching 
extension, instead of multiple files with servable extensions (as you'll 
typically have if you serve .pyc files).  You can now have this by 
setting the appropriate settings, but this aspect persists.

I don't really see the importance of this change -- you can certainly 
make the change for your application, and it's neither a large change, 
nor is distribution much of a problem because you're obviously going to 
be distributing the entire package including Webware.

   Ian

Hi Ian,

> I think the reason (if there was one) for not including .pyc and .pyo
> files is that it could be seen as a potential security hole, in that
> removing the .py file would not be sufficient to delete the servlet if
> the .pyc file had been created.

By default, they are excluded in Application.config anyway. However, if you
forget to exclude them, then you will have an even more severe security
hole, since the content of the files will be delivered to the web browser,
including private information like database passwords or something (they are
treated as UnknownFileTypeServlets currently, which does not make much sense
to me).

> Though part of it was probably also the lack of cascading extensions

As you wrote, this is not an argument any more.

Anyway, I just want to say thank you for providing Webware in the first
place. I really like it and appreciate the efforts of you and whoever might
have added contributions. I just hope the project will be continued and one
day we will see a 1.0 release ;-)

Christoph

Has anyone tried  py2exe on webware? 
I tried it a few years ago without much luck.

-Aaron

Ian Bicking wrote:

> Christoph Zwerschke wrote:
>
>> Currently I am considering about delivering a Webware application to a
>> customer without the source code ot the servlets, i.e. only handing 
>> out the
>> *.pyo files. This may prevent a little bit from fiddling around with the
>> sources, though I know it is not a real protection since it is 
>> possible to
>> recompile. Anyway, the problem is: Webware will not work if you take 
>> away
>> the *.py files. It will ignore the *.pyc and *.pyo files even if you 
>> remove
>> them from FilesToHide. The reason is that '.py' is hardcoded as the 
>> (only)
>> extension for the PythonServletFactory.
>>
>> So, my question is: Is there a good reason why the class
>> PythonServletFactory has only
>>
>>  def extensions(self):
>>   return ['.py']
>>
>> and not
>>
>>  def extensions(self):
>>   return ['.py', '.pyc', '.pyo']
>>
>> I suggest adding the two extensions.
>
>
> I think the reason (if there was one) for not including .pyc and .pyo 
> files is that it could be seen as a potential security hole, in that 
> removing the .py file would not be sufficient to delete the servlet if 
> the .pyc file had been created.  Though part of it was probably also 
> the lack of cascading extensions -- i.e., you had to have one matching 
> extension, instead of multiple files with servable extensions (as 
> you'll typically have if you serve .pyc files).  You can now have this 
> by setting the appropriate settings, but this aspect persists.
>
> I don't really see the importance of this change -- you can certainly 
> make the change for your application, and it's neither a large change, 
> nor is distribution much of a problem because you're obviously going 
> to be distributing the entire package including Webware.
>
>   Ian
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel

Hi,

Can you please grant me cvs access to webware-sandbox?

SF username: wlarsen

Thanks,
Wayne