Reduce some code duplication

[Stephen Gran]

Hi again,

On Thu, Jan 13, 2011 at 02:58:01PM +0100, Andreas Ericsson said:
> On 01/13/2011 01:43 PM, Stephen Gran wrote:
> > Hi,
> > 
> > I'm looking slightly longer term at extending cgi.cfg to support using
> > contact_group names in the authorized_for* settings, and this is step
> > one on the road.  If someone thinks the above is a bad idea (or if reuse
> > of code is a bad idea) let me know and I'll stop.
> 
> There's one problem with this approach;
> The users in cgi.cfg don't have to be contacts. They only have to be able
> to log in to Nagios.
> 
> With that in light, I wonder what happens when eu-admins is both a user
> (from the apache view of things) as well as a contactgroup, but not a
> contact. That's one of the things that absolutely has to keep working,
> or a lot of people's setups will break.

On Thu, Jan 13, 2011 at 07:21:37PM +0100, Jochen Bern said:
> On 01/13/2011 04:52 PM, Stephen Gran wrote:
> > On Thu, Jan 13, 2011 at 02:58:01PM +0100, Andreas Ericsson said:
> >> I wonder what happens when eu-admins is both a user
> >> (from the apache view of things) as well as a contactgroup, but not a
> >> contact. That's one of the things that absolutely has to keep working,
> >> or a lot of people's setups will break.
> > I was planning to use a marker to specify that it is a group, whether %
> > like sudo or @ like many other things
> 
> 1. Both "%" and "@" are legal separators for e-mail addresses, which are
>    getting more and more popular as "usernames" for all sorts of web UI
>    logins. I doubt they're safe to forcefully overload, even as
>    username[0].
> 2. I don't think that there's *any* printable character which is prima
>    facie illegal in Basic Auth usernames. Not even the "," (and "="?)
>    that cgi.cfg sets aside as its separator char(s).
> 3. Suggestion: Make the marker configurable (so that admins can work
>    around odd username[0]s already in use), with setting it to '\0' or
>    somesuch effectively disabling the new feature (for the rare cases
>    where the user base took pride in having really *every* printable
>    character covered ;-).

Sorry to let this sit for so long - the objections were all good ones,
and I had to go have a think, and then other things came up, as they
always do ...

Anyway, I think I've hit on something that may be useful, if you're
amenable.  I'm proposing new cgi.cfg parameters that allow you to
specify contactgroups that are authorized for the various levels of auth
in addition to users.  I think the attached patch does this, and in a
way that should ensure it doesn't interfere with existing practices.

Cheers,
-- 
 --------------------------------------------------------------------------
|  Stephen Gran                  | Labor, n.:  One of the processes by     |
|  steve at lobefin.net             | which A acquires property for B.   --   |
|  http://www.lobefin.net/~steve | Ambrose Bierce, "The Devil's            |
|                                | Dictionary"                             |
 --------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-for-authorization-as-a-function-of-contact_gro.patch
Type: text/x-diff
Size: 4712 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110724/2b0fe046/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110724/2b0fe046/attachment.sig>
-------------- next part --------------
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel