> > 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 . . . . 

> > 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.  
> 
> That sounds to me like a great idea. If anybody gets this working, people would be
> grateful if this could be submitted to the "Contributions" section of this forum.

Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
integration up to you, Stefan.  Seems that there would be two roads to go:
1> Move away from standalone and start to rely on Apache
2> Continue with the standalone theme and build in LDAP authentication (which could
also give you groups functions as well). 

I think I would opt for <2>

> > Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
> > integration up to you, Stefan.  Seems that there would be two roads to go:
> > 1> Move away from standalone and start to rely on Apache
> > 2> Continue with the standalone theme and build in LDAP authentication (which could
> > also give you groups functions as well). 
> > 
> > I think I would opt for <2>
> 
> <1> would only make sense if the functionality could be completely implemented inside
> Apache, without (much) modification of elog. Otherwise I agree that <2> would be more
> following the general lines of elog. I was considering to implement PAM (pluggable
> authorization module) support into elog, which is quite easy to implement and gives you
> to power of having LDAP, Kerberos, Unix username, Windows NT Domain and much more. But
> that would them be restricted to elog running under Linux (and Solaris I guess), since
> I'm not aware of a PAM implementation under Windows.
> 
> Implementing LDAP directly into elog gives me the problem that we don't use LDAP
> authentication at our institute (it's Kerberos in fact). So I would have to set up my own
> LDAP server for testing, plus we at our institute don't have a direct benefit from that,
> which would make it hard for me to justify to spend time on.


Yes, PAM is highly dependent upon Unix and PAM would work under Solaris just fine.  Your
problem lies with Windows - hence my LDAP suggestion.

And LDAP isn't an easy thing to setup, but I bet there is a quick and dirty "test" bench that
could be rigged using OpenLDAP.  Like I indicated, I'll see what I can dig up on this front -
but I make no promises wrt delivery time!

What is the recommended version of gcc to use with elog 2.5.9?  I searched
the discussion database but found nothing pertaining to this. 

Thanks  

> > What is the recommended version of gcc to use with elog 2.5.9?  I searched
> > the discussion database but found nothing pertaining to this. 
> 
> Well, the same code compiles on gcc and on Visual C++ under Windows, so
> hopefully there is no dependence on the gcc version (;-)
> 
> I use gcc 3.2.3 on Scientific Linux 3.03.

I ask because I get a dependency that I did not have before with 2.5.3. 
Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.

> > I ask because I get a dependency that I did not have before with 2.5.3. 
> > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> 
> mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> into a separate directory:
> 
> ...
> -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> 
> I have right now no access to 3.4. Once I get it, I will address the errors
> occuring there.

Ah, now I need to figure out how to pickup the new includes.  
BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
trying an alternative version and it is likely that the way ours is configured is the
problem.

Thanks!

> > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > 
> > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > into a separate directory:
> > 
> > ...
> > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > 
> > I have right now no access to 3.4. Once I get it, I will address the errors
> > occuring there.
> 
> Ah, now I need to figure out how to pickup the new includes.  
> BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> trying an alternative version and it is likely that the way ours is configured is the
> problem.
> 
> Thanks!


Ok, now I see the issue - the tar extract created the mxml directory in the root (not
under the created directory elog-2.5.9).  Is there a reason why these includes are not
placed in the src dir like the regex.h/.c include?

> > > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > > 
> > > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > > into a separate directory:
> > > 
> > > ...
> > > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > > 
> > > I have right now no access to 3.4. Once I get it, I will address the errors
> > > occuring there.
> > 
> > Ah, now I need to figure out how to pickup the new includes.  
> > BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> > trying an alternative version and it is likely that the way ours is configured is the
> > problem.
> > 
> > Thanks!
> 
> 
> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9).  Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?


Ack, ok, I moved the includes into src and tried re-compiling -- and received several
"undefined symbol" errors from the linker.  Clearly the libraries cannot be moved into src?