Updating Trac on Windows?

[Josh Santangelo]

I have Trac 1.0.1 installed via the MSI Installer (control panel says "Python 2.7 Trac-1.0.1").

I see there's a 1.0.5 version available now. If I just run that MSI installer, will it do an upgrade? Or is there more to it?

thanks,

-josh

[Ryan Ollos]

On Thu, May 14, 2015 at 4:13 PM, Josh Santangelo <jo...@stimulant.com> wrote:

I have Trac 1.0.1 installed via the MSI Installer (control panel says "Python 2.7 Trac-1.0.1").

I see there's a 1.0.5 version available now. If I just run that MSI installer, will it do an upgrade? Or is there more to it?

Yeah, I think that is essentially it. Note you'll also need to extract static resources and you should stop the web server before the upgrade (if running a web server rather than Trac standalone). Detailed steps can be found here, and I highly suggest to give them a read:

http://trac.edgewall.org/wiki/TracUpgrade#Instructions

1.0.6 was due to be released a few days ago. I will at least get it out by the weekend so you may want to wait until Monday to upgrade.

- Ryan 

[Josh Santangelo]

I ran the 1.0.6 MSI, but it seemed to break LDAP authentication. When I browse to trac I see:

Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\trac\web\api.py", line 559, in send_error
    data, 'text/html')
  File "C:\Python27\lib\site-packages\trac\web\chrome.py", line 1063, in render_template
    template = self.load_template(filename, method=method)
  File "C:\Python27\lib\site-packages\trac\web\chrome.py", line 1017, in load_template
    self.get_all_templates_dirs(), auto_reload=self.auto_reload,
  File "C:\Python27\lib\site-packages\trac\web\chrome.py", line 725, in get_all_templates_dirs
    for provider in self.template_providers:
  File "C:\Python27\lib\site-packages\trac\core.py", line 78, in extensions
    components = [component.compmgr[cls] for cls in classes]
  File "C:\Python27\lib\site-packages\trac\core.py", line 204, in __getitem__
    component = cls(self)
  File "C:\Python27\lib\site-packages\trac\core.py", line 140, in __call__
    self.__init__()
  File "build\bdist.win32\egg\acct_mgr\web_ui.py", line 75, in __init__
    self._write_check(log=True)
  File "build\bdist.win32\egg\acct_mgr\web_ui.py", line 79, in _write_check
    writable = self.acctmgr.get_all_supporting_stores('set_password')
  File "build\bdist.win32\egg\acct_mgr\api.py", line 348, in get_all_supporting_stores
    for store in self.password_stores:
  File "C:\Python27\lib\site-packages\trac\config.py", line 777, in __get__
    option=tag.tt("[%s] %s" % (self.section, self.name))))
ConfigurationError: Cannot find implementation(s) of the <tt>IPasswordStore</tt> interface named <tt>LdapAuthStore</tt>. Please check that the Component is enabled or update the option <tt>[account-manager] password_store</tt> in trac.ini.

I backed up my Python directory before the install, and restoring it seems to have restored things back to working.

[RjOllos]

Trac 1.0.2 and later enforces that Components specified in the trac.ini configuration file must be loaded. Often users find that when upgrading they had errors in their configuration that passed silently prior to the upgrade.

Your [account-manager] password_store setting includes LdapAuthStore, but the plugin is either not installed, not loading correctly due to an error, or not enabled. LdapAuthStore is provided by LdapAuthStorePlugin (1). Perhaps you aren't actually using that store? In that case you can just removed LdapAuthStore from password_store. But if you are using the plugin, and the plugin is installed and enabled, then we need to determine why it's not loading. See TracTroubleshooting (2). It would also be useful to confirm, before trying the upgrade again, if it is loading in Trac 1.0.2. You can do that by inspecting the debug level log, as described in TracTroubleshooting.

(1) https://trac-hacks.org/wiki/LdapAuthStorePlugin

(2) http://trac.edgewall.org/wiki/TracTroubleshooting#ChecktheLogs

[Josh Santangelo]

Thanks, it seems your suspicions about the plugin not loading are correct, according to the log, which I’ve pasted below. I’m confused though, since LDAP authentication does work, and has for some time. How’s that possible if the plugin isn’t loading? I confirmed that the .egg files in the log are indeed there.

2014-04-01 11:22:27,046 Trac[env] INFO: -------------------------------- environment startup [Trac 1.0.1] --------------------------------
2014-04-01 11:22:27,079 Trac[loader] DEBUG: Adding plugin LdapAuthStorePlugin 0.3.0 from c:\trac\stimulant\plugins\ldapauthstoreplugin-0.3.0-py2.7.egg
2014-04-01 11:22:27,079 Trac[loader] DEBUG: Adding plugin LdapPlugin 0.7.0dev from c:\trac\stimulant\plugins\ldapplugin-0.7.0dev-py2.7.egg
2014-04-01 11:22:27,174 Trac[loader] DEBUG: Loading ldapauthstore.ldap_store from c:\trac\stimulant\plugins\ldapauthstoreplugin-0.3.0-py2.7.egg
2014-04-01 11:22:27,181 Trac[loader] ERROR: Skipping "ldapauthstore.ldap_store = ldapauthstore.ldap_store": 

Traceback (most recent call last):

  File "C:\Python27\lib\site-packages\trac\loader.py", line 68, in _load_eggs
    entry.load(require=True)
  File "C:\Python27\lib\site-packages\setuptools-0.6c11-py2.7.egg\pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build\bdist.win32\egg\ldapauthstore\ldap_store.py", line 2, in <module>
  File "build\bdist.win32\egg\ldapplugin\__init__.py", line 2, in <module>
  File "build\bdist.win32\egg\ldapplugin\api.py", line 25, in <module>
ImportError: No module named ldap
2014-04-01 11:22:27,181 Trac[loader] DEBUG: Loading ldapplugin.api from c:\trac\stimulant\plugins\ldapplugin-0.7.0dev-py2.7.egg
2014-04-01 11:22:27,187 Trac[loader] ERROR: Skipping "ldapplugin.api = ldapplugin.api": 

Traceback (most recent call last):

  File "C:\Python27\lib\site-packages\trac\loader.py", line 68, in _load_eggs
    entry.load(require=True)
  File "C:\Python27\lib\site-packages\setuptools-0.6c11-py2.7.egg\pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build\bdist.win32\egg\ldapplugin\__init__.py", line 2, in <module>
  File "build\bdist.win32\egg\ldapplugin\api.py", line 25, in <module>
ImportError: No module named ldap

[Ryan Ollos]

It looks like it's not finding the Python ldap package. You might be able to install that from pypi.

https://pypi.python.org/pypi/python-ldap

[Cooke, Mark]

> -----Original Message-----
> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On
> Behalf Of Ryan Ollos
>
> It looks like it's not finding the Python ldap package. You might be able to
> install that from pypi.
>
> https://pypi.python.org/pypi/python-ldap

Hmm, I think we would be better to understand how LDAP auth is working
before fixing something that it looks like is not needed.

Are you using apache httpd? I use Trac on Windoze and use apache to
authenticate against our AD forest, perhaps you do the same? In which
case you do not need the Trac ldap interface at all...

~ mark c

[RjOllos]

Does the Apache configuration you use populate the session info such as name and email address from the LDAP data store?

- Ryan 

[Josh Santangelo]

Yes, I’m using Apache on Windows. I believe the original configuration was based on the docs here:

https://trac-hacks.org/wiki/LdapPlugin

httpd.conf looks something like:

<Location />

    Order deny,allow

    Allow from all

    AuthType Basic

    AuthName "Stimulant Trac"

    AuthBasicProvider "ldap"

    AuthLDAPURL "ldap://…"

    AuthLDAPBindDN ...@stimulant.local

    AuthLDAPBindPassword “..."

    authzldapauthoritative Off

    require ldap-group CN=Stimulant Devops,CN=Users,DC=stimulant,DC=local

</Location>

trac.ini looks something like:

[ldap]

allusers_group = Stimulant Devops

basedn = dc=stimulant,dc=local

bind_passwd = ...

bind_user = cn=trac,dc=stimulant,dc=local

enable = true

group_rdn = ou=groups

host = ...

store_bind = true

user_rdn = ou=people

Mark raises a good point, perhaps I should use LDAP in Apache but not at all in Trac?

Thanks again for the thoughtful responses.

[Cooke, Mark]

> On May 26, 2015, at 12:09 PM, RjOllos <rjo...@gmail.com> wrote:
>
> On Tuesday, May 26, 2015 at 2:26:31 AM UTC-4, Cooke, Mark wrote:
>
> > On May 22, 2015 3:02 PM, "Josh Santangelo"

> <jo...@stimulant.com <javascript:> > wrote:
> > >
> > >
> > >> On May 21, 2015, at 8:53 PM, RjOllos <rjo...@gmail.com

> > >>> option=tag.tt <http://tag.tt/> ("[%s] %s" %
> (self.section, self.name <http://self.name/> ))))

This is definitely providing _authentication_ against LDAP as well as _authorisation_ in that httpd will reject users not in the specified group. What this does is pass the user info through to Trac in the session info (based on the parameters specified in the LDAP URL which can include the user's email).

If you only need to _authorise_ users based on LDAP group membership you are done. Do all members of "Stimulant Devops" (via the built-in "authenticated" group) have the same rights or do you need finer grained permissions?

> trac.ini looks something like:
>
> [ldap]
> allusers_group = Stimulant Devops
> basedn = dc=stimulant,dc=local
> bind_passwd = ...
> bind_user = cn=trac,dc=stimulant,dc=local
> enable = true
> group_rdn = ou=groups
> host = ...
> store_bind = true
> user_rdn = ou=people

Trac is repeating work done (probably more efficiently) by httpd.

As I only have a small number of users per repository I manage those special cases through the usual Trac Admin interface (no plugins required) using their network login names, forced to lower case. Personally I would remove this plugin and the section from trac.ini.

> Mark raises a good point, perhaps I should use LDAP in Apache but not at all
> in Trac?
>
> Thanks again for the thoughtful responses.

I hope I have been helpful. Good luck.

~ Mark C

[Josh Santangelo]

I removed the plugin from trac.ini and authorization still seemed to work.

I redid the upgrade to 1.0.6 by switching my c:\python27 to the state it was in after running the MSI. After restarting the server I saw the same error as before rendered into the browser (Cannot find implementation(s) of the <tt>IPasswordStore</tt> interface named <tt>LdapAuthStore</tt>).

I commented out password_store = LdapAuthStore from trac.ini.

Trac pages now load, but at the top it says "Error with navigation contributor AccountModule”

The footer also still says 1.0.1.

I re-ran the MSI installer, but it didn’t change anything.

[Josh Santangelo]

The trac-admin command line output says it’s 1.0.6.post2, though.

trac/about shows:

Trac 1.0.1
Genshi 0.7 (without speedups)
mod_wsgi 3.5 (WSGIProcessGroup WSGIApplicationGroup Trac.stimulant.local|)
psycopg2 2.5.2
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
setuptools 0.6c11
jQuery 1.7.2
jQuery UI 1.8.21
jQuery Timepicker 1.0.1

[RjOllos]

It seems that the egg loaded by the web server is different than the one you find on your path when running trac-admin.

The most obvious thing to check is that the Apache web server has been restarted. After that, I would check the Apache web server configuration files. The "WSGIDaemonProcess" directive may have a "python-path" that points to another Python installation.

- Ryan

[Josh Santangelo]

The server has definitely been restarted.

The only thing in httpd.conf that seems relevant is:

WSGIScriptAlias / C:\Apache\cgi-bin\trac.wsgi

There is no “WSGIDaemonProcess” and python isn’t even mentioned in the Apache config files.

That file exists and contains:

def application(environ, start_request):

    if not 'trac.env_parent_dir' in environ:

        environ.setdefault('trac.env_path', 'c:\\trac\\stimulant')

    if 'PYTHON_EGG_CACHE' in environ:

        os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']

    elif 'trac.env_path' in environ:

        os.environ['PYTHON_EGG_CACHE'] = \

            os.path.join(environ['trac.env_path'], '.egg-cache')

    elif 'trac.env_parent_dir' in environ:

        os.environ['PYTHON_EGG_CACHE'] = \

            os.path.join(environ['trac.env_parent_dir'], '.egg-cache')

    from trac.web.main import dispatch_request

    return dispatch_request(environ, start_request)

The only python install on the path is c:\python27 and c:\python27\scripts. c:\python27\scripts\tracd.exe and trac-admin exist, and report being 1.0.6.

I suspect you’re right, it’s loading the wrong thing, or loading a cached thing, but I’m not sure where to look for the thing.

I see the C:\Users\trac\AppData\Roaming\Python-Eggs and C:\trac\stimulant\.egg-cache directories, but they seem to only contain plugins, not trac itself.

thanks again,

-josh

[RjOllos]

On Monday, June 1, 2015 at 4:35:47 PM UTC-5, Josh Santangelo wrote:

The server has definitely been restarted.

The only thing in httpd.conf that seems relevant is:

WSGIScriptAlias / C:\Apache\cgi-bin\trac.wsgi

There is no “WSGIDaemonProcess” and python isn’t even mentioned in the Apache config files.

That file exists and contains:

def application(environ, start_request):

    if not 'trac.env_parent_dir' in environ:

        environ.setdefault('trac.env_path', 'c:\\trac\\stimulant')

    if 'PYTHON_EGG_CACHE' in environ:

        os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']

    elif 'trac.env_path' in environ:

        os.environ['PYTHON_EGG_CACHE'] = \

            os.path.join(environ['trac.env_path'], '.egg-cache')

    elif 'trac.env_parent_dir' in environ:

        os.environ['PYTHON_EGG_CACHE'] = \

            os.path.join(environ['trac.env_parent_dir'], '.egg-cache')

    from trac.web.main import dispatch_request

    return dispatch_request(environ, start_request)

The only python install on the path is c:\python27 and c:\python27\scripts. c:\python27\scripts\tracd.exe and trac-admin exist, and report being 1.0.6.

I suspect you’re right, it’s loading the wrong thing, or loading a cached thing, but I’m not sure where to look for the thing.

I see the C:\Users\trac\AppData\Roaming\Python-Eggs and C:\trac\stimulant\.egg-cache directories, but they seem to only contain plugins, not trac itself.

thanks again,

-josh

If you set the log level to DEBUG and restart the web server you should be able to see in the log where the components are being loaded from. For example, running TracStandalone, I see the following at the start of the log:

10:48:02 Trac[loader] DEBUG: Loading trac.about from /Users/rjollos/Documents/Workspace/plugin-dev/pve/lib/python2.7/site-packages/Trac-1.0.7.dev0-py2.7.egg

10:48:02 Trac[loader] DEBUG: Loading trac.admin.console from /Users/rjollos/Documents/Workspace/plugin-dev/pve/lib/python2.7/site-packages/Trac-1.0.7.dev0-py2.7.egg

 

[Josh Santangelo]

I deleted C:\Python27\Lib\site-packages\Trac-1.0.1-py2.7.egg-info, which seemed to force it to pick up 1.0.6 from Trac-1.0.6.post2-py2.7.egg-info.

I made the "Error with navigation contributor AccountModule” go away by disabling acct_mgr.web_ui.accountmodule.

So… I think everything is good now!

I think the lesson is for the next upgrade, to run the MSI and delete any old things in site-packages.

-- 
S T I M U L Λ N T
Josh Santangelo, Technical Director
P 415 363 0336 / HQ 415 255 7081 / T @stimulant

[Ryan Ollos]

On Tue, Jun 2, 2015 at 11:17 AM, Josh Santangelo <jo...@stimulant.com> wrote:

I made the "Error with navigation contributor AccountModule” go away by disabling acct_mgr.web_ui.accountmodule.

This brings up a related question I've had about using LDAP through Apache, rather than using LdapPlugin and LdapAuthStorePlugin. My earlier question that I haven't determined the answer to is whether it is possible to populate the session info such as name and email address from the LDAP data store when using an Apache LDAP configuration. Similarly, does AccountManagerPlugin have any useful function if using LDAP through Apache?

- Ryan

[RjOllos]

Hello Mark,

I read through this thread again and spotted a statement by you that I had previously overlooked,

> What this does is pass the user info through to Trac in the session info (based on the parameters specified in the LDAP URL which can include the user's email). 

I currently have an AuthLDAPURL that ends in the following.

/ou=<GroupName>,dc=<domain>,dc=com?sAMAccountName 

Could you give an example of how I would modify this to pull the user name and email address from LDAP to populate the session? Will the session info be populated and saved on every successful authentication? What I mean is, with the proper AuthLDAPURL, if I clear the username and email from the /prefs page, close the browser and authenticate again, should the username and email be immediately populated?

Thanks,

- Ryan

[Cooke, Mark]

> -----Original Message-----
> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On

> Behalf Of RjOllos
>
> On Tuesday, June 2, 2015 at 9:23:58 AM UTC-7, RjOllos wrote:
>
> On Tue, Jun 2, 2015 at 11:17 AM, Josh Santangelo <jo...@stimulant.com>
> wrote:
>
> I made the "Error with navigation contributor AccountModule” go
> away by disabling acct_mgr.web_ui.accountmodule.
>
>
> This brings up a related question I've had about using LDAP through
> Apache, rather than using LdapPlugin and LdapAuthStorePlugin. My earlier
> question that I haven't determined the answer to is whether it is possible to
> populate the session info such as name and email address from the LDAP data
> store when using an Apache LDAP configuration. Similarly, does
> AccountManagerPlugin have any useful function if using LDAP through Apache?
>
>
> - Ryan
>
> Hello Mark,
>
> I read through this thread again and spotted a statement by you that I had
> previously overlooked,
>
> > What this does is pass the user info through to Trac in the session info
> (based on the parameters specified in the LDAP URL which can include the
> user's email).
>
> I currently have an AuthLDAPURL that ends in the following.
>
> /ou=<GroupName>,dc=<domain>,dc=com?sAMAccountName

Sorry for slightly misleading you, it is a while since I set this up here.

There are two parts to this (a) getting the data back from LDAP and
(b) getting Trac to use that data...

For (a) you can edit your LDAPURL to something like:

...DC=net?sAMAccountName,mail?sub?(objectClass=*)

i.e. you can specify a comma-separated list of attributes. Authentication
relies only on the first specified item (e.g. sAMAccountName usually) but I
found that mod_wsgi passes all retrieved attributes through to the python
app (see #1 for some test code):

AUTHENTICATE_MAIL: 'my....@address.com'
AUTHENTICATE_SAMACCOUNTNAME: 'my-user-id'

...i.e. the attributes are available as AUTHENTICATE_<ATTR>

I have not solved (b) as I was not confident to hack into the Trac code but
I do not think it would be too difficult to check for the presence of these
WSGI session values in the relevant place (I think they all started WSGI_
but will have to have another look).

Note that simply logging in is not usually enough to get the session data
updated ~ I have a local macro to list "authenticated" users and people do
not tend to appear until they have "done something" like edit a wiki page.

If I get some time I will try to poke at this again as it would be useful
for me too. Any pointers of where to look in Trac source would be
appreciated!

~ Mark C

[1] https://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment

> Could you give an example of how I would modify this to pull the user name
> and email address from LDAP to populate the session? Will the session info be
> populated and saved on every successful authentication? What I mean is, with
> the proper AuthLDAPURL, if I clear the username and email from the /prefs
> page, close the browser and authenticate again, should the username and email
> be immediately populated?
>
>
> Thanks,
> - Ryan
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to trac-users+...@googlegroups.com.
> To post to this group, send email to trac-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/trac-users.
> For more options, visit https://groups.google.com/d/optout.

[Cooke, Mark]

I just wrote a quick macro to display the LDAP attributes available from the Request object (see below).

Running this shows that, at least on my setup, I get both `AUTHENTICATE_MAIL` and `AUTHORIZE_MAIL` set with my email, I am not sure where the latter comes from.

Also, [1] states that `formatter.req` is "(to be deprecated)" but does not say how else to get at the data? This is my biggest gripe with python code is that it can be difficult to work out how to get to the data I want.

[1] http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.wiki.api.IWikiMacroProvider

Cheers,

~ Mark C

{{{
# -*- coding: utf-8 -*-
#
# With help from https://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment
"""Trac Macro to list a session's WSGI environment."""

from trac.core import *
from trac.wiki.formatter import format_to_html
from trac.wiki.macros import WikiMacroBase

class WsgiEnvMacro(WikiMacroBase):
"""Produces a table of Key: Value pairs from the WSGI request environment
variables.

Usage:
{{{
[[WsgiEnv]]
}}}
"""
def expand_macro(self, formatter, name, content):
dt = "||'''Attribute'''||'''Value'''||\n"
# the current Request is available as formatter.req
wenv = formatter.req.environ
keys = wenv.keys()
keys.sort()
for k in keys:
dt += "|| `%s` || %s ||\n" % (str(k), str(wenv[k]))

content = format_to_html(self.env, formatter.context, dt)
content = '<div class="component-list">%s</div>' % content
return content
}}}

[RjOllos]

On Tuesday, June 2, 2015 at 11:07:45 PM UTC-7, Cooke, Mark wrote:

Sorry for slightly misleading you, it is a while since I set this up here.

There are two parts to this (a) getting the data back from LDAP and
(b) getting Trac to use that data...

For (a) you can edit your LDAPURL to something like:

...DC=net?sAMAccountName,mail?sub?(objectClass=*)

i.e. you can specify a comma-separated list of attributes.  Authentication
relies only on the first specified item (e.g. sAMAccountName usually) but I
found that mod_wsgi passes all retrieved attributes through to the python
app (see #1 for some test code):

AUTHENTICATE_MAIL: 'my....@address.com'
AUTHENTICATE_SAMACCOUNTNAME: 'my-user-id'

...i.e. the attributes are available as AUTHENTICATE_<ATTR>

Nice. You might find TracDeveloperPlugin useful as well.
https://trac-hacks.org/wiki/TracDeveloperPlugin

Here is a view showing inspection of req.environ:


 

 

 

I have not solved (b) as I was not confident to hack into the Trac code but
I do not think it would be too difficult to check for the presence of these
WSGI session values in the relevant place (I think they all started WSGI_
but will have to have another look).

Note that simply logging in is not usually enough to get the session data
updated ~ I have a local macro to list "authenticated" users and people do
not tend to appear until they have "done something" like edit a wiki page.

If I get some time I will try to poke at this again as it would be useful
for me too.  Any pointers of where to look in Trac source would be
appreciated!

The discussion here might be helpful:
https://trac-hacks.org/ticket/12302#comment:5

Maybe we can grab and save the values in LoginModule. I'd have to investigate further to be more confident.
http://trac.edgewall.org/browser/tags/trac-1.1.5/trac/web/auth.py#L39

It looks like there is an open ticket for this. I'd like to get this resolved for Trac 1.2:
trac.edgewall.org/ticket/7371

I'd also like to write a new TracApache page and consolidate the information on configuring Trac with Apache. LDAP specific configuration info would be included. I'd like to get this included in the Trac 1.2 release and have examples for Apache 2.4 in addition to Apache 2.2.

- Ryan
 

[RjOllos]

On Wednesday, June 3, 2015 at 12:20:48 AM UTC-7, Cooke, Mark wrote:

Also, [1] states that `formatter.req` is "(to be deprecated)" but does not say how else to get at the data?  This is my biggest gripe with python code is that it can be difficult to work out how to get to the data I want.

I've considered while working on #11901 that maybe we should just keep `formatter.req`:
http://trac.edgewall.org/changeset/59383956fea004e4dfd6f33f97c7fa2ad1ac250a/rjollos.git/

However, if it's removed you'd instead use `formatter.context.req`

- Ryan

[Cooke, Mark]

> On Tuesday, June 2, 2015 at 11:07:45 PM UTC-7, Cooke, Mark wrote:
>
> > Sorry for slightly misleading you, it is a while since I set this up
> > here.
> >
> > There are two parts to this (a) getting the data back from LDAP and
> > (b) getting Trac to use that data...
> >
> > For (a) you can edit your LDAPURL to something like:
> >
> > ...DC=net?sAMAccountName,mail?sub?(objectClass=*)
> >
> > i.e. you can specify a comma-separated list of attributes.

> > Authentication elies only on the first specified item

> > (e.g. sAMAccountName usually) but I found that mod_wsgi passes all
> > retrieved attributes through to the python app (see #1 for some
> > test code):
> >

> > AUTHENTICATE_MAIL: 'my....@address.com <javascript:> '

> > AUTHENTICATE_SAMACCOUNTNAME: 'my-user-id'
> >
> > ...i.e. the attributes are available as AUTHENTICATE_<ATTR>
> >
> -----Original Message-----
> From: RjOllos [mailto:rjo...@gmail.com]
> Sent: 03 June 2015 22:58
>
> Nice. You might find TracDeveloperPlugin useful as well.
> https://trac-hacks.org/wiki/TracDeveloperPlugin

Wow, that looks great! I will try that out.

> > I have not solved (b) as I was not confident to hack into the Trac
> > code but I do not think it would be too difficult to check for the
> > presence of these WSGI session values in the relevant place (I think
> > they all started WSGI_ but will have to have another look).
> >
> > Note that simply logging in is not usually enough to get the session
> > data updated ~ I have a local macro to list "authenticated" users and
> > people do not tend to appear until they have "done something" like
> > edit a wiki page.
> >
> > If I get some time I will try to poke at this again as it would be
> > useful for me too. Any pointers of where to look in Trac source
> > would be appreciated!
>
>
> The discussion here might be helpful:
> https://trac-hacks.org/ticket/12302#comment:5

Thanks...

> Maybe we can grab and save the values in LoginModule. I'd have to investigate
> further to be more confident.
> http://trac.edgewall.org/browser/tags/trac-1.1.5/trac/web/auth.py#L39

But I believe that my setup does not use the login module at all, all
authentication is done by httpd. I certainly never use the "login" address...

> It looks like there is an open ticket for this. I'd like to get this resolved
> for Trac 1.2:
> trac.edgewall.org/ticket/7371

That looks exactly like what I was suggesting! I will try to look at his
patch for my setup and get back to you.

> I'd also like to write a new TracApache page and consolidate the information
> on configuring Trac with Apache. LDAP specific configuration info would be
> included. I'd like to get this included in the Trac 1.2 release and have
> examples for Apache 2.4 in addition to Apache 2.2.

I could probably contribute to that too, let me know...

> - Ryan
>

[RjOllos]

On Thursday, June 4, 2015 at 1:14:33 AM UTC-7, Cooke, Mark wrote:

> Maybe we can grab and save the values in LoginModule. I'd have to investigate
> further to be more confident.
> http://trac.edgewall.org/browser/tags/trac-1.1.5/trac/web/auth.py#L39

But I believe that my setup does not use the login module at all, all
authentication is done by httpd.  I certainly never use the "login" address...

Yeah that is a good point. I'll have to study the code further.
 

> I'd also like to write a new TracApache page and consolidate the information
> on configuring Trac with Apache. LDAP specific configuration info would be
> included. I'd like to get this included in the Trac 1.2 release and have
> examples for Apache 2.4 in addition to Apache 2.2.

I could probably contribute to that too, let me know...

Thanks, I'll probably raise a thread on trac-dev later this month to propose reorganization and changes to the documentation. It would certainly benefit from your expertise.

- Ryan

[Cooke, Mark]

> -----Original Message-----
> From: RjOllos [mailto:rjo...@gmail.com]

> Sent: 04 June 2015 20:27
>
> > On Thursday, June 4, 2015 at 1:14:33 AM UTC-7, Cooke, Mark wrote:
> >
> > > Maybe we can grab and save the values in LoginModule. I'd have to
> > > investigate further to be more confident.
> > > http://trac.edgewall.org/browser/tags/trac-1.1.5/trac/web/auth.py#L39
> >
> > But I believe that my setup does not use the login module at all, all
> > authentication is done by httpd. I certainly never use the "login"
> > address...
>
> Yeah that is a good point. I'll have to study the code further.

Something must decide between "login" and "logout" text (although I see
neither as I have `logout=disabled` in my `[metanav]` section in trac.ini),
could be a good place to start (although it must be invoked for every page)?

> > > I'd also like to write a new TracApache page and consolidate the
> > > information on configuring Trac with Apache. LDAP specific
> > > configuration info would be included. I'd like to get this
> > > included in the Trac 1.2 release and have examples for Apache 2.4
> > > in addition to Apache 2.2.
> >
> > I could probably contribute to that too, let me know...
> >
>
> Thanks, I'll probably raise a thread on trac-dev later this month to propose
> reorganization and changes to the documentation. It would certainly benefit
> from your expertise.

"experience" rather than "expertise" but I would be happy to help where I can.
I'm not on dev@, feel free to ping me an email.

~ Mark C

[RjOllos]

On Friday, June 5, 2015 at 2:21:27 AM UTC-7, Cooke, Mark wrote:

"experience" rather than "expertise" but I would be happy to help where I can.
I'm not on dev@, feel free to ping me an email.

~ Mark C

Thanks, I'll CC you on any such posts to trac-dev.