oolean isInRole(Wrapper wrapper, Principal principal, String
> role) {
> if(principal instanceof CustomPrincipal
> && ((CustomPrincipal)principal).isMine(this) {
>return super.isInRole(reverseMapRole(role));
> } else {
>// Principal is not from this Real
s as a configurable Map
return "CN=users,OU=groups,DC=example,DC=org";
} else {
return role;
}
public class CustomPrincipal extends GenericPrincipal {
private boolean isMine(MyRealm realm) {
return realm == MyRealm.this;
}
...
}
}
You can use th
Hi folks,
I seek guidance on a larger problem I need to solve where I do have a few ideas,
but am also considering to what degree it would make sense to add code to the
Tomcat codebase for the common good:
I have a realm impl called MyRealm which sources from "store A", is has roles
(groups) in a
On Tue, Jun 1, 2021 at 12:46 PM Carsten Klein wrote:
>
>
> On 01/06/2021 10:18, Mark Thomas wrote:
>
> > I don't know if you can. I suspect not. By all means see if you can. I'm
> > mildly curious to find out the answer. Whether you can or not, you don't
> > need to.
>
> I found nothing to re-tri
On 01/06/2021 10:18, Mark Thomas wrote:
I don't know if you can. I suspect not. By all means see if you can. I'm
mildly curious to find out the answer. Whether you can or not, you don't
need to.
I found nothing to re-trigger the Travis CI build so far. However, now
the CI test is 'success
On 01/06/2021 08:39, Carsten Klein wrote:
Mark,
On 01/06/2021 09:28, Mark Thomas wrote:
We have been seeing that a lot lately. As far as I can tell, it is an
issue with Travis CI.
Can you use the PR anyway?
Yes. We don't have a strict CI must pass rule. Whether or not a PR is
applied a de
Mark,
On 01/06/2021 09:28, Mark Thomas wrote:
We have been seeing that a lot lately. As far as I can tell, it is an
issue with Travis CI.
Can you use the PR anyway? Can/must I re-trigger the Travis build?
Carsten
-
To unsub
On 29/05/2021 13:28, Carsten Klein wrote:
Mark,
On 27/05/2021 18:56, Carsten Klein wrote:
Concerning removal of class UserDatabaseRealm.UserDatabasePrincipal:
I will provide a PR and file a corresponding issue in Bugzilla soon.
My PR and Bugzilla issue are present. However, Travis CI build
Chris,
On 28/05/2021 23:16, Christopher Schultz wrote:
Yeah, about that...
https://openjdk.java.net/jeps/411
IMO this is a Bad Thing for Java. If someone was looking for a reason to
abandon the whole Java ecosystem, this would be it. Well, we had a good
run.
Now we can all run node.js
Mark,
On 27/05/2021 18:56, Carsten Klein wrote:
Concerning removal of class UserDatabaseRealm.UserDatabasePrincipal:
I will provide a PR and file a corresponding issue in Bugzilla soon.
My PR and Bugzilla issue are present. However, Travis CI build failed
on arm64 architecture for the PR w
Mark,
On 5/28/21 04:13, Mark Thomas wrote:
On 28/05/2021 07:22, Carsten Klein wrote:
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
After re-reading this, you mentioned reflection while asking how much
we trust in Collections.unmodifiableMap(). I didn't get that right, my
b
Carsten,
On 5/28/21 01:48, Carsten Klein wrote:
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
What's the primary use-case for these kinds of attributes?
This has been described in detail here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a
On 28/05/2021 07:22, Carsten Klein wrote:
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
After re-reading this, you mentioned reflection while asking how much we
trust in Collections.unmodifiableMap(). I didn't get that right, my bad.
However, I thought of reflection in orde
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
After re-reading this, you mentioned reflection while asking how much we
trust in Collections.unmodifiableMap(). I didn't get that right, my bad.
However, I thought of reflection in order to implement a deep copy
mechanism. May
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
What's the primary use-case for these kinds of attributes?
This has been described in detail here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E
Mark,
On 5/27/21 12:22, Mark Thomas wrote:
On 27/05/2021 15:04, Christopher Schultz wrote:
Mark,
On 5/27/21 04:59, Mark Thomas wrote:
On 27/05/2021 07:32, Carsten Klein wrote:
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would
need to
You read my mind. I always wanted to report this, but never find time.
Implemented this for our realm and principal years ago:
http://tomcatspnegoad.sourceforge.net/apidocs/net/sf/michaelo/tomcat/realm/ActiveDirectoryPrincipal.html#getAdditionalAttributes--
The entire principal should be immutab
sion during its lifetime, which we can surely
drop. Only few other Realms will support this (if any).
If we go the removal route then I'd treat that as a separate PR /
bugzilla issue so any discussion remains focussed on the relevant issue.
The removal route seems simple. Both the UserDatab
On 27/05/2021 15:04, Christopher Schultz wrote:
Mark,
On 5/27/21 04:59, Mark Thomas wrote:
On 27/05/2021 07:32, Carsten Klein wrote:
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would
need to make sure neither the Map nor any of the keys
On 27/05/2021 12:49, Carsten Klein wrote:
On 27/05/2021 10:59, Mark Thomas wrote:
As far as I can tell, removing UserDatabasePrincipal, relying on
GenericPrincipal and User remaining an internal object not exposed via
the Servlet API would achieve the same result with less code.
At this po
Mark,
On 5/27/21 04:59, Mark Thomas wrote:
On 27/05/2021 07:32, Carsten Klein wrote:
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would
need to make sure neither the Map nor any of the keys/values could be
modified. Protecting the Map is
On 27/05/2021 10:59, Mark Thomas wrote:
As far as I can tell, removing UserDatabasePrincipal, relying on
GenericPrincipal and User remaining an internal object not exposed via
the Servlet API would achieve the same result with less code.
At this point I am looking for a reason not to remove
On 27/05/2021 07:32, Carsten Klein wrote:
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would need
to make sure neither the Map nor any of the keys/values could be
modified. Protecting the Map is easy. Protecting the keys/values is a
littl
Hi Mark,
thanks for sharing your ideas :)
On 26/05/2021 19:56, Mark Thomas wrote:
Given that the attributes may well be security related, you would need
to make sure neither the Map nor any of the keys/values could be
modified. Protecting the Map is easy. Protecting the keys/values is a
litt
On 26/05/2021 18:56, Mark Thomas wrote:
On 26/05/2021 12:00, Carsten Klein wrote:
Why does UserDatabaseRealm pass a userPrincipal of type
UserDatabasePrincipal? Can't we just drop that and do it like
JNDIRealm or DataSourceRealm?
I don't see any obvious reason. I'll do some digging in the
On 26/05/2021 12:00, Carsten Klein wrote:
1. How to access the Principal's new attributes
Simplest is to provide a getter method, that actually returns the map
(optionally with a read-only parameter):
Given that the attributes may well be security related, you would need
to make sure neit
Hi there,
as already discussed here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/202104.mbox/ajax/%3Cb9a2a913-f00f-f5bf-ca05-8ea4f8663ca9%40datagis.com%3E
I'm implementing an enhancement for querying configurable extra user
attributes through some of the Realm classes from the "user
er Profile use case
for web app authentication. We currently have user authentication being
done locally in a custom Tomcat realms implementation. For the customers
requiring SSO, we would like to ideally find a pre-integrated Tomcal realms
implementation that we can plug into our Tomcat deploymen
ervlet+specification
Mark
>
> On Sun, Aug 30, 2015 at 9:55 PM, Mark Thomas wrote:
>
>> On 29/08/2015 22:26, Sreyan Chakravarty wrote:
>>> Okay I have just started to use Realms and container managed
>> authentication
>>> and I am confused about as how to specify a
Can you provide a link to the Servlet Spec the to which section you are
referring to.
On Sun, Aug 30, 2015 at 9:55 PM, Mark Thomas wrote:
> On 29/08/2015 22:26, Sreyan Chakravarty wrote:
> > Okay I have just started to use Realms and container managed
> authentication
> >
On 29/08/2015 22:26, Sreyan Chakravarty wrote:
> Okay I have just started to use Realms and container managed authentication
> and I am confused about as how to specify a home page.
Go and read the Servlet spec for how FORM authentication works.
Then read the section on how to specify se
Okay I have just started to use Realms and container managed authentication
and I am confused about as how to specify a home page.
Let me explain-:
TECHERS
/teacher/success.jsp
GET
POST
Here the only resource protected is
/teacher/success.jsp
On 14 Mar 2015, at 3:43 PM, Graham Leggett wrote:
> Changing the auth-type to CLIENT-CERT shows that the username has been
> replaced by the subject-DN of the cert, which is progress.
Reverse engineering tomcat showed that the tomcatAuthentication parameter
solved half the problem - when the w
On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko wrote:
> You are using JRE's default java.util.logging.LogManager.
>
> You need to configure JRE to use the Tomcat JULI implementation of log
> manager with
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>
> The JRE class is us
2015-03-13 23:43 GMT+03:00 Graham Leggett :
> On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic wrote:
>
>> Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache
>> HTTPD?
>
> Yes, it is branded tomcat and appears in the tomcat access log.
>
>> I don't expect it is an Apache issue h
Graham,
On Fri, Mar 13, 2015 at 4:49 PM, Graham Leggett wrote:
> On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic
> wrote:
>
> >>> What doesn’t seem to fit is the realm definition - specifying
> userCredCol
> >>> is marked as mandatory, but this is obviously not present with a client
> >>> certific
ed.
>
> Back in the day there was a simple “debug” flag that turned on debugging.
> That seems to have been replaced with the significantly more complicated
> java.util.logging implementation, based on adding a logging.properties file.
> Adding this file, along with suggested entr
Graham,
On Fri, Mar 13, 2015 at 4:43 PM, Graham Leggett wrote:
> On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic
> wrote:
>
> > Just to confirm, the 403 Forbidden page was rendered by Tomcat, not
> Apache
> > HTTPD?
>
> Yes, it is branded tomcat and appears in the tomcat access log.
Great. We kno
On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic wrote:
>>> What doesn’t seem to fit is the realm definition - specifying userCredCol
>>> is marked as mandatory, but this is obviously not present with a client
>>> certificate. What do you specify in this field?
>>>
>>
> You define the password colu
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic wrote:
> Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache
> HTTPD?
Yes, it is branded tomcat and appears in the tomcat access log.
> I don't expect it is an Apache issue here - because you mentioned your
> application worked
Graham,
On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett wrote:
>
>> What doesn’t seem to fit is the realm definition - specifying userCredCol
>> is marked as mandatory, but this is obviously not present with a client
>> certificate. What do you specify in this field?
>>
>
You define the password
Graham,
On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett wrote:
> Hi all,
>
> I have a basic authentication setup that works great as below.
>
>
> BASIC
> Patricia
>
>
>
>
> administrator
>
>
>
Graham,
On Fri, Mar 13, 2015 at 3:02 PM, Graham Leggett wrote:
> Hi all,
>
> I have a working realm installation using basic authentication, which I
> need to switch to client certificate authentication. Having done so it
> doesn’t work, I just get “forbidden”, with no indication of the error
>
Hi all,
I have a basic authentication setup that works great as below.
BASIC
Patricia
administrator
underwriter
accountant
debugging. That
seems to have been replaced with the significantly more complicated
java.util.logging implementation, based on adding a logging.properties file.
Adding this file, along with suggested entries to debug realms has had no
effect, I can still see nothing in console.out.
Can anyone
Rainer Jung wrote:
> On 05.12.2011 10:42, oh...@cox.net wrote:
> >
> > "André Warnier" wrote:
> >> oh...@cox.net wrote:
> >> ...
> >>> Rainer Jung wrote:
> Although this thread has moved forward towards the role topic, I want to
> give some infos about the user forward
On 05.12.2011 10:42, oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
...
Rainer Jung wrote:
Although this thread has moved forward towards the role topic, I want to
give some infos about the user forwarding by mod_jk. Some of it was
already present in previous pos
"André Warnier" wrote:
> oh...@cox.net wrote:
> ...
> > Rainer Jung wrote:
> >> Although this thread has moved forward towards the role topic, I want to
> >> give some infos about the user forwarding by mod_jk. Some of it was
> >> already present in previous posts.
> >>
> >> 1) In
oh...@cox.net wrote:
...
Rainer Jung wrote:
Although this thread has moved forward towards the role topic, I want to
give some infos about the user forwarding by mod_jk. Some of it was
already present in previous posts.
1) In order to let Tomcat accept the user, you need to set
tomcatA
Rainer Jung wrote:
> On 02.12.2011 17:49, André Warnier wrote:
> > oh...@cox.net wrote:
> >> oh...@cox.net wrote:
> >>> "André Warnier" wrote:
> oh...@cox.net wrote:
> ...
> > > tomcatAuthentication="false" />
> >
> That is correct. The "false" means t
On 02.12.2011 17:49, André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
...
That is correct. The "false" means that Tomcat will not do it's own
authentication, and will instead rely on the authenticated user-id
passed by th
oh...@cox.net wrote:
>
> "Caldarale wrote:
> > > From: oh...@cox.net [mailto:oh...@cox.net]
> > > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
> > > authentication?
> >
> > > In other words,
oh...@cox.net wrote:
"Caldarale wrote:
From: oh...@cox.net [mailto:oh...@cox.net]
Subject: Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
In other words, even though my valve code can assert a user
into Tomcat, and even if that same user al
"Caldarale wrote:
> > From: oh...@cox.net [mailto:oh...@cox.net]
> > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
> > authentication?
>
> > In other words, even though my valve code can assert a user
> > into T
> From: oh...@cox.net [mailto:oh...@cox.net]
> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
> authentication?
> In other words, even though my valve code can assert a user
> into Tomcat, and even if that same user already exists in the
>
> > >
> > > Hi,
> > >
> > > I didn't say anything about it before, but I've been, in parallel with
> > > our discussion, mucking around both the OAM innards and the Apache source
> > > code, as best I can, trying to find out why that internal remote_user
> > > string (it is, I believe, only i
oh...@cox.net wrote:
>
> oh...@cox.net wrote:
> >
> > "André Warnier" wrote:
> > > oh...@cox.net wrote:
> > > > "André Warnier" wrote:
> > > >> oh...@cox.net wrote:
> > > >>> "André Warnier" wrote:
> > > oh...@cox.net wrote:
> > > >> Now let me ask anoth
oh...@cox.net wrote:
>
> "André Warnier" wrote:
> > oh...@cox.net wrote:
> > > "André Warnier" wrote:
> > >> oh...@cox.net wrote:
> > >>> "André Warnier" wrote:
> > oh...@cox.net wrote:
> > >> Now let me ask another question :
> > >> Why do you need to auth
"André Warnier" wrote:
> oh...@cox.net wrote:
> > "André Warnier" wrote:
> >> oh...@cox.net wrote:
> >>> "André Warnier" wrote:
> oh...@cox.net wrote:
> >> Now let me ask another question :
> >> Why do you need to authenticate the user at the Apache level, and pas
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
Now let me ask another question :
Why do you need to authenticate the user at the Apache level, and pass this user-id to
Tomcat ?
Obviously, from the OAM documentation I s
"André Warnier" wrote:
> oh...@cox.net wrote:
> > "André Warnier" wrote:
> >> oh...@cox.net wrote:
> Now let me ask another question :
> Why do you need to authenticate the user at the Apache level, and pass
> this user-id to
> Tomcat ?
> Obviously, from th
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
Now let me ask another question :
Why do you need to authenticate the user at the Apache level, and pass this user-id to
Tomcat ?
Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
for
"André Warnier" wrote:
> oh...@cox.net wrote:
> >> Now let me ask another question :
> >> Why do you need to authenticate the user at the Apache level, and pass
> >> this user-id to
> >> Tomcat ?
> >> Obviously, from the OAM documentation I scanned, there must exist an OAM
> >> module di
oh...@cox.net wrote:
Now let me ask another question :
Why do you need to authenticate the user at the Apache level, and pass this user-id to
Tomcat ?
Obviously, from the OAM documentation I scanned, there must exist an OAM module directly
for Tomcat, to authenticate users there. Why are you n
> Now let me ask another question :
> Why do you need to authenticate the user at the Apache level, and pass this
> user-id to
> Tomcat ?
> Obviously, from the OAM documentation I scanned, there must exist an OAM
> module directly
> for Tomcat, to authenticate users there. Why are you not usi
oh...@cox.net wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the
Apache-to-Tomcat connection. I have a sniff from earlier
oh...@cox.net wrote:
>
> "André Warnier" wrote:
> > André Warnier wrote:
> > > oh...@cox.net wrote:
> > >> oh...@cox.net wrote:
> > >>> P.S. I forgot to mention:
> > >>>
> > >>> As you know, I'd been using a sniffer, to see the data on the
> > >>> Apache-to-Tomcat connection.
"André Warnier" wrote:
> André Warnier wrote:
> > oh...@cox.net wrote:
> >> oh...@cox.net wrote:
> >>> P.S. I forgot to mention:
> >>>
> >>> As you know, I'd been using a sniffer, to see the data on the
> >>> Apache-to-Tomcat connection. I have a sniff from earlier, where I
> >>> w
André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the
Apache-to-Tomcat connection. I have a sniff from earlier, where I
was using "ProxyPass ajp://", and, comparing that sniff vs. a sniff
oh...@cox.net wrote:
oh...@cox.net wrote:
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the Apache-to-Tomcat connection. I
have a sniff from earlier, where I was using "ProxyPass ajp://", and, comparing that
sniff vs. a sniff that I have from when
oh...@cox.net wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
.. re-synchronising..
I've made some progress. I have a VirtualHost, so I had to add a "JkMountCopy 'on'"
inside the , and now, it's at least
oh...@cox.net wrote:
> P.S. I forgot to mention:
>
> As you know, I'd been using a sniffer, to see the data on the
> Apache-to-Tomcat connection. I have a sniff from earlier, where I was using
> "ProxyPass ajp://", and, comparing that sniff vs. a sniff that I have from
> when I tested
P.S. I forgot to mention:
As you know, I'd been using a sniffer, to see the data on the Apache-to-Tomcat
connection. I have a sniff from earlier, where I was using "ProxyPass ajp://",
and, comparing that sniff vs. a sniff that I have from when I tested with your
suggested , in the latter snif
oh...@cox.net wrote:
>
> "André Warnier" wrote:
> > oh...@cox.net wrote:
> > > "André Warnier" wrote:
> > >> oh...@cox.net wrote:
> > >>
> > >> .. re-synchronising..
> > >>> I've made some progress. I have a VirtualHost, so I had to add a
> > >>> "JkMountCopy 'on'" inside th
"André Warnier" wrote:
> oh...@cox.net wrote:
> > "André Warnier" wrote:
> >> oh...@cox.net wrote:
> >>
> >> .. re-synchronising..
> >>> I've made some progress. I have a VirtualHost, so I had to add a
> >>> "JkMountCopy 'on'" inside the , and now, it's at least
> >>> proxying thr
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
.. re-synchronising..
I've made some progress. I have a VirtualHost, so I had to add a "JkMountCopy 'on'"
inside the , and now, it's at least proxying through to the Tomcat using
mod_jk!!
BUT, it's still not logging me
"André Warnier" wrote:
> oh...@cox.net wrote:
>
> .. re-synchronising..
> >
> > I've made some progress. I have a VirtualHost, so I had to add a
> > "JkMountCopy 'on'" inside the , and now, it's at least
> > proxying through to the Tomcat using mod_jk!!
> >
> > BUT, it's still not log
oh...@cox.net wrote:
.. re-synchronising..
I've made some progress. I have a VirtualHost, so I had to add a "JkMountCopy 'on'"
inside the , and now, it's at least proxying through to the Tomcat using
mod_jk!!
BUT, it's still not logging me into the Tomcat :(...
I don't want to post the ent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim,
On 12/2/11 2:08 PM, oh...@cox.net wrote:
> Christopher Schultz wrote:
>>
>> See
>> http://tomcat.apache.org/connectors-doc/reference/apache.html.
>> Specifically, the JkRemoteUserIndicator directive which allows
>> you to override the env
oh...@cox.net wrote:
Christopher Schultz wrote:
Chris, you managed to confuse the guy..
...
To be clear, in the discussion before now, I was just using mod_ajp
and that was a perfectly valid way to connect Apache to Tomcat.
...
I'm now in the process of trying to switch my Apach
oh...@cox.net wrote:
>
> Christopher Schultz wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Jim,
> >
> > On 12/2/11 11:26 AM, oh...@cox.net wrote:
> > > Sure. Here's the section from httpd.conf. This is testing where I
> > > purposely insert a "REMOTE_USER" H
Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jim,
>
> On 12/2/11 11:26 AM, oh...@cox.net wrote:
> > Sure. Here's the section from httpd.conf. This is testing where I
> > purposely insert a "REMOTE_USER" HTTP header into the request
> > being proxied. A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim,
On 12/2/11 11:26 AM, oh...@cox.net wrote:
> Sure. Here's the section from httpd.conf. This is testing where I
> purposely insert a "REMOTE_USER" HTTP header into the request
> being proxied. As I said, I have a sniffer on the line, and I can
> s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/1/11 11:29 PM, oh...@cox.net wrote:
> Also, BTW, I just did a test where, in the Apache httpd.conf, I
> hard-coded REMOTE_USER header using RequestHeader.
>
> In my sniffer, I can see the REMOTE_USER set to the hard-coded
> string, but in my
"André Warnier" wrote:
> oh...@cox.net wrote:
> > oh...@cox.net wrote:
> >> "André Warnier" wrote:
> >>> oh...@cox.net wrote:
> >>> ...
> tomcatAuthentication="false" />
>
> >>> That is correct. The "false" means that Tomcat will not do it's own
> >>> authe
oh...@cox.net wrote:
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
...
That is correct. The "false" means that Tomcat will not do it's own authentication, and
will instead rely on the authenticated user-id passed by the front-end server.
Now could you als
oh...@cox.net wrote:
>
> "André Warnier" wrote:
> > oh...@cox.net wrote:
> > >
> > ...
> > >
> > > > > tomcatAuthentication="false" />
> > >
> > That is correct. The "false" means that Tomcat will not do it's own
> > authentication, and
> > will instead rely on the authenti
"André Warnier" wrote:
> oh...@cox.net wrote:
> >
> ...
> >
> > > tomcatAuthentication="false" />
> >
> That is correct. The "false" means that Tomcat will not do it's own
> authentication, and
> will instead rely on the authenticated user-id passed by the front-end server.
>
> N
oh...@cox.net wrote:
...
That is correct. The "false" means that Tomcat will not do it's own authentication, and
will instead rely on the authenticated user-id passed by the front-end server.
Now could you also show us the section of your Apache front-end configuration, containing
t
"Caldarale wrote:
> > From: oh...@cox.net [mailto:oh...@cox.net]
> > Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
> > authentication?
>
> > In my sniffer, I can see the REMOTE_USER set to the hard-coded
>
> From: oh...@cox.net [mailto:oh...@cox.net]
> Subject: Re: Do any of the Tomcat LDAP-type realms support "no password"
> authentication?
> In my sniffer, I can see the REMOTE_USER set to the hard-coded
> string, but in my test JSP on Tomcat, there getUserPrincipal()
&
Hi,
> > > >>>
> > > >>> I'm new here, and hope that someone can help.
> > > >>>
> > > >>> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm,
> > > >>> etc.) support an authentication mod
oh...@cox.net wrote:
>
> "André Warnier" wrote:
> > oh...@cox.net wrote:
> > > "André Warnier" wrote:
> > >> oh...@cox.net wrote:
> > >>> Hi,
> > >>>
> > >>> I'm new he
Mark Thomas wrote:
> On 01/12/2011 18:17, oh...@cox.net wrote:
> > Having said all of that, I guess that my question has changed
> > somewhat. Specifically, now I'm wondering: With what I described
> > above, and with my valve as described above, does the asserted user
> > NOT have to be
"André Warnier" wrote:
> oh...@cox.net wrote:
> > "André Warnier" wrote:
> >> oh...@cox.net wrote:
> >>> Hi,
> >>>
> >>> I'm new here, and hope that someone can help.
> >>>
> >>>
oh...@cox.net wrote:
"André Warnier" wrote:
oh...@cox.net wrote:
Hi,
I'm new here, and hope that someone can help.
I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support
an authentication mode where no password or credentials are required?
On 01/12/2011 18:17, oh...@cox.net wrote:
> Having said all of that, I guess that my question has changed
> somewhat. Specifically, now I'm wondering: With what I described
> above, and with my valve as described above, does the asserted user
> NOT have to be in the Tomcat realm at all?
Correct.
"André Warnier" wrote:
> oh...@cox.net wrote:
> > Hi,
> >
> > I'm new here, and hope that someone can help.
> >
> > I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.)
> > support an authentication mode where n
> I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.)
> support an authentication mode where no password or credentials are required?
It's hard to imagine a valid use case for this -- I hope you know what
you're doing. That said, you could use JAA
oh...@cox.net wrote:
Hi,
I'm new here, and hope that someone can help.
I was wondering if any of the LDAP-type realms (e.g., JNDIRealm, etc.) support
an authentication mode where no password or credentials are required? In other
words, where just a userID/username is presented, and if
1 - 100 of 178 matches
Mail list logo
