> > > In order to avoid having to remember multiple usernames/passwords for
> > > different systems, is it possible for ELOG to use external authentication
> > > via Active Directory, etc?
> > 
> > Not yet.
> 
> I would note that this is a request that comes in fairly frequently, but to
> Stephan's credit (and looking back at previous comments) the task of trying to
> implement authentication that would *not* be a maintenance nightmare basically
> pushes such a request down to the bottom of the list.
> 
> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication.  One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache.  This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache.  In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.  
> 
> For our twiki (source from twiki.org) website, we use the following config:
> 
> -- In Apache http.conf
> LoadModule auth_ldap_module   libexec/auth_ldap.so
> 
> AddModule auth_ldap.c
> 
> AccessFileName .htaccess
> 
> # Twiki
> Include /proj/www/twiki/conf/httpd.conf
> 
> 
> -- The http.conf in the Twiki directory
> <VirtualHost *>
>         DocumentRoot "/proj/www/twiki/html"
>         ServerName twiki
>         ErrorLog error_log
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName CoreID
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName ID
>                 AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
>                 require valid-user
>                 allow from all
>                 <Limit OPTIONS>
>                         Order Deny,Allow
>                         Deny from all
>                 </LIMIT>
>         </Location>
> </VirtualHost>
> 
> --- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
> the following:
> 
> RedirectPermenant       /       http://twiki.co.com/bin/view.cgi
> 
> --- Also in the /bin directory we have:
> 
> Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi
> 
> AuthType                 Basic
> AuthName                 "LDAP Login"
> AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
> 
> 
> SetHandler cgi-script
> 
> ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth
> 
> <Files ~ "[^/]*\.html$">
>        SetHandler blabla
>        allow from all
> </Files>
> 
> <Files "*">
>        require valid-user
>         allow from all
> </Files>
> -------------------------
> 
> Whether this is at all relevant, well . . . . 

Food for thought--thanks!

> > In order to avoid having to remember multiple usernames/passwords for
> > different systems, is it possible for ELOG to use external authentication
> > via Active Directory, etc?
> 
> Not yet.

I would note that this is a request that comes in fairly frequently, but to
Stephan's credit (and looking back at previous comments) the task of trying to
implement authentication that would *not* be a maintenance nightmare basically
pushes such a request down to the bottom of the list.

The only common denominator that could possibly cover all contingencies would
be LDAP authentication.  One way of doing this in a more-or-less universal
fashion is to offload the auth task from eLog itself and place the burden on
Apache.  This means figuring out how to get Apache to pass auth info to eLog
when eLog operates behind Apache.  In the end, anything that can use LDAP as an
authentication mechanism (like AD) can host eLog - as long as eLog can glom off
of Apache's ability to do the actual authenticating.  

For our twiki (source from twiki.org) website, we use the following config:

-- In Apache http.conf
LoadModule auth_ldap_module   libexec/auth_ldap.so

AddModule auth_ldap.c

AccessFileName .htaccess

# Twiki
Include /proj/www/twiki/conf/httpd.conf


-- The http.conf in the Twiki directory
<VirtualHost *>
        DocumentRoot "/proj/www/twiki/html"
        ServerName twiki
        ErrorLog error_log
        CustomLog access_log combined
        <Directory "/proj/www/twiki/html/bin/">
                Options +ExecCGI
                allow from all
                AllowOverride Authconfig FileInfo Indexes Limit Options
        </Directory>
        <Location /bin>
                Options +ExecCGI
                AuthType Basic
                AuthName CoreID
        CustomLog access_log combined
        <Directory "/proj/www/twiki/html/bin/">
                Options +ExecCGI
                allow from all
                AllowOverride Authconfig FileInfo Indexes Limit Options
        </Directory>
        <Location /bin>
                Options +ExecCGI
                AuthType Basic
                AuthName ID
                AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
                require valid-user
                allow from all
                <Limit OPTIONS>
                        Order Deny,Allow
                        Deny from all
                </LIMIT>
        </Location>
</VirtualHost>

--- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
the following:

RedirectPermenant       /       http://twiki.co.com/bin/view.cgi

--- Also in the /bin directory we have:

Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi

AuthType                 Basic
AuthName                 "LDAP Login"
AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)


SetHandler cgi-script

ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth

<Files ~ "[^/]*\.html$">
       SetHandler blabla
       allow from all
</Files>

<Files "*">
       require valid-user
        allow from all
</Files>
-------------------------

Whether this is at all relevant, well . . . . 

> hi
> the back button/liunk does not work
> if i click on an entry and then back, it does not work properly, i see the 
> same entry
> if i click on the new button or the find button,  and then back, it does 
> not work properly
> mfg guenter

Thanks for reporting that bug, it has been fixed in the curreny CVS version.

> In order to avoid having to remember multiple usernames/passwords for
> different systems, is it possible for ELOG to use external authentication
> via Active Directory, etc?

Not yet.

Have set up 3 top level groups, each with their own password file.
Ever since users have to 'login' twice to get to the appropriate elog.
You click on top level group, get to log book and click on the one you want 
and get login/password dialog box, click ok and and you get it again and 
then you finally get into the elog book.

Anything I can check on this behavior?

hi
the back button/liunk does not work
if i click on an entry and then back, it does not work properly, i see the 
same entry
if i click on the new button or the find button,  and then back, it does 
not work properly
mfg guenter

In order to avoid having to remember multiple usernames/passwords for
different systems, is it possible for ELOG to use external authentication
via Active Directory, etc?

Thanks,
Steve

'Date' attributes can only be between 1970 and 2037, since I use internally the
unix time format. I added a test so future versions will complain and not crash
when the date is outside that range.

If you need dates before 1970, don't use the 'Date' format, simply use strings.