On 21/09/2009 01:20, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Security Constraint conflict
On 9/18/2009 9:47 PM, Bill Barker wrote:
I haven't checked the Servlet 3 spec, but with earlier versions,
the union process is to give you
From: Pid [mailto:p...@pidster.com]
Subject: Re: Security Constraint conflict
The logical union of 'no methods' and 'some methods' is 'some methods',
isn't it? But...
Yes, except the spec says the operation is *not* a union when a constraint has
no roles. Rather than an or effect
Caldarale, Charles R wrote:
From: Pid [mailto:p...@pidster.com]
Subject: Re: Security Constraint conflict
The logical union of 'no methods' and 'some methods' is 'some methods',
isn't it? But...
Yes, except the spec says the operation is *not* a union when a constraint has no roles. Rather
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Security Constraint conflict
I suggest that the Servlet Spec be revised by a German engineer, to the
effect that everything not specifically allowed is forbidden.
Or we could try the quantum physics interpretation: Everything which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill,
On 9/18/2009 9:47 PM, Bill Barker wrote:
I haven't checked the Servlet 3 spec, but with earlier versions, the union
process is to give you the *least* restrictive checking (i.e. you just have
to pass one constraint to pass). And, yes, the
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Security Constraint conflict
On 9/18/2009 9:47 PM, Bill Barker wrote:
I haven't checked the Servlet 3 spec, but with earlier versions,
the union process is to give you the *least* restrictive checking
(i.e. you
We have a situation where we recently introduced a new security
constraint into our configuration that has caused a conflict with our
previous constraint. Here's our current configuration:
security-constraint
display-nameRestrict access to XHTML pages/display-name
web-resource-collection
See 13.8.1 of the servlet spec.
The result in is unioning all the constraints together for one that passes
It might be easier to write a filter to implement the restriction that
only GET/POST/HEAD is allowed.
-Tim
Peter Holcomb wrote:
We have a situation where we recently introduced a new
Tim,
Thanks for your response. I've read through the example in 13.7.2 of
the spec but I don't think I'm understanding how the union works.
According to my thought process, the url patterns are:
*.xhtml - access precluded
/* PUT,DELETE,TRACE,OPTIONS - access precluded
How does the unioning of
By the way, this works as we expected in Websphere and WebLogic.
On Fri, Sep 18, 2009 at 3:34 PM, Peter Holcomb peter.holc...@gmail.com wrote:
Tim,
Thanks for your response. I've read through the example in 13.7.2 of
the spec but I don't think I'm understanding how the union works.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
On 9/18/2009 4:34 PM, Peter Holcomb wrote:
Thanks for your response. I've read through the example in 13.7.2 of
the spec
Which version of the spec? I don't see a section 13.8 at all in either
2.4 or 2.5 of the spec. I see the heading
I was actually looking in the 3.0 spec (here:
http://jcp.org/aboutJava/communityprocess/pr/jsr315/index.html) but I
believe the same example is available in the 2.4 spec under 12.8.2.
It's the example under combining constraints.
I can't figure out the unioning process other than maybe it's
My bad - I was quoting the servlet 3.0 spec (usually the headings align)
I need to reread but it might be a bug. (I dont have the spec in front
of me) but IIRC it said something to the effect of using the url + the
HTTP method to get all applicable constraints. And then unioning them
Christopher Schultz ch...@christopherschultz.net wrote in message
news:4ab3f5f1.5060...@christopherschultz.net...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
On 9/18/2009 4:34 PM, Peter Holcomb wrote:
Thanks for your response. I've read through the example in 13.7.2 of
the spec
14 matches
Mail list logo
