Jeanfrancois Arcand wrote:
Now the big question: do we plan to have that JSR 115 support for the
next stable release, or is it too early to have it done ?
Since there is still some gray area I need to think of, I would say no.
But let me think of it :-)
Well, since we don't have any really urgent
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Mmm, ok. I'm not quite following very well, since I didn't read the
spec yet ;-) If I understand, you would implement something which
would work as the JSR 115 security policy provider, but (likely :) )
simpler ?
Yes, as a first steps. It wi
Jeanfrancois Arcand wrote:
Mmm, ok. I'm not quite following very well, since I didn't read the
spec yet ;-) If I understand, you would implement something which
would work as the JSR 115 security policy provider, but (likely :) )
simpler ?
Yes, as a first steps. It will also works without a secu
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Zzzzoui :-)
I will do that (on my own time unfortunalty, so may take a couple of
weeks)
First, it would be easier just to convert the web.xml into security
permissions, and to keep internal collections, for unchecked,
excluded, and role
Jeanfrancois Arcand wrote:
Zzzzoui :-)
I will do that (on my own time unfortunalty, so may take a couple of
weeks)
First, it would be easier just to convert the web.xml into security
permissions, and to keep internal collections, for unchecked, excluded,
and role permissions than to do all
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Not yet, but it is one of the thing I want to do when I've found
spare time. For sure (5.0.x + sec manager) is faster than (5.0.x +
sec manager + jsr115) since with 115, the policy provider is called
everytime hasUser/ResourcePermission are ca
Jeanfrancois Arcand wrote:
Not yet, but it is one of the thing I want to do when I've found spare
time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager
+ jsr115) since with 115, the policy provider is called everytime
hasUser/ResourcePermission are called, and this approach ca
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Brian Stansberry wrote:
At 10:03 PM 12/8/2003 -0800, you wrote:
The decision on whether to change the Realm interface, or
move the header processing to AuthenticatorBase is still open.
So soon after such a major release
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Brian Stansberry wrote:
At 10:03 PM 12/8/2003 -0800, you wrote:
The decision on whether to change the Realm interface, or
move the header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolha
Jeanfrancois Arcand wrote:
Brian Stansberry wrote:
At 10:03 PM 12/8/2003 -0800, you wrote:
The decision on whether to change the Realm interface, or
move the header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolhardy to bring this
up, bu
Brian Stansberry wrote:
At 10:03 PM 12/8/2003 -0800, you wrote:
The decision on whether to change the Realm interface, or
move the header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to ha
Brian Stansberry wrote:
At 10:03 PM 12/8/2003 -0800, you wrote:
The decision on whether to change the Realm interface, or move the
header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolhardy to bring this
up, but Phillipe's post seems to have opened
Bill Barker wrote:
Ok, I take back my . It seems that they have really made a hash out
of the security-constraints. Something like Philippe's implementation is
required. Section 12.8.3 requires that only the 'best match' constraints
are processed, and those in a 'grant' fashion (i.e. you get the
At 10:03 PM 12/8/2003 -0800, you wrote:
>The decision on whether to change the Realm interface, or
>move the header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolhardy to bring this up, but Phillipe's
post seems to have opened a can of worms
A
still open.
- Original Message -
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 9:00 PM
Subject: Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
uot;Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 6:00 AM
Subject: Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
> Yes, this looks like it changed between pfd3 to fr :(.
Security-constraints
> now work like '
Opinions, Comments, Flames?
- Original Message -
From: "philippe.leothaud" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 6:43 PM
Subject: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Hi all,
I am new to Tomcat&#
Hi all,
I am new to Tomcat's mailing lists, and I don't really know if this list is the right
place for such a post : excuse me if it is not the case.
I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems
to do exactly what developers want it to do,
but more a
18 matches
Mail list logo
