[
https://issues.apache.org/jira/browse/TAP5-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052883#comment-13052883
]
Josh Canfield commented on TAP5-53:
-----------------------------------
I'm probably missing something obvious, but isn't this the whole point of the
HttpSession?
It's a per-user server-side datastore that has built in cluster support
provided by the application server. Only the session-id is sent to the client,
and the data stays on the server?
If you have memory concerns you can store your sessions in a database instead
of in memory, via well-known app server configurations.
> Mechanism to send pointers to serialized data to the client, not the data
> itself
> --------------------------------------------------------------------------------
>
> Key: TAP5-53
> URL: https://issues.apache.org/jira/browse/TAP5-53
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> Tapestry has the capability to store much data on the client, whether it is
> persisted page fields, or Form component action data. This presents a couple
> of problems; first, it inflates the size of the rendered HTML stream.
> Second, it is a potential security issue, since a hyper-intelligent black hat
> might find a way to change such data before returning it.
> What if Tapestry stored the associated bytestreams on the server, and
> provided, in the HTML, just a relatively short pointer (a string id that
> points to the correct bytestream) to the stream?
> A small amount of additional data on the server side could be used to
> authenticate the pointer, using the user's session id (if a session exists)
> and host ip.
> Unreferenced data would be periodically purged.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
