Mercurial > p > roundup > code
changeset 3276:3124e578db02
Email fixes:
- fix checking of "Email Access" for Anonymous email registration [SF#177057]
- disable "Email Access" for Anonymous by default to stop spam regsitering
users on public trackers
- doc fixes / additions too
| author | Richard Jones <richard@users.sourceforge.net> |
|---|---|
| date | Wed, 13 Apr 2005 03:38:23 +0000 |
| parents | 3e216b862018 |
| children | 3084b07ec266 |
| files | CHANGES.txt doc/customizing.txt roundup/cgi/client.py roundup/mailgw.py templates/classic/schema.py |
| diffstat | 5 files changed, 67 insertions(+), 53 deletions(-) [+] |
line wrap: on
line diff
--- a/CHANGES.txt Thu Apr 07 07:38:29 2005 +0000 +++ b/CHANGES.txt Wed Apr 13 03:38:23 2005 +0000 @@ -17,6 +17,10 @@ - web forms don't create new items if no item properties are set from UI - item creation failed if multilink fields had invalid entries (sf bug 1177602) - fix bdist_rpm (sf bug 1164328) +- fix checking of "Email Access" for Anonymous email registration (sf bug + 1177057) +- disable "Email Access" for Anonymous by default to stop spam regsitering + users on public trackers 2005-03-03 0.8.2
--- a/doc/customizing.txt Thu Apr 07 07:38:29 2005 +0000 +++ b/doc/customizing.txt Wed Apr 13 03:38:23 2005 +0000 @@ -2,7 +2,7 @@ Customising Roundup =================== -:Version: $Revision: 1.176 $ +:Version: $Revision: 1.177 $ .. This document borrows from the ZopeBook section on ZPT. The original is at: http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx @@ -18,7 +18,7 @@ Customisation of Roundup can take one of six forms: -1. `tracker configuration`_ file changes +1. `tracker configuration`_ changes 2. database, or `tracker schema`_ changes 3. "definition" class `database content`_ changes 4. behavioural changes, through detectors_ @@ -58,6 +58,12 @@ The ``config.ini`` located in your tracker home contains the basic configuration for the web and e-mail components of roundup's interfaces. +Changes to the data captured by your tracker is controlled by the `tracker +schema`_. Some configuration is also performed using permissions - see the +`security / access controls`_ section. For example, to allow users to +automatically register through the email interface, you must grant the +"Anonymous" Role the "Email Access" Permission. + The following is taken from the `Python Library Reference`__ (May 20, 2004) section "ConfigParser -- Configuration file parser": @@ -79,11 +85,6 @@ __ http://docs.python.org/lib/module-ConfigParser.html -Configuration variables may be referred to in lower or upper case. In code, -variables not in the "main" section are referred to using their section and -name, so "domain" in the section "mail" becomes MAIL_DOMAIN. The -configuration variables available are: - Section **main** database -- ``db`` Database directory path. The path may be either absolute or relative @@ -282,6 +283,11 @@ You may generate a new default config file using the ``roundup-admin genconfig`` command. +Configuration variables may be referred to in lower or upper case. In code, +variables not in the "main" section are referred to using their section and +name, so "domain" in the section "mail" becomes MAIL_DOMAIN. The +configuration variables available are: + Tracker Schema ============== @@ -740,22 +746,28 @@ - Edit (everything) - View (everything) -Every Class you define in your tracker's schema also gets an Create, Edit -and View Permission of its own. - -The default interfaces define: - -- Web Registration -- Web Access -- Web Roles -- Email Registration -- Email Access +These are assigned to the "Admin" Role by default, and allow a user to do +anything. Every Class you define in your `tracker schema`_ also gets an +Create, Edit and View Permission of its own. The web and email interfaces +also define: + +*Email Access* + If defined, the user may use the email interface. Used by default to deny + Anonymous users access to the email interface. When granted to the + Anonymous user, they will be automatically registered by the email + interface (see also the ``new_email_user_roles`` configuration option). +*Web Access* + If defined, the user may use the web interface. All users are able to see + the login form, regardless of this setting (thus enabling logging in). +*Web Roles* + Controls user access to editing the "roles" property of the "user" class. + TODO: deprecate in favour of a property-based control. These are hooked into the default Roles: - Admin (Create, Edit, View and everything; Web Roles) - User (Web Access; Email Access) -- Anonymous (Web Registration; Email Registration) +- Anonymous (Web Access) And finally, the "admin" user gets the "Admin" Role, and the "anonymous" user gets "Anonymous" assigned when the tracker is installed. @@ -765,10 +777,11 @@ - Create, Edit and View issue, file, msg, query, keyword - View priority, status - View user -- Edit their own record +- Edit their own user record And the "Anonymous" Role is defined as: +- Web interface access - Create user (for registration) - View issue, file, msg, query, keyword, priority, status @@ -784,37 +797,31 @@ # REGULAR USERS # # Give the regular users access to the web and email interface - p = db.security.getPermission('Web Access') - db.security.addPermissionToRole('User', p) - p = db.security.getPermission('Email Access') - db.security.addPermissionToRole('User', p) + db.security.addPermissionToRole('User', 'Web Access') + db.security.addPermissionToRole('User', 'Email Access') # Assign the access and edit Permissions for issue, file and message # to regular users now for cl in 'issue', 'file', 'msg', 'query', 'keyword': - p = db.security.getPermission('View', cl) - db.security.addPermissionToRole('User', p) - p = db.security.getPermission('Edit', cl) - db.security.addPermissionToRole('User', p) - p = db.security.getPermission('Create', cl) - db.security.addPermissionToRole('User', p) + db.security.addPermissionToRole('User', 'View', cl) + db.security.addPermissionToRole('User', 'Edit', cl) + db.security.addPermissionToRole('User', 'Create', cl) for cl in 'priority', 'status': - p = db.security.getPermission('View', cl) - db.security.addPermissionToRole('User', p) + db.security.addPermissionToRole('User', 'View', cl) # May users view other user information? Comment these lines out # if you don't want them to - p = db.security.getPermission('View', 'user') - db.security.addPermissionToRole('User', p) - - # Users should be able to edit their own details. Note that this - # permission is limited to only the situation where the Viewed or - # Edited item is their own. + db.security.addPermissionToRole('User', 'View', 'user') + + # Users should be able to edit their own details -- this permission + # is limited to only the situation where the Viewed or Edited item + # is their own. def own_record(db, userid, itemid): '''Determine whether the userid matches the item being accessed.''' return userid == itemid p = db.security.addPermission(name='View', klass='user', check=own_record, description="User is allowed to view their own user details") + db.security.addPermissionToRole('User', p) p = db.security.addPermission(name='Edit', klass='user', check=own_record, description="User is allowed to edit their own user details") db.security.addPermissionToRole('User', p) @@ -825,35 +832,31 @@ # Let anonymous users access the web interface. Note that almost all # trackers will need this Permission. The only situation where it's not # required is in a tracker that uses an HTTP Basic Authenticated front-end. - p = db.security.getPermission('Web Access') - db.security.addPermissionToRole('Anonymous', p) + db.security.addPermissionToRole('Anonymous', 'Web Access') # Let anonymous users access the email interface (note that this implies # that they will be registered automatically, hence they will need the # "Create" user Permission below) - p = db.security.getPermission('Email Access') - db.security.addPermissionToRole('Anonymous', p) + # This is disabled by default to stop spam from auto-registering users on + # public trackers. + #db.security.addPermissionToRole('Anonymous', 'Email Access') # Assign the appropriate permissions to the anonymous user's Anonymous # Role. Choices here are: # - Allow anonymous users to register - p = db.security.getPermission('Create', 'user') - db.security.addPermissionToRole('Anonymous', p) + db.security.addPermissionToRole('Anonymous', 'Create', 'user') # Allow anonymous users access to view issues (and the related, linked # information) for cl in 'issue', 'file', 'msg', 'keyword', 'priority', 'status': - p = db.security.getPermission('View', cl) - db.security.addPermissionToRole('Anonymous', p) + db.security.addPermissionToRole('Anonymous', 'View', cl) # [OPTIONAL] # Allow anonymous users access to create or edit "issue" items (and the # related file and message items) #for cl in 'issue', 'file', 'msg': - # p = db.security.getPermission('Create', cl) - # db.security.addPermissionToRole('Anonymous', p) - # p = db.security.getPermission('Edit', cl) - # db.security.addPermissionToRole('Anonymous', p) + # db.security.addPermissionToRole('Anonymous', 'Create', cl) + # db.security.addPermissionToRole('Anonymous', 'Edit', cl) Automatic Permission Checks @@ -887,6 +890,9 @@ - NEW_WEB_USER_ROLES - NEW_EMAIL_USER_ROLES +The `users may only edit their issues`_ example shows customisation of +these parameters. + Changing Access Controls ------------------------
--- a/roundup/cgi/client.py Thu Apr 07 07:38:29 2005 +0000 +++ b/roundup/cgi/client.py Wed Apr 13 03:38:23 2005 +0000 @@ -1,4 +1,4 @@ -# $Id: client.py,v 1.212 2005-01-05 22:00:39 richard Exp $ +# $Id: client.py,v 1.213 2005-04-13 03:38:23 richard Exp $ """WWW request handler (also used in the stand-alone server). """ @@ -26,6 +26,7 @@ security.addPermissionToRole('Admin', p) # doing Role stuff through the web - make sure Admin can + # TODO: deprecate this and use a property-based control p = security.addPermission(name="Web Roles", description="User may manipulate user Roles through the web") security.addPermissionToRole('Admin', p)
--- a/roundup/mailgw.py Thu Apr 07 07:38:29 2005 +0000 +++ b/roundup/mailgw.py Wed Apr 13 03:38:23 2005 +0000 @@ -72,7 +72,7 @@ an exception, the original message is bounced back to the sender with the explanatory message given in the exception. -$Id: mailgw.py,v 1.163 2005-02-15 23:45:28 richard Exp $ +$Id: mailgw.py,v 1.164 2005-04-13 03:38:22 richard Exp $ """ __docformat__ = 'restructuredtext' @@ -768,7 +768,8 @@ # Don't create users if anonymous isn't allowed to register create = 1 anonid = self.db.user.lookup('anonymous') - if not self.db.security.hasPermission('Create', anonid, 'user'): + if not (self.db.security.hasPermission('Create', anonid, 'user') + and self.db.security.hasPermission('Email Access', anonid)): create = 0 # ok, now figure out who the author is - create a new user if the
--- a/templates/classic/schema.py Thu Apr 07 07:38:29 2005 +0000 +++ b/templates/classic/schema.py Wed Apr 13 03:38:23 2005 +0000 @@ -124,7 +124,9 @@ # Let anonymous users access the email interface (note that this implies # that they will be registered automatically, hence they will need the # "Create" user Permission below) -db.security.addPermissionToRole('Anonymous', 'Email Access') +# This is disabled by default to stop spam from auto-registering users on +# public trackers. +#db.security.addPermissionToRole('Anonymous', 'Email Access') # Assign the appropriate permissions to the anonymous user's Anonymous # Role. Choices here are:
