On Fri, 30 Aug 2013 17:51:17 -0300, Muhammad Gelbana <m.gelb...@gmail.com>
wrote:
I'm asking because having a maintained session between the client and the
server is a better scenario. Instead of having to authenticate the user's
credentials upon every request.
As far as I know, that's how almost any webservice works and you're
swimming against the tide here. As Lance already said, doing this or not
depends on what the client is. If it uses HttpClient, it already supports
cookies, so you don't need to change anything server-side. If not, then we
need to know how the client is implemented to give y
I'm aware there are other standard methods to have a statefull web
service, but I haven't explored that area yet, and I thought it could be
done faster and easier using the
ApplicationStateManager. Frankly the idea is not fully developed in my
head.
The problem with this is that you have to handle the session creation
yourself and knowing which session should be used in a given request.
That's a difficult problem that, if not implemented very, very carefully,
can lead to session hijacking and other security problems.
ApplicationStateManager is the service that handles the @SessionState
annotation, so you can override, advice or decorate to make it work anyway
you want.
Also I always like exploring all possible options to always be free to
chose whatever fit my needs more, and I always like to know more Tapestry
tricks.
Nice. :) The problem here, if I got it right, is that you want to replace
a functionality which isn't implemented by Tapestry itself (session
handling), being implemented by servlet containers instead. Of course, you
can take a look at the sources of Jetty and Tomcat to know how they deal
with sessions.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
