| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67547
|
Tue Jul 16 15:42:30 2013 |
 | Martin Rongen | martin.rongen@rwth-aachen.de | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > > Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> > But, this is elog v2.9.0-2435, and I am using v2.9.2-2475. And I remember there was a recent issue about the image manipulation at some point, so I went to the
> > download section to read the subversion listing to find where this occurred. But you've changed subversion! I couldn't find my way around it, so I not only could
> > I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
> >
> > As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it. Do you know when this was? Could it be relivent?
>
> I upgraded to V2.9.2, so please try again.
>
> /Stefan
I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc... |
|
67548
|
Tue Jul 16 16:35:01 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...
Have you tried on the Demo logbook on the PSI server or on your installation. I just attached an image to this entry, rotated it twice, reduced its size
and it works fine. The point is that I have to reproduce your bug in order to fix it, but it seems I cannot.
/Stefan |
| Attachment 1: psi.png
|
|
|
67549
|
Fri Jul 19 14:03:29 2013 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg | > > I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...
> Have you tried on the Demo logbook on the PSI server or on your installation. I just attached an image to this entry, rotated it twice, reduced its size and it works fine. The point is that I have to reproduce your bug in order to fix it, but it seems I cannot.
> /Stefan
Hi Stefan,
I've noted that you did your test with a PNG while he was reporting about a problem with a PDF. I'll give it a try with your server 
⇄
Detect language » English
It appears to work nicely.
I would suggest that the reporters of the issue add a little bit of information, like the version of the operating system, of ImageMagick and if the problem occurs with only a specific browser, etc.
Regards
Andreas
⇄
Detect language » English
Cool: while it worked fine when I've created the entry, it stops working when I EDIT the entry that had been rotated! Actually it sometimes works and sometimes not.
As a workaround you can always go to "1:1" and then retry to rotate. That worked here.
Andreas
⇄
Detect language » English
⇄
Detect language » English
PS: I've noticed that the thumbnail PNG file only updated in the List view after I did a reload. I'm using Firefox 10.0.11 ESR on SL6.0. |
| Attachment 1: psi.pdf
|
|
|
67550
|
Mon Jul 22 14:05:48 2013 |
| Martin Rongen | martin.rongen@rwth-aachen.de | Question | Linux | 2.9.2-2475 | Re: elog's image manipulation of .png file generated from a pdf/jpg |
| Andreas Luedeke wrote: |
|
I would suggest that the reporters of the issue add a little bit of information, like the version of the operating system, of ImageMagick and if the problem occurs with only a specific browser, etc.
⇄
Detect language » English
⇄
Detect language » English
PS: I've noticed that the thumbnail PNG file only updated in the List view after I did a reload. I'm using Firefox 10.0.11 ESR on SL6.0.
|
Hi all
Tested browsers on my SL6.4 desktop computer are Firefox 17.07, Konqueror 4.3.4. Here the rotation and rescaling is all wonky and the changes are not saved when submitting the entry.
On my Android mobile phone (Chrome 28.0.1500.64) the images rotate and rescale nicely, but the changes are not saved aswell. I tried to force reloading and clearing my cache with all of the browsers.
The elogs I tested are served from Ubuntu 10.04.4 LTS and Debian 3.2.46-1 x86_64 running IM 6.5.7-8 and 6.7.7-10 respectively.
Martin |
|
1260
|
Tue Jul 12 10:15:30 2005 |
 | Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug fix | Linux | 2.5.9 | Re: elog utility for submission used wrong 'Host:' in POST header | > The 'elog' utility for commandline submission used wrong 'Host:' in POST header.
> The host listed after 'Host:' should be the host where the server runs, not the
> localhost (see patch below).
>
> $ diff -u elog.c_20050711 elog.c
> --- elog.c_20050711 Mon Jul 11 18:54:20 2005
> +++ elog.c Mon Jul 11 18:55:31 2005
> @@ -421,7 +421,7 @@
> sprintf(request + strlen(request), "%s/%d?cmd=download", experiment, message_id);
> strcat(request, " HTTP/1.0\r\n");
>
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
>
> first = 1;
> @@ -872,7 +872,7 @@
> strcat(request, " HTTP/1.0\r\n");
>
> sprintf(request + strlen(request), "Content-Type: multipart/form-data; boundary=%s\r\n", boundary);
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
> sprintf(request + strlen(request), "Content-Length: %d\r\n", content_length);
This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ...
On the other hand it should replay with an error when a bogus client tries to speak HTML/1.0 specifing "host:",
and (the wrost case) when the bogus client says to speak HTML/1.1 and doesnt provide the required "Host:" header ...
Yes .. elog will ignore it, but it is an RFC requirement for HTML/1.1 ! |
|
1283
|
Wed Jul 20 21:03:29 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | Linux | 2.5.9 | Re: elog utility for submission used wrong 'Host:' in POST header |
| Emiliano Gabrielli wrote: | This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ... |
So I remove the Host: ... line at all, I hope this is ok with everybody. |
|
63
|
Tue Jul 9 10:58:18 2002 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | | | Re: elog submit without user and password | > 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.
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.
Any ideas? |
|
64
|
Tue Jul 9 15:28:33 2002 |
| H. Scheit | h.scheit@mpi-hd.mpg.de | Comment | | | Re: elog submit without user and password | > > 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. |
|