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.
> 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