Re: "Guest menu commands" not changing the menu line, posted by Steve Jones on Wed Apr 25 19:44:34 2007
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | BTW, WebSVN no longer provides a means of downloading a tar of your code trunk. I had to go to http://midas.psi.ch/elog/download/tar/ in order to get your 2.6.4-1 revision.
|
That should be fixed now.
| Steve Jones wrote: | Ok, here is what I found. Apparently in the past there was a "Find Menu Commands = " option? Because I had this in my config and elog was not barfing on it being there. So, I changed the word "Find" with "List" and things seems to now work. Stefan, was there an old command called "Find Menu Commands"?
|
Yes. Indeed this was changes some time ago. Have a look at elog:880. Unfortunately I did not announce this change clearly. |
| Quote: |
Ok, I am fixed now (took me awhile to respond - sorry).
Thanks Stefan!
|
|
Too many logbooks during user registration, posted by Steve Jones on Mon Aug 6 17:43:52 2007
|
Stefan, we require registration with elog. We have quite a number of logbooks and when someone requests a login account AND elects to register with all of the logbooks, the resulting URL is apparently too long for browsers to handle when the admins click on the link embedded in the email notification. For example, FireFox (latest ver) appears to truncate the URL *after* submission (the correct URL is there before submission).
My question: Is it possible to limit - or remove - the checkboxes that the user can select during registration? I realize that this is a browser issue but I doubt I can persuade those guys to fix FireFox.
Thanks. |
Re: Too many logbooks during user registration, posted by Steve Jones on Tue Sep 11 15:30:11 2007
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | Stefan, we require registration with elog. We have quite a number of logbooks and when someone requests a login account AND elects to register with all of the logbooks, the resulting URL is apparently too long for browsers to handle when the admins click on the link embedded in the email notification. For example, FireFox (latest ver) appears to truncate the URL *after* submission (the correct URL is there before submission).
My question: Is it possible to limit - or remove - the checkboxes that the user can select during registration? I realize that this is a browser issue but I doubt I can persuade those guys to fix FireFox.
Thanks. |
I changed the current SVN version (#1909) to show only the list of logbooks if there are ten or less logbooks, in order not to make the URL too long. On the activation by the administrator, the list of subscribed logbooks appears as previously, but all are unchecked. So it's the task of the administrator to enable subscriptions or not. |
| Quote: | So the list is shown to the one requesting the registration? Would it be possible to have an option that, when selected, simply did not list any logbooks? I can see a customer becoming confused if they did not see their logbook listed. Just turn off the selection completely. Otherwise, this will work but I fear will generate more questions as in "Why isn't logbook <blah> listed?"
Thanks!
|
|
external authentication possible?, posted by Steve Allen on Mon Dec 6 02:34:32 2004
|
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 |
Re: external authentication possible?, posted by Steve Allen on Tue Dec 7 01:18:14 2004
|
> > > 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! |
LDAP docs, posted by Stephen G on Thu Jun 4 00:08:56 2015
|
Could someone point me to the LDAP configuration docs, I searched to no avail. I'm sure there is some big red ldap config button it, but I just can't find it. |
|
Duplicate: LDAP docs, posted by Stephen G on Thu Jun 4 00:10:32 2015
|
This is a duplicate, made by mistake.
Could someone point me to the LDAP configuration docs, I searched to no avail. I'm sure there is some big red ldap config button it, but I just can't find it. |
|
Re: LDAP docs, posted by Stephen G on Thu Jun 4 19:36:31 2015
|
Thank you, I am looking to do LDAPS over 636 where would the certificate go (Does it go in the SSL folder?).
| David Wallis wrote: |
|
This is what I've been able to figure out, in terms of the elogd.cfg file:
LDAP server = server.domain:389
LDAP userbase = ou=people,o=domain.com,dc=domain,dc=com
LDAP login attribute = uid
LDAP register = 0
| Stephen G wrote: |
|
Could someone point me to the LDAP configuration docs, I searched to no avail. I'm sure there is some big red ldap config button it, but I just can't find it.
|
|
|
|