Subscriber Classes: Allow for Active Directory / Kerberos usernames

[Rich]

At present there's a simple test against the sid of the user, for example:

if re.match(r'^[^@]+@.+', ticket['reporter']):
    sid, auth, addr = None, 0, ticket['reporter']
else:
    sid, auth, addr = ticket['reporter'], 1, None

This means that any users with a sid like user@… get treated from this point forwards as unauthenticated.

This has disastrous consequences e.g. their email address (in session_attribute) can never be retrieved as the where clause contains 'authenticated = 0'!

[Rich]

For info, TracNotification got around it like this:

"When using apache and mod_kerb for authentication against Kerberos / Active Directory, usernames take the form (username@…). To avoid this being interpreted as an email address, add the Kerberos domain to (ignore_domains)."

[Rich]

Thinking about it, why are the subscriber classes making this decision? They should just encapsulate the functionality required to provide a list of interested parties and leave finding our 'where' the users are to the resolver classes.

Surely, for example, the SessionEmailResolver should be querying the DB with the username (reporter/owner etc.) to find out whether or not there's a matching sid and how to contact them, assuming the username *is* their mail address is a task for the SpecifiedEmailResolver?

[Steffen Hoffmann]

Notice the possible shortcomings of the reported regular expression as well.

And I'm glad, that this is already documented here. +1 for fixing this in the resolver domain, but I'll have to do much more code reading, before I'll attempt to fix this issue. Please be patient and bear with me, or better: Provide some patches for review ("code rules"). This should speed-up a working solution once I've cleared some database issues, that are top-rated for now.

[Ryan J Ollos]

Please upgrade to Trac 1.2, which has integrated the core of AnnouncerPlugin. Please raise the issue on the ​trac:MailingList if you encounter the issue with Trac 1.2.