Well I sort have run out of time on this for the moment. I hope to
come back to it
in a month or so.

I love the sage idea and what has been put together so far is VERY
impressive.
Unfortunately the warts from the developer side,
are fairly daunting to me. I have some experience with Django, and
some
other web frameworks. I really wish the web server portion of sage
could be factored out. LDAP
authentication, as well as web templates, session management, and
forms, are well handled by other software
frameworks. Not that there is anything fundamentally wrong with
twisted, or zope for that matter.
It just from the web application side, twisted is fairly low level and
building ones one
web application framework from the ground up from twisted is highly
non-trivial.

Yes, yes, it is easy to criticize and whats really needed is energy
and effort... well
I hope to try some more... but the structure of the files makes it
very difficult
to follow. When one only has a limited amount of time to contribute it
is really
depressing spending 9/10 ths of it just trying to figure out what
calls
what. Ideally it would be nice to make a small patch as you suggest
but
I don't see how. Every tweak I make breaks something else. Perhaps if
I knew how it was all connected a small patch would be possible. I
don't, and
trial and error is very inefficient.

On Jul 21, 12:30 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 20, 2008 at 11:01 PM, Michael_D_G <[EMAIL PROTECTED]> wrote:
>
> > Dear William or anyone....
>
> > I tried to unify the objects in user_db and users and let the
> > passwords proxy ldap if they are
> > not the default users (which could use the basic hash+salt method). I
> > ran into this odd problem
> > that on startup it was trying to set a non-existent admin with the
> > password. On some
> > investigation I ran across the part of run_notebook.py quoted below
> > which I just don't understand.
> > How does it ever get to the else branch???
>
> That code looks to me like it is just crap.   I'm not insulting
> anybody by saying
> that since I wrote that code.  I would like to strongly encourage you
> (Michael D. G.)
> to take a clean copy of Sage, change just that code by say getting rid of the
> else, test things out, make a patch, and submit it for inclusion in sage.  
> This
> is a hopefully simple straightforward task and will give you a sense for the
> sage project's workflow (plus you get your name in big red lights as a
> contributor).
>
>  -- William
>
>
>
> >http://www.sagemath.org/hg/sage-main/file/f1f9a0884cdf/sage/server/no...
> > The tabbing seems to have go lost here.
>
> > 103 if not nb.user_exists('admin'):
> > 104 reset = True
> > 105
> > 106 if reset:
> > 107 passwd = get_admin_passwd()
> > 108 if reset:
> > 109 nb.user('admin').set_password(passwd)
> > 110 print "Password changed for user 'admin'."
> > 111 else:
> > 112 nb.create_default_users(passwd)
> > 113 print "User admin created with the password you specified."
> > 114 print "\n\n"
> > 115 print "*"*70
> > 116 print "\n"
> > 117 if secure:
> > 118 print "Login to the SAGE notebook as admin with the password you
> > specified above."
> > 119 #nb.del_user('root')
>
> > On Jul 18, 3:43 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> >> On Fri, Jul 18, 2008 at 2:17 PM, Michael_D_G <[EMAIL PROTECTED]> wrote:
>
> >> > Thanks so much William!
>
> >> > No I am not talking about the worksheets but the notebook.
> >> > What confused me was that a UserDatabase looked like
> >> > the place were all the users were being stored. I saw user.py
> >> > but that doesn't have a container class. There is clearly some
> >> > redundancy between UserRecord and User.
>
> >> > What you seem to be saying is that rather than
> >> > put my effort into user_db.py, I should be reworking users.py.
>
> >> > What would be nice is to have a single containter class that
> >> > holds the user information. I sort of started in this direction
> >> > by making UserDatabase subclass dict. The password,
> >> > rather than actually being a string or hash is its own
> >> > class. That subclasses the new-style "object" class.
>
> >> > The thing is we can override the __eq__ method. This
> >> > means that when you check if two password objects
> >> > are equal you can use what ever authentication
> >> > method the system is configured to use. This
> >> > pushes all the complication for authentication
> >> > away from the notebook (which probably
> >> > shouldn't have it) and into classes for
> >> > managing user information.
>
> >> > A first draft (messy prototype):
>
> >> > class UserRecord(object):
> >> >    def __init__(self, username, passwd=None, email=None):
> >> >        self.username = username
> >> >        self.passwd = LDAP_Password(username,passwd)
> >> >        self.email = email
>
> >> > class LDAP_Password(object):
> >> >    def __init__(self, username,passwd):
> >> >        self.uid = username
> >> >        if passwd:
> >> >            valid =
> >> > authenticate_uid(base,server_ip,server_port,self.uid,passwd)
> >> >            if valid:
> >> >                #cache password
> >> >                self.passwd=passwd
> >> >            else:
> >> >                self.passwd=None
> >> >        else:
> >> >            self.passwd=None
> >> >    def __eq__(self,passwd):
> >> >        # Allows checking against either a string
> >> >        # or another LDAP_Password
> >> >        # object.
> >> >        if type(self)==type(passwd):
> >> >            pw=passwd.passwd
> >> >        else:
> >> >            pw = passwd
> >> >        #Password never checked
> >> >        if self.passwd == None:
> >> >            valid =
> >> > authenticate_uid(base,server_ip,server_port,self.uid,pw)
> >> >            if valid:
> >> >                self.passwd=pw
> >> >        return str(self.passwd).__eq__(pw)
> >> >    def __repr__(self):
> >> >        # Really insecure
> >> >        return str(self.passwd)
>
> >> > One thing I am not happy about is that I am implicitly using this as a
> >> > caching method. If
> >> > the plain text password is authenticated then I store it and use it to
> >> > check instead
> >> > of theldap. More properly the caching mechanism should be at least
> >> > hashing and
> >> > probably pushed into authenticate_uid.
>
> >> Hi,
>
> >> I don't like the really insecure storing of the plain text password at
> >> all; that's
> >> of course terrible since it will get pickled to disk probably.    But I 
> >> like
> >> the design strategy you suggest above, especially overloading __eq__
> >> and improving user.py.  I very very very strongly encourage you to create
> >> one single tiny patch that does something right in this direction and 
> >> submit
> >> it to be reviewed and included in Sage.  It will help you get a sense of
> >> how the Sage workflow goes without biting off more than you can easily
> >> chew.
>
> >>  -- William
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to