On 20/04/2013 07:04, David Jencks wrote:
> Hi Mark,
>
> I hope my being tired doesn't come across as being unpleasant… if so
> I apologize in advance.
Not at all. No need to apologize.
> I think a lot of the security discussion in the servlet spec is vague
> and misleading. I think the JACC spe
On Apr 21, 2013, at 11:37 PM, David Jencks wrote:
> On Apr 21, 2013, at 3:56 PM, Jeremy Boynes wrote:
>
>> On Apr 19, 2013, at 11:04 PM, David Jencks wrote:
>>> IMO you have misinterpreted roles in the ee specs. The specs including the
>>> servlet spec define application roles and base the d
On Apr 21, 2013, at 3:56 PM, Jeremy Boynes wrote:
> On Apr 19, 2013, at 11:04 PM, David Jencks wrote:
>> IMO you have misinterpreted roles in the ee specs. The specs including the
>> servlet spec define application roles and base the declarative security
>> constraints on them. Then you can
On Apr 19, 2013, at 11:04 PM, David Jencks wrote:
> IMO you have misinterpreted roles in the ee specs. The specs including the
> servlet spec define application roles and base the declarative security
> constraints on them. Then you can map strings that bits of the application
> like, at leas
Hi Mark,
I hope my being tired doesn't come across as being unpleasant… if so I
apologize in advance.
I think a lot of the security discussion in the servlet spec is vague and
misleading. I think the JACC spec provides a firmer basis for thinking about
how security is supposed to work.
IMO y
Currently, Tomcat only checks against elements if
there is a call to isUserInRole(). Prior to Servlet 3.0 this made sense.
The person deploying the web application has control over web.xml and
hence the security roles (those used in security constraints) but no
control over application roles (thos
