Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 666 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 665, 666, 667 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  66086   Thu Nov 27 10:29:19 2008 Reply Niklasniklas@hoglund.pp.seBug reportLinux2.7.5 2142Re: Elogd crashes with: *** stack smashing detected ***

Stefan Ritt wrote:

 

Niklas wrote:

 

Stefan,

perhaps there should be something like the bold text below in elogd.c:

int process_http_request(const char *request, int i_conn)^M
...

   /* extract cookies */^M
   if ((p = strstr(request, "Cookie:")) != NULL) {^M
      p += 6;^M
      do {^M
         p++;^M
         while (*p && *p == ' ')^M
            p++;^M
         strlcpy(str, p, sizeof(str));^M
         for (i = 0; i < (int) strlen(str); i++)^M
            if (str[i] == '=' || str[i] == ';')^M
               break;^M
         if (str[i] == '=') {^M
            str[i] = 0;^M
            p += i + 1;^M
            for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' && i < (int) sizeof(cookie); i++)
                      cookie[i] = *p++;

...

 

Wow, where did you get that long cookie from? Certainly not from elogd. You must run elogd under Apache, and have some other service next to it on your server which distributes this long cookies, that's why other people did not experience this problem yet. I appreciate your fix. It's alwasy nice to see users not only complain about things, but try to fix them. Your fix is almost correct, you need a

i<(int) sizeof(cookie)-1

since there is the trailing zero for terminating the cookie string. I applied your fix to SVN revision #2146.

I the cookie is used for single-sign-on for multiple sites within company.com. So the cookie is issued for "company.com" i.e. all websites gets it even elog.company.com:8080..

I mostly fibble little bit in perl (dont need to bother with trailing zeros there ).

BR, Niklas

 

 

  66087   Thu Nov 27 11:36:53 2008 Agree T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.5-2130Re: Select -> Edit wipes dates

Stefan Ritt wrote:

 This problem has been fixed in revision 2.7.5-2143. Please upgrade.

 Yup, this works now - thanks a mil!

  66097   Fri Dec 5 16:14:19 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukBug reportLinux2.7.5Re: Auto-increment attributes

Steve Williamson wrote:

We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

 

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve

 Hi

This is to let you know that the increment problem has just happened again.

Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29

overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53

So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.

There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence.  If you pick it up at the end then you can't display it until the user presses submit.

regards

Steve

  66100   Mon Dec 8 10:09:14 2008 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.7.5Re: Auto-increment attributes

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

  66101   Mon Dec 8 13:13:13 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukBug reportLinux2.7.5Re: Auto-increment attributes

Stefan Ritt wrote:

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

 Stefan

Thanks for fix - I've just tested it and it works beautifully.

regards

Steve

 

  66106   Thu Dec 11 03:13:31 2008 Warning Dennis Seitzdseitz@berkeley.eduBug reportMac OSX2.7.5Attribute value lost when adding to another extendable attribute

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  66109   Fri Dec 12 08:07:59 2008 Reply Stefan Rittstefan.ritt@psi.chBug reportMac OSX2.7.5Re: Attribute value lost when adding to another extendable attribute

 

Dennis Seitz wrote:

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

  66112   Sat Dec 13 02:13:51 2008 Reply Dennis Seitzdseitz@berkeley.eduBug reportMac OSX2.7.5Re: Attribute value lost when adding to another extendable attribute

 

Stefan Ritt wrote:

 

Dennis Seitz wrote:

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

 

 Excellent! Thank you.

Goto page Previous  1, 2, 3 ... 665, 666, 667 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6