Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 644 of 808  Not logged in ELOG logo
    icon2.gif   Re: Access to global configuration in v2.6.1, posted by Stefan Ritt on Wed Jan 25 12:10:46 2006 
> or maybe browser cookies. 

That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
fooled by old cookies. Just delete all cookies in your browser and try again.
    icon2.gif   Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Tue Mar 14 17:11:10 2006 
> > or maybe browser cookies. 
> 
> That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
> fooled by old cookies. Just delete all cookies in your browser and try again.

Hi,
here I am at it again. Since my first posts, I tried to install the latest version of elog out-of-the-box on one pair of
PCs from scratch (fresh elog install on new, just-installed PCs, OS WinXP Pro and Win2000), but with no results. No
trace of the global configuration menu or the buttons to reach it.
Neither taking a look at the code has helped, I could not figure out exactly where the button bar was generated.
Didn't anybody other point out a similar behaviour? Do you have any suggestion for any tests to carry out?
Thanks
GiorgioCC
    icon2.gif   Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Tue Aug 29 15:16:31 2006 
Hi,
after a long time, I thought I could try to investigate the code some further,
and maybe I found some hint.
The page where I expected the options to show was (probably) the one generated by this function:

void show_admin_page(LOGBOOK * lbs, char *top_group)

Inside, it, the buttons are generated by following code snippets:

(elogd.c:10443)
if (is_admin_user_global(getparam("unm"))) {
   sprintf(str, loc("Change %s"), "[global]");
   rsprintf("<input type=submit name=cmd value=\"%s\">\n", str);
}
(elogd.c:10461)
  if (is_admin_user("global", getparam("unm"))) {
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Delete this logbook"));
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Rename this logbook"));
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Create new logbook"));
}

The functions called to validate the user are following:

(elogd.c:21298)
BOOL is_admin_user(char *logbook, char *user):
//...
   if (user == NULL)
      return FALSE;

(elogd.c:21324)

BOOL is_admin_user_global(char *user)
{
//...
   if (user == NULL)
      return FALSE;

Since I assume that I'm probably in the "userless" case (no users are defined in the configuration,
and no usernames are set when launching elog either), I would understand that this causes the options for
global config editing etc etc not to be shown on the admin page.

In my opinion (and given that my interpretation of the code flow isn't wrong), the "null"
user should be indeed considered admin, at least as long as no user management is defined whatsoever.
(If I got it right, if user==NULL, but a password file exists, user management is applied,
thus we're in the case of anonymous user which is correctly not admin).

Again, I might be wrong, but I would be curious to hear an opinion from you about this issue.
Thanks again for your attention.
GiorgioCC
    icon2.gif   Re: Access rights, posted by Stefan Ritt on Mon May 7 15:12:24 2012 

Roland Gsell wrote:

Hi,

the manual says:

"
There are four ways through which access to a logbook may be controlled:

it may be open for all to read ;
it may require a common "read" password for all users ;
it may require each user to have an individual user account (login name) and password ;
finally, access may be granted or not depending on the address of the workstation you are using.
"

But it doesn't say how to do so or at least I didn't find it.

If I have each user have to log in with an individual accout, can I define which logbooks he can read and/or modify?
If yes, how to do that?

Also, please accept my vote for user groups. We can use that, too.

TIA,
Roland.

You haven't found it. Just look here:

http://midas.psi.ch/elog/config.html#access

 

You need Password file and Login user

    icon2.gif   Re: Access control, group level, posted by Stefan Ritt on Tue Nov 3 09:24:15 2009 

Niklas wrote:

Hi elog experts =)

 

Anyone know if it's possible to have access control per group-level?

For instance:

Group A = B,C   

Group B = LogA   

Group C = LogB, LogC      

Group C: Read password = abc

 //NH

I added your vote to the wishlist

https://midas.psi.ch/elog/wishlist.html 

    icon2.gif   Re: Access Control, posted by Yoshio Imai on Tue May 13 16:58:40 2008 

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.
    icon2.gif   Re: Access Control, posted by Grant Jeffcote on Tue May 13 21:56:30 2008 

Yoshio Imai wrote:

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.


What a great solution, thanks Yoshio, it works a treat.
    icon2.gif   Re: Access Control, posted by Grant Jeffcote on Thu May 15 17:45:44 2008 

Grant Jeffcote wrote:

Yoshio Imai wrote:

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.


What a great solution, thanks Yoshio, it works a treat.


Is there any way to give a logged in user a 'Guest' view on certain logbooks?
Unfortunately at the moment if they are not in the 'login users = ' group they are automatically logged out and have to re-log back into their own logbook.
ELOG V3.1.5-3fb85fa6