On 7/10/12 11:57 AM, Mark Thomas wrote:
> On 10/07/2012 15:39, Jeff Williams wrote:
>> Adding a method to allow developers to change the session id is good.
>> Even better would be if the session id rotation happens automatically
>> upon logon().
> +1. I'd like to see language to this effect added to specification.
>
>> Then having a separate method for developers to force a
>> session id change is largely unnecessary (but probably useful for legacy
>> apps).
> -1. Container authentication is not the only way authentication is
> provided. There are lots of frameworks that provide authentication and
> they need the ability to change the session ID (without destroying the
> actual session) as well.
For instance, JASPI (JSR 196) auth modules would like to use the API.
>
>> I'm not sure I understand why anyone would want to have a listener for
>> this event. Using the sessionid for anything other than the session is
>> an antipattern in my opinion. Having a listener might encourage this
>> and end up exposing the sessionid in new ways, undermining the purpose
>> of the method.
> -1. There are lots of valid reasons why the change in session ID needs
> to be advertised. Clustering is the most obvious as the other nodes in
> the cluster need to know that a session's ID has changed.
>
>> But as I mentioned last week, I'm concerned that we're not helping
>> developers out with the most important risks...
>>
>>> At some point, the servlet team is going to have to start
>>> providing support to developers for protecting against
>>> web attacks. At least if we want people to use it for critical
>>> apps. XSS, CSRF, header injection, HPP, Clickjacking,
>>> open redirect/forward, sidejacking, URL rewriting, etc...
>>> they're all relatively easy to fix but nobody does.
>>> How about something that helps developers manage all
>>> the security-critical headers that have come out (X-Frame-
>>> Options, X-XSS-Protection, X-Download-Options, Strict-
>>> Transport-Security, etc...)
>> Is there interest here in addressing some of these issues? Or is this
>> the wrong forum?
> Make some concrete proposals and they'll get considered. Keep in mind
> that the J2EE EG's place a very high priority on backwards compatibility.
>
> Mark