merge from HEAD

Author: Richard Jones

CHANGES.txt

@@ -10,8 +10,17 @@ Fixed:
   (see doc/upgrading.txt for how to fix in your trackers)
 - after logout, always display tracker home page
 - 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)
+- 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
+- send errors in the web interface to a logfile by default. Use the
+  "debug" multiprocess mode (roundup-server) or the DEBUG_TO_CLIENT var
+  (roundup.cgi) to have the errors appear in your browser
+- fix setgid typo (sf bug 1171346)
 
 
 2005-03-03 0.8.2

cgi-bin/roundup.cgi

@@ -16,12 +16,12 @@
 # BASIS, AND THERE IS NO OBLIGATION WHATSOEVER TO PROVIDE MAINTENANCE,
 # SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
 # 
-# $Id: roundup.cgi,v 1.40 2004-07-27 00:57:17 richard Exp $
+# $Id: roundup.cgi,v 1.40.2.1 2005-04-13 06:11:14 richard Exp $
 
 # python version check
 from roundup import version_check
 from roundup.i18n import _
-import sys
+import sys, time
 
 #
 ##  Configuration
@@ -42,8 +42,9 @@ import sys
 # ROUNDUP_LOG is the name of the logfile; if it's empty or does not exist,
 # logging is turned off (unless you changed the default below). 
 
-# ROUNDUP_DEBUG is a debug level, currently only 0 (OFF) and 1 (ON) are
-# used in the code. Higher numbers means more debugging output. 
+# DEBUG_TO_CLIENT specifies whether debugging goes to the HTTP server (via
+# stderr) or to the web client (via cgitb).
+DEBUG_TO_CLIENT = False
 
 # This indicates where the Roundup tracker lives
 TRACKER_HOMES = {
@@ -211,7 +212,16 @@ except SystemExit:
 except:
     sys.stdout, sys.stderr = out, err
     out.write('Content-Type: text/html\n\n')
-    cgitb.handler()
+    if DEBUG_TO_CLIENT:
+        cgitb.handler()
+    else:
+        out.write(cgitb.breaker())
+        ts = time.ctime()
+        out.write('''<p>%s: An error occurred. Please check
+            the server log for more infomation.</p>'''%ts)
+        print >> sys.stderr, 'EXCEPTION AT', ts
+        traceback.print_exc(0, sys.stderr)
+
 sys.stdout.flush()
 sys.stdout, sys.stderr = out, err
 LOG.close()

doc/customizing.txt

@@ -2,7 +2,7 @@
 Customising Roundup
 ===================
 
-:Version: $Revision: 1.161.2.12 $
+:Version: $Revision: 1.161.2.13 $
 
 .. 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 @@ Before you get too far, it's probably worth having a quick read of the Roundup
 
 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 @@ Tracker Configuration
 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 @@ section "ConfigParser -- Configuration file parser":
 
 __ 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 @@ Section **nosy**
 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 @@ A set of Permissions is built into the security module by default:
 - 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 @@ For the "User" Role, the "classic" tracker defines:
 - 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 @@ Put together, these settings appear in the tracker's ``schema.py`` file::
     # 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)
+    db.security.addPermissionToRole('User', 'View', 'user')
 
-    # 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.
+    # 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 @@ Put together, these settings appear in the tracker's ``schema.py`` file::
     # 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 users are assigned the Roles defined in the config file as:
 - NEW_WEB_USER_ROLES
 - NEW_EMAIL_USER_ROLES
 
+The `users may only edit their issues`_ example shows customisation of
+these parameters.
+
 
 Changing Access Controls
 ------------------------

roundup/scripts/roundup_server.py

@@ -17,11 +17,11 @@
 
 """Command-line script that runs a server over roundup.cgi.client.
 
-$Id: roundup_server.py,v 1.74.2.3 2005-02-19 10:14:16 a1s Exp $
+$Id: roundup_server.py,v 1.74.2.4 2005-04-13 06:11:15 richard Exp $
 """
 __docformat__ = 'restructuredtext'
 
-import errno, cgi, getopt, os, socket, sys, traceback, urllib
+import errno, cgi, getopt, os, socket, sys, traceback, urllib, time
 import ConfigParser, BaseHTTPServer, SocketServer, StringIO
 
 # python version check
@@ -70,6 +70,7 @@ class RoundupRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
     TRACKER_HOMES = {}
     TRACKERS = None
     LOG_IPADDRESS = 1
+    DEBUG_MODE = False
 
     def get_tracker(self, name):
         """Return a tracker instance for given tracker name"""
@@ -116,16 +117,26 @@ def run_cgi(self):
                 self.send_response(400)
                 self.send_header('Content-Type', 'text/html')
                 self.end_headers()
-                try:
-                    reload(cgitb)
+                if self.DEBUG_MODE:
+                    try:
+                        reload(cgitb)
+                        self.wfile.write(cgitb.breaker())
+                        self.wfile.write(cgitb.html())
+                    except:
+                        s = StringIO.StringIO()
+                        traceback.print_exc(None, s)
+                        self.wfile.write("<pre>")
+                        self.wfile.write(cgi.escape(s.getvalue()))
+                        self.wfile.write("</pre>\n")
+                else:
+                    # user feedback
                     self.wfile.write(cgitb.breaker())
-                    self.wfile.write(cgitb.html())
-                except:
-                    s = StringIO.StringIO()
-                    traceback.print_exc(None, s)
-                    self.wfile.write("<pre>")
-                    self.wfile.write(cgi.escape(s.getvalue()))
-                    self.wfile.write("</pre>\n")
+                    ts = time.ctime()
+                    self.wfile.write('''<p>%s: An error occurred. Please check
+                    the server log for more infomation.</p>'''%ts)
+                    # out to the logfile
+                    print 'EXCEPTION AT', ts
+                    traceback.print_exc()
         sys.stdin = save_stdin
 
     do_GET = do_POST = do_HEAD = run_cgi
@@ -405,18 +416,22 @@ def get_server(self):
         """Return HTTP server object to run"""
         # we don't want the cgi module interpreting the command-line args ;)
         sys.argv = sys.argv[:1]
+
         # preload all trackers unless we are in "debug" mode
         tracker_homes = self.trackers()
         if self["MULTIPROCESS"] == "debug":
             trackers = None
         else:
             trackers = dict([(name, roundup.instance.open(home, optimize=1))
                 for (name, home) in tracker_homes])
+
         # build customized request handler class
         class RequestHandler(RoundupRequestHandler):
             LOG_IPADDRESS = not self["LOG_HOSTNAMES"]
             TRACKER_HOMES = dict(tracker_homes)
             TRACKERS = trackers
+            DEBUG_MODE = self["MULTIPROCESS"] == "debug"
+
         # obtain request server class
         if self["MULTIPROCESS"] not in MULTIPROCESS_TYPES:
             print _("Multiprocess mode \"%s\" is not available, "