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
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
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
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
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
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
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
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
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:
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
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.
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
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 UserDatabasePrincipal
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
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
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
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
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
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
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
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
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
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 deployment to allow
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 <ma...@apache.org> wrote:
> On 29/08/2015 22:26, Sreyan Chakravarty wrote:
> > Okay I have just started to use Realms and container managed
&
ervlet+specification
Mark
>
> On Sun, Aug 30, 2015 at 9:55 PM, Mark Thomas <ma...@apache.org> 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 abo
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 security
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-:
web-resource-collection
web-resource-nameTECHERS/web-resource-name
url-pattern/teacher/success.jsp/url-pattern
On 14 Mar 2015, at 3:43 PM, Graham Leggett minf...@sharp.fm 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
On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko knst.koli...@gmail.com 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
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 entries to debug realms has had no
effect, I can still see nothing in console.out.
Can anyone
Graham,
On Fri, Mar 13, 2015 at 3:02 PM, Graham Leggett minf...@sharp.fm 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
Graham,
On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm wrote:
Hi all,
I have a basic authentication setup that works great as below.
login-config
auth-methodBASIC/auth-method
realm-namePatricia/realm-name
/login-config
Graham,
On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm 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
On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com 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
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com 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
Hi all,
I have a basic authentication setup that works great as below.
login-config
auth-methodBASIC/auth-method
realm-namePatricia/realm-name
/login-config
!-- Security roles referenced by this web application --
security-role
Graham,
On Fri, Mar 13, 2015 at 4:43 PM, Graham Leggett minf...@sharp.fm wrote:
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:
Just to confirm, the 403 Forbidden page was rendered by Tomcat, not
Apache
HTTPD?
Yes, it is branded tomcat and appears in the
2015-03-13 23:43 GMT+03:00 Graham Leggett minf...@sharp.fm:
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com 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
Graham,
On Fri, Mar 13, 2015 at 4:49 PM, Graham Leggett minf...@sharp.fm wrote:
On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:
What doesn’t seem to fit is the realm definition - specifying
userCredCol
is marked as mandatory, but this is obviously not
.
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 entries to debug realms has
On 02.12.2011 17:49, André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
tomcatAuthentication=false /
That is correct. The false means that Tomcat will
Rainer Jung rainer.j...@kippdata.de wrote:
On 02.12.2011 17:49, André Warnier wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
oh...@cox.net wrote:
...
Rainer Jung rainer.j...@kippdata.de 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,
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Rainer Jung rainer.j...@kippdata.de 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
On 05.12.2011 10:42, oh...@cox.net wrote:
André Warniera...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Rainer Jungrainer.j...@kippdata.de 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
Rainer Jung rainer.j...@kippdata.de wrote:
On 05.12.2011 10:42, oh...@cox.net wrote:
André Warniera...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Rainer Jungrainer.j...@kippdata.de wrote:
Although this thread has moved forward towards the role topic, I want to
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
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
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 I
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
André Warnier a...@ice-sa.com 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
was using
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
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 using
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
André Warnier a...@ice-sa.com 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
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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,
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
Now let me ask another question :
Why do you need to authenticate the user at the Apache
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
Now let me ask another question :
Why do you need to
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
Now let me ask
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 internal to Apache),
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
Tomcat realm, the asserted user
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 already exists
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
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.
Now could
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
tomcatAuthentication=false /
That is correct. The false means that Tomcat will not do it's own
authentication, and
will instead rely on the
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
tomcatAuthentication=false /
That is correct. The false means that Tomcat will not do it's own
authentication,
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
tomcatAuthentication=false /
That is correct. The false means that Tomcat will not do it's own authentication, and
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
...
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
tomcatAuthentication=false /
That is correct. The false means
-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
-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
see
Christopher Schultz ch...@christopherschultz.net 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
oh...@cox.net wrote:
Christopher Schultz ch...@christopherschultz.net 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
oh...@cox.net wrote:
Christopher Schultz ch...@christopherschultz.net 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim,
On 12/2/11 2:08 PM, oh...@cox.net wrote:
Christopher Schultz ch...@christopherschultz.net wrote:
See
http://tomcat.apache.org/connectors-doc/reference/apache.html.
Specifically, the JkRemoteUserIndicator directive which allows
you
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 VirtualHost, 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
André Warnier a...@ice-sa.com 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 VirtualHost, and now, it's at least
proxying through to the Tomcat using mod_jk!!
BUT, it's still
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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 VirtualHost, and now, it's at least proxying through to the Tomcat using
mod_jk!!
BUT,
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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 VirtualHost, and now, it's at least
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
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 Location, in the
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 with
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
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 JAASRealm with
http
André Warnier a...@ice-sa.com 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? In other words
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. If
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
Mark Thomas ma...@apache.org 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
oh...@cox.net wrote:
André Warnier a...@ice-sa.com wrote:
oh...@cox.net wrote:
André Warnier a...@ice-sa.com 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
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 that userID/username is present in the LDAP, then
the user gets authenticated?
You
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()
is returning null. I've tried
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
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 mode where no password or credentials are required? In other
words, where just a userID/username is presented, and if that userID/username
On 04/04/2011 06:09, Andrew Kolchoogin wrote:
Nothing helps: all Google search results refers me either to
UserDatabase Realm and conf/tomcat-users.xml (that is obviously works
well -- I've tested it) or to realm authentication for THIRD-PARTY
applications, that I'm not interested in.
Mark,
hi there!
2011/4/4 Mark Thomas ma...@apache.org:
This also looks OK, altough if you aren't interested in using the
UserDatabaseRealm, why is it still configured?
Just to test CombinedRealm functionality, althougth I've tried to
deconfigure UserDatabase entirely -- it doesn't help,
On 04/04/2011 15:13, Andrew Kolchoogin wrote:
You won't see any error messages from DataSourceRealm until you try and
use it and it fails.
Trying to login is an usage attempt?
It is gets as far as the DataSourceRealm, yes.
Enabling debug logging for org.apache.catalina.realm should show you
1 - 100 of 161 matches
Mail list logo
