1 of 1 people found this helpful
Actually this is a limitation of JSF and Seam - both are stateful frameworks and must store its state somewhere (JSF views, Seam session and conversation scoped components). For JSF see for example this answer on stackoverflow: http://stackoverflow.com/a/5475564.
You could try:
1) Switch to JSF client state saving and use some request scoped component instead of org.jboss.seam.security.Identity (it's session scoped). Although I'm not sure this will work and would not recommend this, especially the client state saving.
2) Some workaround - e.g. use plain HTML and custom servlet for login page. However in this case you will have to bridge your Seam components somehow. Note that if you use ContextualHttpServletRequest or ContextFilter Seam will force creation of the session anyway. So I would recommend using Lifecycle#beginCall() and Lifecycle#endCall() using temporary Seam contexts...
Also consider some session timeout tweak: http://seamframework.org/Documentation/AutomaticallyExtendingSessionTimeoutForAuthenticatedUsers.
BTW I don't think it's a security issue. Threads are allocated per request, not per session. So you get the above message only if your app cannot handle all incoming HTTP requests - solution, increase the number of threads in pool.
Thank you very much for the helpful threads and suggestion, it help me to understand this issue better.
I am not sure whether it is a security issue, but one of my client complains that his competitor attacks his website which is based on seam, simulates a lot of users to access login page, because of the issue that session is created before login action, no matter how many threads in pool, the website is unavailable.