gzilla/show_bug.cgi?id=35036
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
Summary|JNDI Realm unable to use NIS|JNDI
gzilla/show_bug.cgi?id=35036
Summary: JNDI Realm unable to use NIS context factory & FLAT
Product: Tomcat 5
Version: 5.5.7
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
I opened a bug several weeks ago and have seen no traffic on it, and
have posted to the user list twice with no answer, so I'll try here.
I apologize for mis-posting if I have.
I opened a bug on this a couple of weeks ago, but it hasn't been
touched. Maybe other folks have seen this behavior...
have to checkout from CVS head and recompile tomcat
to solve the problem, or is there a stable version which correct this ?
Thanks for your answer,
Sebastien
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]
Sent: lundi 2 août 2004 14:15
To: Tomcat Developers List
Subject: Re: JNDI
Developers List
Subject: Re: JNDI Realm Bug
IIRC - This was fixed in HEAD of JNDIRealm.
-Tim
Sebastien Brunot wrote:
> Hi,
>
>
>
> I'm using Tomcat 4.1.30 with JDK 1.4.2 on Windows XP Professionnal.
>
>
>
> I've got a problem with JNDIRealm : the group a
IIRC - This was fixed in HEAD of JNDIRealm.
-Tim
Sebastien Brunot wrote:
Hi,
I'm using Tomcat 4.1.30 with JDK 1.4.2 on Windows XP Professionnal.
I've got a problem with JNDIRealm : the group a user is in in my LDAP
directory is an object which attribute "member" contains the user CN. So
I've
Hi,
I'm using Tomcat 4.1.30 with JDK 1.4.2 on Windows XP Professionnal.
I've got a problem with JNDIRealm : the group a user is in in my LDAP
directory is an object which attribute "member" contains the user CN. So
I've set up the roleSearch attribute of JNDIRealm to the value
"(member=*{0}
gzilla/show_bug.cgi?id=26834
JNDI Realm worked for tomcat 4 but not with tomcat 5
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RE
gzilla/show_bug.cgi?id=26834
JNDI Realm worked for tomcat 4 but not with tomcat 5
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PRO
gzilla/show_bug.cgi?id=26834
JNDI Realm worked for tomcat 4 but not with tomcat 5
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=26834
JNDI Realm worked for tomcat 4 but not with tomcat 5
Summary: JNDI Realm worked for tomcat 4 but not with tomcat 5
Product: Tomcat 5
Version: 5.0.18
Platform: PC
OS/Version: Linux
Status: NEW
Severity:
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RE
gzilla/show_bug.cgi?id=16541
jndi realm role search cannot handle \ in user dn correctly
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 21:14 ---
Yes, the other defect's patch covers this problem. The user simply has to
escape the comma manually, and now that "\&quo
gzilla/show_bug.cgi?id=16541
jndi realm role search cannot handle \ in user dn correctly
--- Additional Comments From [EMAIL PROTECTED] 2003-12-11 17:08 ---
After my initial look at this defect yesterday, I had resolved that this was
NOT a duplicate of 23190. Maybe it IS though, sin
gzilla/show_bug.cgi?id=16541
jndi realm role search cannot handle \ in user dn correctly
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
--- Additional Comments From [EMAIL PROTECTED] 2003-08-25 23:29 ---
Can I get a stacktrace? I thought I squished any NPE. But I *might* see one more
spot which might through a NPE. Please make sure the stac
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
--- Additional Comments From [EMAIL PROTECTED] 2003-08-08 12:53 ---
addAttributeValues() has the ability to return null on certain conditions.
Then later in getRoles(), if debug >=2, then the list re
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PRO
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
Summary: JNDI Realm authentication to Novell eDirectory via LDAP
Product: Tomcat 4
Version: 4.1.27
Platform: PC
OS/Version: Windows NT/2K
Statu
gzilla/show_bug.cgi?id=22236
JNDI Realm authentication to Novell eDirectory via LDAP
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=18698
Exception message in JNDI realm is not "Socket closed" on different ldap
implementations
[EMAIL PROTECTED] changed:
What|Removed |Added
gzilla/show_bug.cgi?id=18698
Exception message in JNDI realm is not "Socket closed" on different ldap
implementations
Summary: Exception message in JNDI realm is not "Socket closed"
on different ldap implementations
Product: Tomcat 4
}
}
}
}
}
public String getInfo() {
return "org.apache.catalina.realm.SmartJNDIRealm/1.0";
}
protected String getName() {
return &quo
Hello all.
I need to set up Tomcat to use a LDAP directory for authentication and
authorization. I successfully configured my iPlanet directory and a JNDI
realm in Tomcat, and users and roles checkings work well, but with a
restriction. My directory schema, which is quite classical, provides a
gzilla/show_bug.cgi?id=16541
jndi realm role search cannot handle \ in user dn correctly
Summary: jndi realm role search cannot handle \ in user dn
correctly
Product: Tomcat 4
Version: 4.1.18
Platform: Other
OS/Versio
gzilla/show_bug.cgi?id=14438
Can't configure referrals in JNDI Realm
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
gzilla/show_bug.cgi?id=14438
Can't configure referrals in JNDI Realm
--- Additional Comments From [EMAIL PROTECTED] 2002-11-11 08:09 ---
Created an attachment (id=3796)
Patch to add referral support to JNDIRealm
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.a
gzilla/show_bug.cgi?id=14438
Can't configure referrals in JNDI Realm
Summary: Can't configure referrals in JNDI Realm
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
John Holman wrote:
> Amy Roh wrote:
>
>> I just committed fixes to validate only className and connectionURL
>> and also to
>> check either userPattern or userSearch is specified but not both.
>
>
> Thanks!
>
>> I don't think any change to JNDIRealm is necessary since I changed
>> admin so t
Amy Roh wrote:
> I just committed fixes to validate only className and connectionURL and also to
> check either userPattern or userSearch is specified but not both.
Thanks!
> I don't think any change to JNDIRealm is necessary since I changed admin so that
> it doesn't replace null values with "
John,
Thanks for the feedback.
John Holman wrote:
> Amy
>
> Yes - much too strict for JNDIRealm!
I agree!
> The only configuration attributes
> that should always be specified for this realm are className and
> connectionURL. In addition either userPattern or userSearch must be
> specified (b
Amy
Yes - much too strict for JNDIRealm! The only configuration attributes
that should always be specified for this realm are className and
connectionURL. In addition either userPattern or userSearch must be
specified (but not both). Other attributes either have default values,
or not specify
JDBC and JNDI Realms have many attributes. What's the minimum list of
attributes to enable these two Realms? I'll need to know the minimum
required list of attributes to validate the realm pages in admin webapp.
Currently, it's validating all the fields as required which I think is
too str
gzilla/show_bug.cgi?id=9224
JNDI realm documentation not up to date
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
f
these?
Craig
On Sat, 18 May 2002, John Holman wrote:
> Date: Sat, 18 May 2002 18:33:54 +0100
> From: John Holman <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] Documentation for JNDI Realm
>
gzilla/show_bug.cgi?id=9224
JNDI realm documentation not up to date
Summary: JNDI realm documentation not up to date
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Pr
I submitted some major changes to the JNDI Realm earlier this year, which
Craig committed in March. I also sent updates for the realm how-to and
realm configuration docs to this list shortly afterwards, but those have
not yet been committed. The current how-to doc in particular does not cover
At 20:11 01/03/02, Jonathan Eric Miller wrote
>Hi John,
>
>I'm glad to see that you have come up with a patch for JNDIRealm which
>allows users to be authenticated by a bind instead of having to query for a
>password.
>
>One thing that I'm wondering about though, with regard to your
>implementati
Hi John,
I'm glad to see that you have come up with a patch for JNDIRealm which
allows users to be authenticated by a bind instead of having to query for a
password.
One thing that I'm wondering about though, with regard to your
implementation, do you have to use groups? Or, can you specify a fi
Craig
>
> On Fri, 1 Feb 2002, John Holman wrote:
>
> > Date: Fri, 01 Feb 2002 21:56:44 +
> > From: John Holman <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: {PATCH] Enhanced JNDI realm
> >
> > Crai
ittle gunshy about merging diffs.
Thanks,
Craig
On Fri, 1 Feb 2002, John Holman wrote:
> Date: Fri, 01 Feb 2002 21:56:44 +
> From: John Holman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: {PATCH] Enhanced JNDI realm
>
> Craig
>
>
Craig
I've attached a patch to enhance the current JNDI realm implementation.
This includes three features that have been requested a number of times and
appear in the draft functional specification:
** the realm can authenticate by binding to the directory as the user. This
mo
nection pool (for either JNDI connections or JDBC
> > >connections) in server.xml, and then use it from within a Realm *and* an
> > >application if the system administrator sets things up to allow this.
> > >That should let us improve overall performance -- at
rove overall performance -- at least on the "log in
> >with the system username/password" mode that we currently support.
> >
> >Craig
> >
> >
> >On Tue, 8 Jan 2002, John Holman wrote:
> >
> > > Date: Tue, 08 Jan 2002 14:25:16 +
>
Jan 2002 14:25:16 +0000
> > From: John Holman <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Functional spec for JNDI Realm
> >
> > Craig
> >
> > After a long delay, I'm looking at your proposed function
002 14:25:16 +
> From: John Holman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Functional spec for JNDI Realm
>
> Craig
>
> After a long delay, I'm looking at your proposed functional spec for the
> Tomcat 4 JNDI Realm,
Craig
After a long delay, I'm looking at your proposed functional spec for the
Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
"Adminstrator Login Mode Functionality" section:
> The following approaches should be supported [ for retrieving the roles
John Holman wrote:
>
> On a different but related topic, I wonder whether it is sensible
> to assume that user authentication and the determination of roles
> always use the same mechanisms. For example one might want to use a
> directory service for authentication but look up roles in a databas
The log of Craig's initial commit for JNDIRealm says:
> TODO: Support an operational mode where the Realm attempts to bind to the
> directory server using the user's username and password (instead of a
> system administrator username and password). This is a different enough
> style that it pro
- Original Message -
From: "Martin Smith" <[EMAIL PROTECTED]>
> I wonder if it wouldn't be useful to permit a principal or a credential to
be an
> attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
> types of data, I wonder if it may be more efficient to mai
son entries with creditbalance > 1" ? I understand this can be
achieved by referring to an attribute that stores a URI that includes an LDAP
query string.
In any case, this authenticator is a very exciting contribution.
Martin
John Holman wrote:
> One of the action items in the Ca
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> To authenticate the
> > user, the directory is first searched for an entry with an attribute
> > matching the given username. An attempt is then made to bind to the
> > directory using the name of that entry and the
On Mon, 2 Apr 2001, John Holman wrote:
> One of the action items in the Catalina status document is a JNDI realm.
> I've been working on this recently and wonder whether what I've done would
> be useful to the project - though I'm not sure how best to get involved.
&g
One of the action items in the Catalina status document is a JNDI realm.
I've been working on this recently and wonder whether what I've done would
be useful to the project - though I'm not sure how best to get involved.
Incidentally, the status document lists James W as a voluntee
54 matches
Mail list logo
