Re: Using curl to post new entries, posted by Stefan Ritt on Wed Sep 2 15:42:40 2020
|
This is correct. The elogd daemon needs username and password in parameters "unm" and "upwd". The password must be SHA256 encoded, so best is to grab it from the password file. This way one does not have to send clear text passwords over the network.
| Florian Feldbauer wrote: |
|
After going through the code of the Python API (https://github.com/paulscherrerinstitute/py_elog/blob/master/elog/logbook.py) I tried the following:
$ python3
>>> from passlib.hash import sha256_crypt
>>> sha256_crypt.hash( 'foobaa', salt='', rounds=5000)[4:]
'waa2sT6eBt.qk0wsucX/nxU5GcqffqlEx6ja5Lg1OR5'
>>> from datetime import datetime
>>> datetime.now().timestamp()
1599039390.964989
$ curl -F cmd=Submit -F exp=labor -F unm=florian -F upwd='waa2sT6eBt.qk0wsucX/nxU5GcqffqlEx6ja5Lg1OR5' -F Encoding=plain -F When=1599039390.964989 -F Author=curl -F Subject="curl test" -F Category=General -F Type=Diary -F Text="foo baa" http://localhost:8080/test/
This worked. It seems to me, that the "-u" option from Curl is not working for elog.
Cheers,
Florian
| Florian Feldbauer wrote: |
|
Hey,
i'm trying to use curl to post new entries to our logbook as described here: https://elog.psi.ch/elogs/Forum/68597.
The Elog is installed via the Deban package on Buster.
I created a test logbook with attributes Author, Type, Category and Subject.
curl -u florian:foobaa -F cmd=Submit -F Author=Florian -F Type=Diary -F Category=General -F Subject="testing curl" -F Text="foo baa" http://localhost:8080/test
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>ELOG Login</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body OnLoad="document.form1.uname.focus();">
<form name=form1 method="POST" action="./" enctype="multipart/form-data">
<input type=hidden name=redir value="">
<table class="login_frame" cellspacing=0 align=center><tr><td class="login_title">Please login</td></tr>
<tr><td class="login_form">
<span class="overlay_wrapper">
<label for="uname" id="uname" class="overlabel">Username</label>
<input type="text" class="login_input" name="uname" value="" title="Username" onInput="document.getElementById('uname').style.display='none';">
</span></td></tr>
<tr><td class="login_form">
<span class="overlay_wrapper">
<label for="upassword" id="upassword" class="overlabel">Password</label>
<input type="password" class="login_input" name="upassword" onInput="document.getElementById('upassword').style.display='none';">
</span></td></tr>
<tr><td align=center class="login_form"><input type=checkbox checked name=remember value=1>
Keep me logged in on this computer
for the next 31 days or until I log out</td></tr>
<tr><td align=center class="login_form">
<a href="?cmd=Forgot">Forgot password?</a></td></tr>
<tr><td align=center class="login_form_bottom"><input type="submit" class="login_submit" value="Submit"></td></tr></table>
<center><a class="bottomlink" title="Goto ELOG home page" href="https://midas.psi.ch/elog/">ELOG V3.1.3-7933898</a></center></form></body></html>
As you can see, curl only prints the login page of the logbook and no new entry has been created. Any suggestions what might go worng here?
Regards,
Florian
|
|
|
Query to get values for Attributes, posted by Florian Feldbauer on Mon Sep 21 09:17:52 2020
|
Hey,
I'm trying to integrate the Elog into our SlowControl System (Phoebus/EPICS). As a first step I translated the python library to Java. So writing new Entries and viewing them works.
But for Phoebus, you need a list of the possible values for the attributes. Currently this is done via the config file from Phoebus.
Is there a way to get the values also via a query directly from the Elog?
Cheers,
Florian |
Re: Query to get values for Attributes, posted by Andreas Luedeke on Mon Sep 21 20:03:49 2020
|
That would be a nice feature...
If you are good in parsing HTML you can achieve this feature: when you create a new entry "<elog-URL>?cmd=new", you'll get HTML source code that provides you with all possible attribute choices.
Disclaimer: this only works if you don't use Conditional attributes.
| Florian Feldbauer wrote: |
|
Hey,
I'm trying to integrate the Elog into our SlowControl System (Phoebus/EPICS). As a first step I translated the python library to Java. So writing new Entries and viewing them works.
But for Phoebus, you need a list of the possible values for the attributes. Currently this is done via the config file from Phoebus.
Is there a way to get the values also via a query directly from the Elog?
Cheers,
Florian
|
|
|
Re: Query to get values for Attributes, posted by Florian Feldbauer on Tue Sep 22 09:27:45 2020
|
Thanks for the tipp. I managed to use XPATH to get the values for my Type and Category attributes!
The API, I'm developing for Phoebus is quiet simple. It currently just supports Author, Subject, Type and Category as attributes and the latter two are just lists of values.
| Andreas Luedeke wrote: |
|
That would be a nice feature...
If you are good in parsing HTML you can achieve this feature: when you create a new entry "<elog-URL>?cmd=new", you'll get HTML source code that provides you with all possible attribute choices.
Disclaimer: this only works if you don't use Conditional attributes.
| Florian Feldbauer wrote: |
|
Hey,
I'm trying to integrate the Elog into our SlowControl System (Phoebus/EPICS). As a first step I translated the python library to Java. So writing new Entries and viewing them works.
But for Phoebus, you need a list of the possible values for the attributes. Currently this is done via the config file from Phoebus.
Is there a way to get the values also via a query directly from the Elog?
Cheers,
Florian
|
|
|
|
Placeholders in Python API, posted by Florian Feldbauer on Wed Nov 25 15:10:34 2020
|
Hey all,
In the configuration of the Elog one can use
Preset Author = $long_name
Preset Author Email = $user_email
to have predefined values for the Author and Author Email fields when creating a new entry via the web interface.
Is it also possible to use these placeholders when creating a new entry via the Python API?
Cheers,
Florian |
|
length of condition names, posted by Harry Martin on Wed Dec 2 22:45:16 2020
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it! |
|
Re: Options <...> vs ROptions <...>, posted by Harry Martin on Thu Dec 3 01:51:49 2020
|
Same problem here, in version 3.1.3. It would be very nice if this worked.
| Wolfgang Bayer wrote: |
|
According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?
|
|
|
Re: length of condition names, posted by Stefan Ritt on Thu Dec 3 09:57:20 2020
|
You can easily use multi-character conditionals, up to 256 chars.
| Harry Martin wrote: |
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it!
|
|