Re: Enhancing Gnotices

["Michael R. Bernstein" <webmaven lvcm com>]

On Tue, 2001-09-11 at 06:16, Steve Fox wrote:
>
> On Tue, 2001-09-11 at 01:33, Michael R. Bernstein wrote:
> >
> > How does Trove store account information? Zope can interface with
> > practically any source of authentication and authorization, though some
> > setups take some more work.
> 
> Trove itself doesn't not store any account information. The
> authentication is done via session.php (or logger.php in CVS
> SourceForge). I wish I could show you only that file, but SF doesn't
> (currently) use CVS on sf.net. See
> http://sourceforge.net/project/showfiles.php?group_id=1&release_id=18242
> for a download.
> 
> Basically I think you will need to just write some code to interface
> with the users table. It's rather trivial and you could end up putting a
> function call to check for login status on each page that needs it.
>
> e.g. SF pages have : session_require (array(isloggedin=>1));

Zope doesn't work quite like that. Zope has a fairly well developed
access control list implementation, but doesn't insist on the
authentication and authorization info being stored inside the ODB.

Basically, we'll install an SQL acl_users folder object that will get
the usernames and passwords from the RDBMS (which does Trove use?), and
optionally assign roles to those users also from info in the RDBMS.

<pedantic_speech>
In Zope, access to resources (objects and their methods) is assigned to
roles, so that a user will only be able to access those resources that
they have roles for. this is all built in, so you don't actually have to
code security for your application.

Zope has four default roles: Anonymous, Authenticated, Manager, and
Owner.

Anonymous is the default role, and typically has viewing priveleges. You
can always remove viewing permissions for the Anonymous role in order to
require logging in to view it. No code needs to be added to the actual
page in order to do this.

Authenticated is a special role that is basically the inverse of
Anonymous, and typically doesn't have any permissions assigned to it. it
basically exists so you can easily test whether the user is logged in
(kind of like the code you had).

Manager is a role that typically has *all* permissions (including
modification and deletion). This is not one to give lightly to a user,
even if they only have it as a local role on some object.

Owner is another special role. It is granted as a local role on an
object to that object's creator, and is used to limit what that *object*
can do when accessed by someone else. Basically, an object can only
perform operations that both it's owner *and* the user who is accessing
it have permissions for. This is to prevent server-side trojan attacks,
when you allow untrusted users to create executable code.
</pedantic_speech>

I'm guessing that we may want to create a custom role of Developer, and
assign appropriate permissions.

What is the table structure that Trove uses to store user authentication
and authorization in the RDBMS?

> > > I'm currently working on listing the projects in the Software
> > > Map. Next is listing their latest releases in the File Release System.
> > 
> > Is this is what will be exposed via RSS?
> 
> The last updated projects will be exposed. I'm sure we could export any
> other data we desire with little problem.

Great!

Michael Bernstein.