On Friday 14 December 2001 08:26 am, Alex V Koval wrote:
> Hello,
>
> At first I would like to tell big Thanks to all who are
> working on creation of Webware! I tried to test Webware for
> a test projects and found it to be very useful new platform
> for our team of web developers.
>
> While testing different sides of Webware I tried to use MiddleKit
> for a simple test application. I'd like to note that
> I am beginner with Python, Webware and Cheetah, but wanted to
> test this overall to study Python programming, Webware and
> Cheetah by developing a simple application.
>
> In the MiddleKit I found some small mistakes which makes it
> impossible to specify "Enum" for mkmodel structure. Documentation
> for MiddleKit does not contain (or I could not find) the information
> where/how to submit those small patches. I do not think that
> I will became stable developer of something (because my little
> experience with python which counts just a week) but I find my
> patches to be useful for a new people which will be trying to use
> MiddleKit.
>
> BTW, are the MiddleKit still developed by its author or development
> stopped ? I read somewhere that interface for PostgreSQL was planned
> long ago, but I do not see PostgreSQL drivers even in latest CVS
> updated version of Webware.
>
> As alternatives I also checked PyDO, but it does not fits our needs.
> Before we developed projects with Perl and we created those "middle
> objects" manually. Overall process was much more difficult comparing
> to use MiddleKit automate tool "generate".
I feel like I answered this question before, but this message is unread
in my box and I can't find any replies to it.
Patches should be posted by visiting the project page at:
http://sourceforge.net/projects/webware
And clicking "Patches". The direct URL is:
http://sourceforge.net/tracker/?group_id=4866&atid=304866
Webware cvs has improved support for csv so your enum problems should
go away.
Yes, MK is still under development.
-Chuck

I've checked in Tavis's patches for the new configuration settings:
ExtensionsToServe, UseExtensionCascading, ExtensionCascadeOrder,
FilesToHide, and FilesToServe. Documentation has been updated.
With proper use of these settings, you can avoid exposing things like *.pyc
and *.py~ files through the web.
--
- Geoff Talvola
gtalvola@...

At 09:12 AM 12/18/01 -0800, Russell Blank wrote:
>Geoffrey,
>
>***********
>When I receive the error for 'UseAutomaticPathSessions', I am using
>wkcgi.exe.
>***********
>Thank you for your last response, but I must be honest, it has made me a bit
>nervous. I am a bit concerned about you last comment 'The unfortunate fact
>is, neither the ISAPI interface nor wkcgi.exe are solid, stable, proven
>solutions at this point.' I have been testing against wkcgi.exe for several
>months and have seen better performance and reliability than webkit.cgi.
>What has been reported that makes it unreliable? Are there security
>concerns?
>
>Thanks
Very long URL's can cause an access violation in wkcgi.exe. In addition to
that, you seem to be experiencing two problems -- UseAutomaticPathSessions
doesn't work, and it hangs with 100% of the CPU if the appserver isn't
running. I think that the problem with long URL's might be a security concern.
On the positive side, it doesn't seem like it would be hard to fix any of
these problems. I'll try look into these issues myself soon (i.e. later
this week), but I was also hoping Jay Love could look into it since he
wrote it.
--
- Geoff Talvola
gtalvola@...

Geoffrey,
***********
When I receive the error for 'UseAutomaticPathSessions', I am using
wkcgi.exe.
***********
Thank you for your last response, but I must be honest, it has made me a bit
nervous. I am a bit concerned about you last comment 'The unfortunate fact
is, neither the ISAPI interface nor wkcgi.exe are solid, stable, proven
solutions at this point.' I have been testing against wkcgi.exe for several
months and have seen better performance and reliability than webkit.cgi.
What has been reported that makes it unreliable? Are there security
concerns?
Thanks
-----Original Message-----
From: Geoffrey Talvola [mailto:gtalvola@...]
Sent: Tuesday, December 18, 2001 5:42 AM
To: rblank@...; Webware-Devel (E-mail)
Subject: Re: [Webware-devel] A few questions
On Monday December 17, 2001 05:36 pm, Russell Blank wrote:
> In the next few weeks, I am about to go live with a project that was
> developed using webware. I have a few questions that I have been
> accumulating:
>
> 1. Can I shut off access to the webware default/admin pages?
You can simply remove the Admin context from the list of contexts in your
Application.config.
> 2. How does 'UseAutomaticPathSessions': 1, work? If I change the
> option to 1 I get the following error:
> Traceback (most recent call last): File "WebKit\Application.py", line
> 346, in dispatchRequest self.handleMissingPathSession(transaction)
> File "WebKit\Application.py", line 487, in handleMissingPathSession if
> request.queryString(): File "WebKit\HTTPRequest.py", line 448, in
> queryString return self._environ['QUERY_STRING'] KeyError:
QUERY_STRING
Which adapter are you using when you see this error?
> 3. What is faster and more secure wkcgi.exe or using ISAPI through IIS?
4.
> When I use wkcgi.exe and I do not have the appserver running (by
mistake),
> my machine freezes and a processes call wkcgi.exe is peaked at 99% CPU
> usage. When I try to kill this process, I am denied access? Any
> thoughts?
> My Environment is: Windows 2000 and IIS Server 5.0 using Webware 0.6 (not
> 6 beta)
ISAPI is faster, but last time I checked it had memory leaks, so wkcgi.exe
may be a better solution. But it certainly shouldn't get stuck in an
infinite loop if it can't contact the appserver. The unfortunate fact is,
neither the ISAPI interface nor wkcgi.exe are solid, stable, proven
solutions
at this point.
I've added this bug report to the Sourceforge bug tracker, and hopefully the
author (Jay Love) can take a look at it soon. If you have a C compiler
handy
you could also look into it yourself.
But certainly, if you don't need the additional speed, your most solid
solution on IIS is definitely to use WebKit.cgi. You could convert it to an
EXE using py2exe or Installer to gain a small amount of additional speed.
- Geoff

On Monday December 17, 2001 05:36 pm, Russell Blank wrote:
> In the next few weeks, I am about to go live with a project that was
> developed using webware. I have a few questions that I have been
> accumulating:
>
> 1. Can I shut off access to the webware default/admin pages?
You can simply remove the Admin context from the list of contexts in your
Application.config.
> 2. How does 'UseAutomaticPathSessions': 1, work? If I change the
> option to 1 I get the following error:
> Traceback (most recent call last): File "WebKit\Application.py", line
> 346, in dispatchRequest self.handleMissingPathSession(transaction)
> File "WebKit\Application.py", line 487, in handleMissingPathSession if
> request.queryString(): File "WebKit\HTTPRequest.py", line 448, in
> queryString return self._environ['QUERY_STRING'] KeyError: QUERY_STRING
Which adapter are you using when you see this error?
> 3. What is faster and more secure wkcgi.exe or using ISAPI through IIS? 4.
> When I use wkcgi.exe and I do not have the appserver running (by mistake),
> my machine freezes and a processes call wkcgi.exe is peaked at 99% CPU
> usage. When I try to kill this process, I am denied access? Any
> thoughts?
> My Environment is: Windows 2000 and IIS Server 5.0 using Webware 0.6 (not
> 6 beta)
ISAPI is faster, but last time I checked it had memory leaks, so wkcgi.exe
may be a better solution. But it certainly shouldn't get stuck in an
infinite loop if it can't contact the appserver. The unfortunate fact is,
neither the ISAPI interface nor wkcgi.exe are solid, stable, proven solutions
at this point.
I've added this bug report to the Sourceforge bug tracker, and hopefully the
author (Jay Love) can take a look at it soon. If you have a C compiler handy
you could also look into it yourself.
But certainly, if you don't need the additional speed, your most solid
solution on IIS is definitely to use WebKit.cgi. You could convert it to an
EXE using py2exe or Installer to gain a small amount of additional speed.
- Geoff

In the next few weeks, I am about to go live with a project that was
developed using webware. I have a few questions that I have been
accumulating:
1. Can I shut off access to the webware default/admin pages?
2. How does 'UseAutomaticPathSessions': 1, work? If I change the
option to 1 I get the following error:
Traceback (most recent call last): File "WebKit\Application.py", line 346,
in dispatchRequest self.handleMissingPathSession(transaction) File
"WebKit\Application.py", line 487, in handleMissingPathSession if
request.queryString(): File "WebKit\HTTPRequest.py", line 448, in
queryString return self._environ['QUERY_STRING'] KeyError: QUERY_STRING
3. What is faster and more secure wkcgi.exe or using ISAPI through IIS?
4. When I use wkcgi.exe and I do not have the appserver running (by
mistake), my machine freezes and a processes call wkcgi.exe is peaked at 99%
CPU usage. When I try to kill this process, I am denied access? Any
thoughts?
My Environment is: Windows 2000 and IIS Server 5.0 using Webware 0.6 (not 6
beta)
Russell A. Blank
Senior Consultant
Atlas Development Corporation
6351 Owensmouth Avenue, #101
Woodland Hills, CA 91367
(818) 340-7080 Phone
(818) 340-7079 Fax

On Saturday December 15, 2001 01:07 am, Tripp Lilley wrote:
> The following error says to me either that StyleSheet.css is being
> inappropriately stored in CVS, or that the installer should gracefully
> handle the inability to write over it. I don't know whether or not there
> are any other files that are in a similar state, because I just do a find
> / chmod whenever this happens...
I agree, and I would suggest that Webware install script shouldn't ever try
to write to files that are part of the CVS repository. So I would vote for
removing StyleSheet.css (and any other files that install.py writes) from
CVS.
- Geoff

On Friday 14 December 2001 23:44, Tripp Lilley wrote:
> Chuck told me to just post enhancement requests here, since the
> Tracker isn't currently configured with different categories for
> enhancements, bugs, etc.
>
> Note that I'm not just expecting this stuff to magically "happen".
> I'm just recording the ideas for posterity so other people know
> about them (and maybe get inspired by them), and so I have
> somewhere to go to find them all when I'm ready to tackle some of
> them :)
>
> With that hefty disclaimer out of the way, here's one:
>
> In Application.config, I ought to be able to specify a context as
> an alias for another context. Specifically, I want the "default"
> context to be an alias for some other context.
>
> E.g., "default : 'alias:foo'" or what have you.
I've implemented something similar in the experimental code I've been
working on:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/expwebware/Webware/
I've used the concepts 'Applications' and 'VirtualDirs' rather than
'contexts'. The experimental code allows you to have multiple
Applications running in the AppServer, each with its own pool of
servlets, sessions, shared data, etc. Applications are mapped to
requests in the same way as 'contexts', but are different in all
other respects. They are more like the original 'ServletContexts'
from J2EE, that WebKit's 'contexts' where named after.
VirtualDirs belong to Applications, are the same as 'aliases' in
Apache.
Applications:
ROOT:
VirtualDirs:
Home = '/home/WK/home'
Products = '/home/WK/Products'
ROOT = Home
MyOtherApp:
Home = '/home/WK2/home'
Products = '/home/WK2/Products'
ROOT = Home
# this will launch 2 applications
http://myhost.com/WK/Home/MyServlet.py
will map to the ROOT Application's 'Home' virtual dir. So will
http://myhost.com/WK/MyServlet.pyhttp://myhost.com/WK/MyOtherApp/Products/MyServlet.py will map to the
'MyOtherApp' application's 'Products' virtual dir.
http://myhost.com/WK/MyOtherApp/MyServlet.py will map to its 'Home'
virtual dir.
You can also do this:
Applications:
MyOtherApp:
Home = '/home/WK2/home'
Products = '/home/WK2/Products'
ROOT = Home
ROOT = 'MyOtherApp' # an alias
# this will launch 1 application
Cheers,
Tavis

Chuck told me to just post enhancement requests here, since the Tracker
isn't currently configured with different categories for enhancements,
bugs, etc.
Note that I'm not just expecting this stuff to magically "happen". I'm
just recording the ideas for posterity so other people know about them
(and maybe get inspired by them), and so I have somewhere to go to find
them all when I'm ready to tackle some of them :)
With that hefty disclaimer out of the way, here's one:
In Application.config, I ought to be able to specify a context as
an alias for another context. Specifically, I want the "default"
context to be an alias for some other context.
E.g., "default : 'alias:foo'" or what have you.
--
Tripp Lilley * http://www.hfd.com/ * Thinkerer
------------------------------------------------------------------------
"Hey! That's in the list of things that evil overlords should
never do. 'Don't fight like a man, fight like an evil overlord.'"
http://www.userfriendly.org/cartoons/archives/99apr/19990429.html

On Friday 14 December 2001 06:55, Geoffrey Talvola wrote:
> At 04:04 PM 12/13/01 -0800, Tavis Rudd wrote:
> >Here's a patch to implement ExtensionsToServe, FilesToHide, and
> >FilesToServe. They work as I documented yesterday, and will also
> > need to be added to the default config file.
>
> Excellent! I'll check in the patch to CVS sometime in the next
> couple of days, unless Chuck gets to it before I do.
Before you do ... here's an update of that patch that also implements
'ExtensionCascadeOrder', which is a list of extensions to cascade
through when there are multiple files with different extensions found
for a requested basename. The first match from the list
'ExtensionCascadeOrder' is used. If no match is found a 404 error is
returned. The setting 'UseCascadingExtensions' turns the behaviour
on and off. The patch includes the changes to the default
Configs/Application.config file.
Tavis

Hello,
At first I would like to tell big Thanks to all who are
working on creation of Webware! I tried to test Webware for
a test projects and found it to be very useful new platform
for our team of web developers.
While testing different sides of Webware I tried to use MiddleKit
for a simple test application. I'd like to note that
I am beginner with Python, Webware and Cheetah, but wanted to
test this overall to study Python programming, Webware and
Cheetah by developing a simple application.
In the MiddleKit I found some small mistakes which makes it
impossible to specify "Enum" for mkmodel structure. Documentation
for MiddleKit does not contain (or I could not find) the information
where/how to submit those small patches. I do not think that
I will became stable developer of something (because my little
experience with python which counts just a week) but I find my patches
to be useful for a new people which will be trying to use MiddleKit.
BTW, are the MiddleKit still developed by its author or development
stopped ? I read somewhere that interface for PostgreSQL was planned long
ago, but I do not see PostgreSQL drivers even in latest CVS
updated version of Webware.
As alternatives I also checked PyDO, but it does not fits our needs.
Before we developed projects with Perl and we created those "middle objects"
manually. Overall process was much more difficult comparing to use MiddleKit
automate tool "generate".
--
Alex V. Koval

At 04:04 PM 12/13/01 -0800, Tavis Rudd wrote:
>Here's a patch to implement ExtensionsToServe, FilesToHide, and
>FilesToServe. They work as I documented yesterday, and will also need
>to be added to the default config file.
>
>IMHO,there's far too much coupling in there between the Application
>and Request classes, which makes it harder than it should be to grok, or
>implement new stuff like this.
>
>Tavis
Excellent! I'll check in the patch to CVS sometime in the next couple of
days, unless Chuck gets to it before I do.
- Geoff Talvola
gtalvola@...

Here's a patch to implement ExtensionsToServe, FilesToHide, and
FilesToServe. They work as I documented yesterday, and will also need
to be added to the default config file.
IMHO,there's far too much coupling in there between the Application
and Request classes, which makes it harder than it should be to grok, or
implement new stuff like this.
Tavis
On Thursday 13 December 2001 11:59, Geoffrey Talvola wrote:
> 2 questions:
>
> - Can this be made backward-compatible by also allowing the name
> "ExtensionsToIgnore", perhaps emitting a deprecation warning
> message?
>
> - Now that you've done the work in your experimental version, could
> you adapt it to create a patch for Webware CVS?
>
> At 01:40 PM 12/12/01 -0800, Tavis Rudd wrote:
> >I've just done a little more work on this in the experimental
> > code. Here are the config settings I've implemented and tested so
> > far:
> >
> >DirectoryFiles = ['index','Index','main','Main',
> > 'default','Default',]
> >
> >## these 2 only affect requests with no extension specified
> ># same as before
> >ExtensionsToHide = ['.pyc','.pyo','.py~', '.bak', '.tmpl',
> > '.py_bak'] # only use if a list is given
> >ExtensionsToServe = None
> ># ExtensionsToServe = ['.py','.html']
> >
> >
> ># if multiple files are found for a URI without the ext specified
> ># cascade through this list in sequence till one is found.
> ># 404 if none match
> >UseCascadingExtensions = True
> >ExtensionCascadeOrder = ['.html', '.py', '.psp', '.tmpl']
> >
> ># a list of glob patterns to filter out after all the rest of the
> ># path matching is finished. 404 if matches
> >FilesToHide = ['.*','*~', '*bak', '*.tmpl', ]
> >
> ># a list glob patterns to serve from exclusively.
> ># if the file found for the URI doesn't match then 404
> ># done after FilesToHide
> >FilesToServe = None # only used if a list is given
> >#FilesToServe = ['*.py', '*.jpg','*.gif']
> >
> >
> >Regardless of whether the rest of the experimental code is used I
> >feel this stuff should definitely make it in. What do you think
> > about the names I've given the settings? ExtensionsToServe and
> > FilesToServe are a bit ambiguous. I'm leaning towards
> >FilePatternsToServe.
> >
> >Tavis

On Thursday 13 December 2001 11:59, Geoffrey Talvola wrote:
> 2 questions:
>
> - Can this be made backward-compatible by also allowing the name
> "ExtensionsToIgnore", perhaps emitting a deprecation warning
> message?
Sure, why don't we just stick with ExtensionsToIgnore for now? I
think 'ExtensionsToHide' makes the purpose of the setting clearer and
should be used in 0.7.
> - Now that you've done the work in your experimental version, could
> you adapt it to create a patch for Webware CVS?
Sure, though it might take me a while to remember/regrok how this
stuff is dealt with in Webware 0.6 ;)
> At 01:40 PM 12/12/01 -0800, Tavis Rudd wrote:
> >I've just done a little more work on this in the experimental
> > code. Here are the config settings I've implemented and tested so
> > far:
> >
> >DirectoryFiles = ['index','Index','main','Main',
> > 'default','Default',]
> >
> >## these 2 only affect requests with no extension specified
> ># same as before
> >ExtensionsToHide = ['.pyc','.pyo','.py~', '.bak', '.tmpl',
> > '.py_bak'] # only use if a list is given
> >ExtensionsToServe = None
> ># ExtensionsToServe = ['.py','.html']
> >
> >
> ># if multiple files are found for a URI without the ext specified
> ># cascade through this list in sequence till one is found.
> ># 404 if none match
> >UseCascadingExtensions = True
> >ExtensionCascadeOrder = ['.html', '.py', '.psp', '.tmpl']
> >
> ># a list of glob patterns to filter out after all the rest of the
> ># path matching is finished. 404 if matches
> >FilesToHide = ['.*','*~', '*bak', '*.tmpl', ]
> >
> ># a list glob patterns to serve from exclusively.
> ># if the file found for the URI doesn't match then 404
> ># done after FilesToHide
> >FilesToServe = None # only used if a list is given
> >#FilesToServe = ['*.py', '*.jpg','*.gif']
> >
> >
> >Regardless of whether the rest of the experimental code is used I
> >feel this stuff should definitely make it in. What do you think
> > about the names I've given the settings? ExtensionsToServe and
> > FilesToServe are a bit ambiguous. I'm leaning towards
> >FilePatternsToServe.
> >
> >Tavis

2 questions:
- Can this be made backward-compatible by also allowing the name
"ExtensionsToIgnore", perhaps emitting a deprecation warning message?
- Now that you've done the work in your experimental version, could you
adapt it to create a patch for Webware CVS?
At 01:40 PM 12/12/01 -0800, Tavis Rudd wrote:
>I've just done a little more work on this in the experimental code.
>Here are the config settings I've implemented and tested so far:
>
>DirectoryFiles = ['index','Index','main','Main', 'default','Default',]
>
>## these 2 only affect requests with no extension specified
># same as before
>ExtensionsToHide = ['.pyc','.pyo','.py~', '.bak', '.tmpl', '.py_bak']
># only use if a list is given
>ExtensionsToServe = None
># ExtensionsToServe = ['.py','.html']
>
>
># if multiple files are found for a URI without the ext specified
># cascade through this list in sequence till one is found.
># 404 if none match
>UseCascadingExtensions = True
>ExtensionCascadeOrder = ['.html', '.py', '.psp', '.tmpl']
>
># a list of glob patterns to filter out after all the rest of the
># path matching is finished. 404 if matches
>FilesToHide = ['.*','*~', '*bak', '*.tmpl', ]
>
># a list glob patterns to serve from exclusively.
># if the file found for the URI doesn't match then 404
># done after FilesToHide
>FilesToServe = None # only used if a list is given
>#FilesToServe = ['*.py', '*.jpg','*.gif']
>
>
>Regardless of whether the rest of the experimental code is used I
>feel this stuff should definitely make it in. What do you think about
>the names I've given the settings? ExtensionsToServe and
>FilesToServe are a bit ambiguous. I'm leaning towards
>FilePatternsToServe.
>
>Tavis
--
- Geoff Talvola
gtalvola@...

I've just done a little more work on this in the experimental code.
Here are the config settings I've implemented and tested so far:
DirectoryFiles = ['index','Index','main','Main', 'default','Default',]
## these 2 only affect requests with no extension specified
# same as before
ExtensionsToHide = ['.pyc','.pyo','.py~', '.bak', '.tmpl', '.py_bak']
# only use if a list is given
ExtensionsToServe = None
# ExtensionsToServe = ['.py','.html']
# if multiple files are found for a URI without the ext specified
# cascade through this list in sequence till one is found.
# 404 if none match
UseCascadingExtensions = True
ExtensionCascadeOrder = ['.html', '.py', '.psp', '.tmpl']
# a list of glob patterns to filter out after all the rest of the
# path matching is finished. 404 if matches
FilesToHide = ['.*','*~', '*bak', '*.tmpl', ]
# a list glob patterns to serve from exclusively.
# if the file found for the URI doesn't match then 404
# done after FilesToHide
FilesToServe = None # only used if a list is given
#FilesToServe = ['*.py', '*.jpg','*.gif']
Regardless of whether the rest of the experimental code is used I
feel this stuff should definitely make it in. What do you think about
the names I've given the settings? ExtensionsToServe and
FilesToServe are a bit ambiguous. I'm leaning towards
FilePatternsToServe.
Tavis
On Wednesday 12 December 2001 11:57, Love, Jay wrote:
> We've talked about having an ExtensionsToServe numerous times.
> Perhaps this should be a configuration option, say
> "LimitFileTpesServed", and then ExtensionsToServe would list what
> may be served.
>
> J
>
> > -----Original Message-----
> > From: Geoffrey Talvola [mailto:gtalvola@...]
> > Sent: Wednesday, December 12, 2001 2:51 PM
> > To: tavis@...; Webware-devel@...
> > Subject: Re: [Webware-devel] security hole in WebKit
> >
> > At 11:55 AM 12/12/01 -0800, Tavis Rudd wrote:
> > >Hi,
> > >in the cvs version of WebKit (and I assume all previous
> > > versions) it's possible to access backup versions of the .py
> > > servlet files: http://localhost/WK/Welcome.py~ for example.
> > > This could expose information about the site that should be
> > > kept private. Consider http://localhost/WK/.htpasswd. While
> > > the ExtensionsToIgnore setting works when the extension isn't
> > > specified in the URI, it provides no protection when it is.
> > >
> > >A solution is to make WebKit accept a list of files that it will
> > >never serve ('FilesToIgnore' or 'FilesToHide'). The setting
> > > could be a list of plain string filenames, or a list of
> > > patterns to match. Conversely, it should accept a list of
> > > files/patterns that it will serve from exclusively
> > > ('FilesToServe').
> > >
> > >Also, I propose that 'ExtensionsToIgnore' be renamed
> > >'ExtensionsToHide', making its purpose clearer.
> > > 'ExtensionsToServe' should be implemented as well.
> >
> > Also, even if you're not editing your live site and leaving
> > backup files
> > lying around, you'll still have *.pyc files in there that can
> > be fetched
> > and then potentially decompiled.
> >
> >
> > --
> >
> > - Geoff Talvola
> > gtalvola@...
> >
> > _______________________________________________
> > Webware-devel mailing list
> > Webware-devel@...
> > https://lists.sourceforge.net/lists/listinfo/webware-devel
>
> -------------------------------------------------------------------
>---------
>
> This e-mail and any attachments may be confidential or legally
> privileged. If you received this message in error or are not the
> intended recipient, you should destroy the e-mail message and any
> attachments or copies, and you are prohibited from retaining,
> distributing, disclosing or using any information contained herein.
> Please inform us of the erroneous delivery by return e-mail.
>
> Thank you for your cooperation.
>
> -------------------------------------------------------------------
>---------

We've talked about having an ExtensionsToServe numerous times. Perhaps this
should be a configuration option, say "LimitFileTpesServed", and then
ExtensionsToServe would list what may be served.
J
> -----Original Message-----
> From: Geoffrey Talvola [mailto:gtalvola@...]
> Sent: Wednesday, December 12, 2001 2:51 PM
> To: tavis@...; Webware-devel@...
> Subject: Re: [Webware-devel] security hole in WebKit
>
>
> At 11:55 AM 12/12/01 -0800, Tavis Rudd wrote:
> >Hi,
> >in the cvs version of WebKit (and I assume all previous versions)
> >it's possible to access backup versions of the .py servlet files:
> >http://localhost/WK/Welcome.py~ for example. This could expose
> >information about the site that should be kept private. Consider
> >http://localhost/WK/.htpasswd. While the ExtensionsToIgnore setting
> >works when the extension isn't specified in the URI, it provides no
> >protection when it is.
> >
> >A solution is to make WebKit accept a list of files that it will
> >never serve ('FilesToIgnore' or 'FilesToHide'). The setting could be
> >a list of plain string filenames, or a list of patterns to match.
> >Conversely, it should accept a list of files/patterns that it will
> >serve from exclusively ('FilesToServe').
> >
> >Also, I propose that 'ExtensionsToIgnore' be renamed
> >'ExtensionsToHide', making its purpose clearer. 'ExtensionsToServe'
> >should be implemented as well.
>
> Also, even if you're not editing your live site and leaving
> backup files
> lying around, you'll still have *.pyc files in there that can
> be fetched
> and then potentially decompiled.
>
>
> --
>
> - Geoff Talvola
> gtalvola@...
>
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>
----------------------------------------------------------------------------
This e-mail and any attachments may be confidential or legally privileged.
If you received this message in error or are not the intended recipient, you
should destroy the e-mail message and any attachments or copies, and you are
prohibited from retaining, distributing, disclosing or using any information
contained herein. Please inform us of the erroneous delivery by return
e-mail.
Thank you for your cooperation.
----------------------------------------------------------------------------

At 11:55 AM 12/12/01 -0800, Tavis Rudd wrote:
>Hi,
>in the cvs version of WebKit (and I assume all previous versions)
>it's possible to access backup versions of the .py servlet files:
>http://localhost/WK/Welcome.py~ for example. This could expose
>information about the site that should be kept private. Consider
>http://localhost/WK/.htpasswd. While the ExtensionsToIgnore setting
>works when the extension isn't specified in the URI, it provides no
>protection when it is.
>
>A solution is to make WebKit accept a list of files that it will
>never serve ('FilesToIgnore' or 'FilesToHide'). The setting could be
>a list of plain string filenames, or a list of patterns to match.
>Conversely, it should accept a list of files/patterns that it will
>serve from exclusively ('FilesToServe').
>
>Also, I propose that 'ExtensionsToIgnore' be renamed
>'ExtensionsToHide', making its purpose clearer. 'ExtensionsToServe'
>should be implemented as well.
Also, even if you're not editing your live site and leaving backup files
lying around, you'll still have *.pyc files in there that can be fetched
and then potentially decompiled.
--
- Geoff Talvola
gtalvola@...

Hi,
in the cvs version of WebKit (and I assume all previous versions)
it's possible to access backup versions of the .py servlet files:
http://localhost/WK/Welcome.py~ for example. This could expose
information about the site that should be kept private. Consider
http://localhost/WK/.htpasswd. While the ExtensionsToIgnore setting
works when the extension isn't specified in the URI, it provides no
protection when it is.
A solution is to make WebKit accept a list of files that it will
never serve ('FilesToIgnore' or 'FilesToHide'). The setting could be
a list of plain string filenames, or a list of patterns to match.
Conversely, it should accept a list of files/patterns that it will
serve from exclusively ('FilesToServe').
Also, I propose that 'ExtensionsToIgnore' be renamed
'ExtensionsToHide', making its purpose clearer. 'ExtensionsToServe'
should be implemented as well.
Cheers,
Tavis

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details