With elog it is possible to submit messages to a password protected
logbook without specifying the -u option.  I.e. NO PASSWORD is
necessary to submit a message.  I assume it is related to the problem
of expiring password-cookies while entering the message using a web
browser.

> > With elog it is possible to submit messages to a password protected
> > logbook without specifying the -u option.  I.e. NO PASSWORD is
> > necessary to submit a message.  I assume it is related to the problem
> > of expiring password-cookies while entering the message using a web
> > browser.
> 
> Indeed this problem is related to the expiring password cookies. As a 
> reminder: For the submission of a new entry, the password is checked when
one 
> presses the "New" button, but NOT for the "submit". This is because a 
> password can expire between the "New" and the "Submit", so a entered message 
> could not be sent. The question is now what to do with the standalone
"elog".
> 
> Right now, elog does a normal submission where the password is not checked, 
> which is maybe not what one wants. But what to do? If elog sends a special 
> flag "please do check password on submit", someone could analyze the source 
> code, remove the flag from elog and then still submit messages without a 
> password. If I put an additional flag to the web browser submission "please 
> do not check the password since the cookie might have been expired", someone 
> can add this flag into elog and still bypass the password checking.

I guess it cannot and doesn't have to be 100% save.  Maybe if the web
interface is used for a new message a long random number (let's call
it newID) can be included, which elog remembers for some time (say 1
day).  Now elogd accepts a new message only if 

  1) the cookies is there and valid or
  2) if the cookies are NOT THERE, but the newID matches one of the
       stored ones.     

The new message is rejected if the cookies are there, but are wrong.

> Anothe thing which bothers me is if you specify the password explicitly on 
> the command line of elog, it's visible in some scripts etc, which yould be a 
> security issue as well.

Maybe the encoded password should be specified.  I use wget to
retrieve some entries automatically over a cron job and with wget
you specify a cookie-file with --cookie-file (or something like
this).  The content of this file corresponds to the content of the
netscape cookie file.

> 
> Any ideas?

Can one delete or edit messages with elog?  If yes then this should not be
possible.

The last x link TEXT now shows up like this

   'Last 20 entries?mode=threaded'

I can not reproduce this with the elogdemo logbook, however.

Return-Path: 
Received: from ligo.phys.lsu.edu ([unix socket])
	by ligo.phys.lsu.edu (Cyrus v2.1.13) with LMTP; Wed, 28 Jan 2004 16:27:03 -0600
X-Sieve: CMU Sieve 2.2
Received: from ligo.phys.lsu.edu (ligo.phys.lsu.edu [130.39.181.231])
	by ligo.phys.lsu.edu (Postfix) with SMTP
	id 5E12A788D1; Wed, 28 Jan 2004 16:27:03 -0600 (CST)
To: ELOG@ligo.phys.lsu.edu, user@ligo.phys.lsu.edu
From: elog@ligo.phys.lsu.edu
Subject: New playground elog entry
X-Mailer: Elog, Version 2.3.9
X-Elog-URL: http://ligo.phys.lsu.edu:8080/playground/13
X-Elog-submit-type: web|elog
Date: Wed, 28 Jan 2004 22:27:03 +52182819
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <20040128222703.5E12A788D1@ligo.phys.lsu.edu>

A new entry has been submitted on ligo.phys.lsu.edu

Logbook             : playground
Author              : Joseph Giaime
Type                : Other
Category            : Other
Subject             : yet another test

Logbook URL         : http://ligo.phys.lsu.edu:8080/playground/13

 G'day everyone.

Looking for some input on this idea.

I work for an organization which uses elog extensively for day to day operations.

In several of our logbooks we use a "location" attribute where we would enter an address or intersection.

I am working with the google places api and am able to create the auto complete form in a separate html page, but am interested if anyone has a good direction how i could change the input box into the google map autocomplete search box.

I have the code already for the api search box. but when i add it to the config it doesn't really do anything different.

Attached is the html file i setup with the api code.

the autocomplete works great, now i just want it to work in elog.

Any help is much appreciated!

And perhaps the Elog Powers that be might be interested in making it a function down the road? :)

Hi,
I just installed v.2.6.1 coming from the previous 2.6.0 (on Win2000)
When I access the "configuration" function from a logbook, in the cfg page I only see two buttons in the header
(save or cancel); in the previous version I saw more buttons there ("global config", "create new logbook" and so
on), so here I'm unable to access global configuration or logbook management (except for current logbook options).
I am logged in as admin (actually I have a single-user configuration, thus no particular users defined).
I hope this report may be helpful, and not just being caused by a misunderstanding on my side ;)
Thanks
GiorgioCC

Hi all,

We've been happily using ELOG for years, but ran into an odd problem when replacing the old Solaris server that ran the ELOG with a newer box running Ubuntu. 

Basically, when I try to search the log, the URL seems to be malformed. I.e. the form produces the query string:

?mode=summvry&reverse=0&reverse=1&npp=35&m&y&Authorthor=ericq

Instead of a functional one like:

?mode=summary&reverse=1&npp=35&Author=ericq

We're running v2.8.1, since we like using the global write password mode; our log is viewable here: http://nodus.ligo.caltech.edu:8080 Any ideas what could've gone wrong? Installation was pretty straightforward, the code compiled happily on the ubuntu machine. 

Incidentally, I notice this logbook is running V3, using CKeditor. Any hints when these might be available for public use?

Thanks!

I have "Show attachments = 0" set in [global], but attachments are shown in the "Full" view. Is this the intended behavior? Looking at individual entries correctly hides the attachments. 

We use inline images often, so when an attachement is shown at the bottom of a post it is effectively a duplicate, which clutters things up a bit.