Open
Bug 297822
Opened 20 years ago
Updated 11 years ago
NIS/NIS+/YP authentication in Bugzilla
Categories
(Bugzilla :: Extension Ideas, enhancement)
Bugzilla
Extension Ideas
Tracking
()
NEW
People
(Reporter: kbenton, Unassigned)
References
Details
Attachments
(1 file)
20.39 KB,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
I'd like to have NIS/NIS+/YP authentication implemented within Bugzilla so users
could remain logged in via cookies rather than making them log in every session.
Comment 1•20 years ago
|
||
Kevin: How about something like this:
A person would log in using their e-mail address & password. The script would
extract the username (everything before the @), look up the encrypted password
in NIS, and make sure that passwords match. The script would only work for
people in the appropriate domain (for example, only users with an @example.com
email address). Users not in the appropaite domain would be validated using one
of the built-in mechanisms that already exist.
New users in the example.com domain would not have to create an account. They
would just need to log in. The script would recognize that they are logging in
for the first time, and will create a new account for them as part of their
initial login. Their real name would be obtained from NIS, and can not be
changed by the user.
Although the user can not change their real name, they can change their email
address. By doing so they would no longer be validated by NIS, which is good if
they're losing their account (resigning, being fired, etc.).
Something like that sound good?
Reporter | ||
Comment 2•20 years ago
|
||
Sounds great to me. I would like to see, however, a look-up table for emails to
usernames when email addresses don't match. If you're already working on this,
that puts this farther ahead than me - I haven't had the time to work this issue
at all yet.
Assignee: kevin.benton → karl
Comment 3•20 years ago
|
||
(In reply to comment #2)
> Sounds great to me. I would like to see, however, a look-up table for emails to
> usernames when email addresses don't match.
Interesting. So, you're looking for something that takes an e-mail address &
returns a username that can be looked up in NIS? Should the lookup table be
consulted (a) if the domain portion of a submitted e-mail doesn't match or (b)
if the domain portion does match but the NIS lookup fails?
> If you're already working on this,
> that puts this farther ahead than me - I haven't had the time to work this
> issue at all yet.
I've got what I think is a correct implementation (the code compiles, at least).
I still have documentation to work on, and I'd appreciate users who are able to
test this on their installations!
Status: NEW → ASSIGNED
Target Milestone: --- → Bugzilla 2.22
Comment 4•20 years ago
|
||
The implementation of this module now depends on the resolution of two other bugs.
bug 298569: If NIS is not the only authentication method, and NIS generates an error, you get an error
message similar to the one in bug 298569 instead of the expected error message. This must be fixed
so that NIS errors can be properly reported.
bug 299311: For NIS error messages to be as helpful as possible, they should include all available data
returned by NIS. This includes NIS error messages and NIS passwd records, which can contain
potentially sensitive information (like encrypted passwords). Normally, I would not display this
information unless the user who is seeing the error is an administrator. However, there is no way to
determine this because the user is in the middle of logging in when the error appears! This must be
fixed so that sensitive information associated with NIS errors can be logged.
Comment 5•20 years ago
|
||
Retargeting for 2.20. Hoping against hope that it can make it in (though I know it's doubtful).
Both bug 298659 and bug 299311 have patches in and awaiting review, and look like they may make
2.20. I will also have Patch v1 ready for review by the end of the weekend. Testers will be wanted at
that time (I'll make a newsgroup/mailinglist post asking for help).
Whiteboard: [testers wanted]
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Updated•20 years ago
|
Target Milestone: Bugzilla 2.20 → ---
Comment 6•20 years ago
|
||
This is it! This is version #1 of the patch that would put NIS authentication
support into Bugzilla! I've tested it as far as I can.
This patch includes the new Perl module to handle NIS authentication, a new
template file that holds the HTML descriptions of the various AUTH_ERRORs that
can be returned, the modifications to defparams.pl to define the parameters
used by the new module, and the modifications to checksetup.pl to check for the
required Net::NIS Perl module, and to create/validate the one data file used by
the new module. Documentation is also included. Comments are pretty detailed,
and the combination of comments & documentation should get any reader up to
speed.
I should note that I really dislike the fact that I used an eval() to process
the user and domain regular expressions. I'd love another, simpler way of
doing that! As a side note, I can probably trim down the list of combinations
in the user_verify_class parameter. Also, a way of validating replacement
regular expressions would be nice!
The patch includes two new files, which I got into the patch by diffing them
against /dev/null. Apologies if it doesn't display properly. I can submit the
new files as separate attachments, if needed. This patch also requires the
latest patches for bug 298659 and bug 299311. Once those are checked in, you
can simply use the latest tip. You'll also need Net::NIS v0.34 or later.
In the end, the final version of the patch is going to need an r+ from
(probably) four different people: kiko@ for NIS module itself, mkanat@ for the
changes to checksetup.pl, erik@ (or mkanat@) for the changes to defparams.pl,
and documentation@ (probably colin.ogilvie@) for the added documentation. Of
course, that will change if additional files are touched as a result of this
patch, if one person can submit a review+ for multiple people, or if a reviewer
feels that someone else should be brought in to review something. Since the
module is the biggest part (apart from documentation), I'm asking for a review
from kiko first.
Attachment #188090 -
Flags: review?(kiko)
Comment 7•20 years ago
|
||
(In reply to comment #6)
> I should note that I really dislike the fact that I used an eval() to process
> the user and domain regular expressions. I'd love another, simpler way of
> doing that!
I dislike that too, especially because you don't need to do that. Try the
example program below....
use strict;
my $a = "abcdefg";
my $b = "def";
$a =~ s/c$b/woo/;
print $a;
You should be able to change your eval to ....
my $nis_domain_filter = Param('auth_nis_domain_regexp');
if ($username =~ m/$nis_domain_filter/) {
In the case of the substirution that follows, you will have to split the left
side from the right side and then use...
$nis_username =~ s/$leftside/$rightside/;
try this example...
my $a = "abcdefg";
my $b = "d.f";
$a =~ s/c$b/$b/;
print $a;
Comment 8•20 years ago
|
||
Joel: Thanks very much for the code snippet!
I'm not ignoring this. I'm sure that kiko is going to find other stuff to note
when patch v1 is reviewed, so I'm waiting for that before submitting a Patch v2.
Whiteboard: [testers wanted] → [patch awaiting review] [testers wanted]
Target Milestone: --- → Bugzilla 2.22
![]() |
||
Comment 9•19 years ago
|
||
Comment on attachment 188090 [details] [diff] [review]
Patch v1
defparams.pl no longer exists
Attachment #188090 -
Flags: review?(kiko) → review-
![]() |
||
Updated•19 years ago
|
Whiteboard: [patch awaiting review] [testers wanted]
![]() |
||
Comment 11•18 years ago
|
||
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:
- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker
If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.
If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.
If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Updated•17 years ago
|
Assignee: karl.kornel → user-accounts
Status: ASSIGNED → NEW
Target Milestone: Bugzilla 3.2 → ---
Comment 12•12 years ago
|
||
hi every body
i am new user of bugzilla and linux (centos) i need to apply a patch. please some one cant help me step by step to apply this patch. need NIS authentication
thank you
Comment 13•12 years ago
|
||
(In reply to madjid from comment #12)
> hi every body
>
> i am new user of bugzilla and linux (centos) i need to apply a patch. please
> some one cant help me step by step to apply this patch. need NIS
> authentication
>
> thank you
Comment 14•11 years ago
|
||
this proposal is better suited to being implemented as an extension instead of in bugzilla core.
Assignee: user-accounts → extension.ideas
Component: User Accounts → Extension Ideas
You need to log in
before you can comment on or make changes to this bug.
Description
•