On Tue, 02 Feb 2010 19:21:22 -0200, Howard Lewis Ship <hls...@gmail.com>
wrote:
Intresting. So perhaps instead of encoding the primary key of a
Hibernate entity directly, you'd instead maintain a lookup combining
user id and object id, mapped to a random string. The random string
would have to be in some kind of fast lookup table stored persistently
(perhaps in the DB for sharing across the cluster, if any).
Is the overhead worth it? As attackers car intercept the URLs, you still
need to check if the user can access that data.
Anyway, that's the kind of idea that popped into my head ... what's
your solution looking like?
Not 100% related, but I created an ActivationContextEncoder<T> interface
and corresponding ActivationContextEncoderSource service. This way, I can
have the logic for generating the activation context value for a given
type separate from its ValudeEncoder logic. The above pseudo-id lookup
logic above could be implemented in a reusable way with
ActivationContextEncoder.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
