Webware for Python

On Saturday 08 December 2001 01:57 pm, Tim Payne wrote:
> If I went to the default page, the server seemed to go into a loop,
> forwarding me to /, then //, ///, and so on. If I tried to access a
> page directly, such as GeneralPage in the root directory, then it
> would forward to the default webware location under the url
> 127.0.0.1/GeneralPage.py/  From that point forward, all urls were
> based upon that, so when it tried to access the location I wanted, it
> was appended to that incorrect url and would report not found.
>
> I'm sure I've got something screwed up in either my apache config or
> one of the webkit/appserver configs. Anyone spot a possible cause
> from the effects I've described? I can provide copies of the configs
> and logs if someone would be willing to check them out for me.

Actually, my bet is that this is a bug in WebKit. We have had other 
bugs concerning root directories, the default context, etc. that varied 
depending on web server and adapter. This smells like another.

I've taken a note of this, but can't say when I will get to it. Anyone 
is welcome to fix it.

In the mean time (if you're up to tracking it down), can mod_rewrite 
get you what you need with minimal effort?


-Chuck

On Thursday 22 November 2001 04:01 pm, Tavis Rudd wrote:
> There's ways around this that don't require storage of passwords in
> clear text.  For example, a fall-back challenge question can be used
> in combination with an email address.  The user forgets their
> password, clicks 'send me a reminder', the server sends an email
> with a randomized URI the user can go to for the next 30 minutes and
> change their password.  Once they go to the URI they must answer the
> challenge question correctly before changing their password.  The
> response to the challenge question would also be hashed.  The
> password change would only truly be secure if it was encrypted via
> SSL, but you could use the javascript implementation md5 to send a
> hash of the new password instead of clear text when SSL is not
> available.

While those are all interesting solutions, we still shouldn't preclude 
a web site developer from mailing the user their password. That is 
still more convenient to the user that the above solutions and for many 
sites, the most basic security is all that is required.

-Chuck

On Wednesday 21 November 2001 10:26 am, Tavis Rudd wrote:
> just curious...

Don't forget to count all the people that either don't respond or 
aren't on the list.   ;-)


-Chuck

On Saturday 24 November 2001 03:27 pm, Luke Opperman wrote:
> What is the current state of MiddleKit? I like what I've
> read so far, curious how the database location is
> specified, curious how object inheritance is represented in
> a relational model. I'm very comfortable with complex
> relational join's and modeling... It will take a little
> readjusting to think of the same solutions in an object
> model (assuming possible..). Besides MiddleKit, what other
> ways are people dealing with database access?

The arguments you pass when creating the store are passed onto the DB 
API module. So you have your usual keyword args like host, username, 
etc. The database name is derived from your model.

If I remember my terminology correctly, we are using "horizontal 
mapping". In any case, the key points:
  - 1 SQL table per concrete (eg non-abstract) class
  - each table has all attributes including inheritance
  - obj references use a a 64 bit id (32 bit class serial num and
    32 bit obj serial num)
  - lists are down with back "pointer"/ref attributes

MKs largest weakness is unsophisticated list handling.

It has an excellent test suite and is very stable. I use it in 2 
production projects.

I also use the MK object model to generate views and forms and sample 
data for my objects. You may find other creative uses for the object 
model.

BTW If you don't like the 64 bit obj refs (and if you don't that's 
probably due to working with existing databases), simply don't use the 
"obj ref" type in your model. Or use it, mark it as isDerived, and 
implement the method that retrieves it.


-Chuck

On Sunday 25 November 2001 05:04 pm, James R. Phillips wrote:
> All,
>
> I changed filenameForKey() in SessionFileStore.py to use os.sep
> instead of the original hard-coded forward slash as in:
>
>    def filenameForKey(self, key):
>        return self._sessionDir + os.sep + '%s.ses' % key
>
> but since the original worked for me on both Windows NT
> and Linux I'm not sure whether this is a bug or not.  On
> Windows the path separator is \ and on Linux it is /, I
> changed it just to be safe.  I have not checked to see if
> the other WebKit directory names have the hard-coded forward
> slash or not.
>
>     Randy Phillips

Forward slashes in pathnames work on all platforms (for a Python 
program). This begs the question if the conventional wisdom of using 
os.path.join and os.sep is worthwhile.


-Chuck

On Monday 26 November 2001 04:18 pm, Dan Wilder wrote:
> Perhaps too much setup is required, with no GUI interface to
> Apache's httpd.conf.

On Monday 26 November 2001 04:50 pm, Geoffrey Talvola wrote:
> Apache works well on WinNT/2000 but it does require editing messy
> config files by hand.  That's a big turn-off for many Windows people.

But the original poster referred to installing the app on employee or 
customer laptops. httpd.conf is a text file which means writing a bit 
of Python code to whip it into shape for your custom app is doable and 
rather easy. In fact, I've done it for my own purposes.

Also, one could add a handler to Python's own HTTPServer as is 
discussed in later messages.


On Tuesday 27 November 2001 08:51 am, Mike Orr wrote:
> Is there a reason Webware needs a socket connection between its
> AppServer and a future built-in HTTP server?  Or could the HTTP
> server just import the AppServer and run it on its own?  Would it
> gain any performance advantagess?  Would there be any disadvantages,
> besides not being portable to other HTTP servers?

Having a separate web server means that restarting your app server is a 
delay for your users instead of an error message. In a production 
environment, that is fantastic.

I would prefer a subclass of HTTPServer that communicates with WebKit 
and even launches it if it is configured to run locally. Then you would 
have all the conveniences including restarting and one command to 
launch.


-Chuck

On Saturday 24 November 2001 05:39 am, Geoffrey Talvola wrote:
> On Thursday November 22, 2001 07:51 pm, Bill Bell wrote:
> > OK, I have consumed several early evening cocktails to prepare
> > myself for the embarrassment that must attend asking a question
> > like this. Here goes.
> >
> > Please consider the following script:
> >
> > 	import sys
> > 	sys . path . insert ( 1, r"H:\Webware" )
> > 	#~ import WebKit . OneShotAdapter
> > 	import WebKit . Object
> > 	print 'IMPORT SUCCEEDED'
> >
> > Obviously I have been playing with WebWare in an effort to get my
> > head around it.
> >
> > If I run this script just as it appears here I am unsurprised to
> > see the output from the 'print' statement. However, if I remove the
> > '#~' from that one line of the script and place it at the beginning
> > of the next line I do _not_ see the 'print' statement output.
> >
> > What say you?
>
> I can certainly understand your confusion.  It looks like
> OneShotAdapter.py redirects stdout immediately to a StringIO object
> as soon as it's imported. Also, there's a comment to the effect that
> "maybe this isn't the right thing to do" :-)
>
> OneShotAdapter is really only intended for use by OneShot.cgi -- did
> you have another use in mind, or were you just playing around?
>
> - Geoff

OneShotAdapter does this in order to support the OneShotAdapter.config 
ShowConsole setting which forces stdout to be displayed at the end of 
your web page. Without that setting, you can't see stdout which may 
include some important debugging print stmts as well as the app server 
startup messages.

Other than the confusion Bill stumbled upon, I don't think it causes 
any other problems. If we didn't redirect it at the top, we'd so later 
on. Doing so at the top captures as much output as possible.


-Chuck

Hi,

IMHO the download location on the right side of webware.sourceforge.net 
should point to webware 0.6 and not to webware 0.5.

Philipp 

-- 
Philipp Siegert
siegert@...
http://www.pp-services.de

In certain situations, MiddleKit could store an invalid object 
reference in the SQL database. This would cause a warning when 
retrieving the object and a disconnect between the source and target 
objects.

This was first reported by Dave Rogers who ran into it when A points to 
B and B points to A.

Stephan Karlsson reported it for when A points to 
B, both are new objects, and A is archived first.

I have fixed the bug and added a test case for this. All existing test 
cases pass.

If you are using MiddleKit, please get the latest CVS version and try 
it out.
	https://sourceforge.net/cvs/?group_id=4866


-Chuck