On 19/06/2020 14:38, Christopher Schultz wrote:
> Mark,
>
> On 6/9/20 08:13, Mark Thomas wrote:
>> On 08/06/2020 22:29, Christopher Schultz wrote:
>>> I think that's enough for now. So the questions are:
>>>
>>> 1. Does anyone really want Tomcat to be worried about this stuff?
>>> I know the answer is "some people care" but I want to get a sense
>>> of how many actually care. So if you think this would be a good
>>> thing to implement in one way or another, please speak up.
>
>> My instinct is that this is a fairly rare requirement at the
>> moment.
>
> As I think more about this, I think it's important that we investigate
> this a little further. Especially because I do not think it will be
> terribly complicated.
>
>>> 2. If we implement this, is it okay to change the API to do so?
>>> I think we can do this in a backward-compatible way so that we
>>> don't have to e.g. use an ObjectOutputStream to write a byte[]
>>> which has been encrypted after using another ObjectOutputStream
>>> to generate those bytes for storage.
>
>> It depends which API. There are lots of 3rd-party session managers
>> so we need to be very careful. Default methods could be useful.
>
>> I'm wondering if we need a new Filter/Valve/Interceptor style API
>> for this. Or a wrapper around an existing store. Or a wrapper
>> around an existing Manager. Or...
>
> I've been looking at where ObjectOutputStream is being used in Tomcat
> code, and it's quite limited:
>
> XByteBuffer (not relevant)
> DeltaManager (serves a different purpose)
> StandardManager
> JDBCStore
> FileStore
>
> Obviously, it's the last 3 of these which are interesting to me.
>
> StandardManager, when configured with a pathname (or left to default
> SESSIONS.ser), will use a local-file to store *all* sessions when
> Tomcat is shutting-down, and will load from that file on startup. This
> is fundamentally different from the session Store concept which deals
> with sessions individually instead of in bulk.
>
> The Store interface and the various implementations thereof deal with
> individual session-storage.
>
> So I think we need separate solutions for each of the two above cases,
> even if they end up sharing a lot of code (e.g. implementation of an
> encrypted wrapper).
>
>> I think we need to look a some of the 3rd party session managers
>> out there to get an idea of how this might integrate with them. Or
>> if that is even possible.
>
> If we can do this at the Manager/Store level (separately) then I think
> we won't disturb 3rd-party session managers. If we package the code in
> a helpful way, 3rd-party session managers could probably re-use the
> code if it makes sense to do so.
>
> What is a little strange is that the JDBCStore and FileStore
> implementations delegate the session serialization to the
> StandardManager, probably in the spirit of code-reuse. Here is where
> the unfortunate internal Tomcat API is working against us:
> StandardManager.writeObjectData accepts an ObjectOutputStream instead
> of an OutputStream.
>
> What if we add something like this in StandardSession:
>
> public void writeObjectData(OutputStream out) {
> if(encrypt) {
> out = addEncryptionDecorator(out);
> }
>
> writeObjectData(new ObjectOutputStream(out));
> }
>
> This should not disturb any existing code.
>
> We update the Store implementations to call
> writeObjectData(OutputStream) instead of
> writeObjectData(ObjectOutputStream). Any 3rd-party session manager can
> use addEncryptionDecorator() if it wants to, and any 3rd-party Store
> implementation can use writeObjectData(OutputStream).
>
> StandardManager's implementation of bulk-session-storage can create a
> single encrypted stream and continue to call
> writeObjectData(ObjectOutputStream) as before.
>
> Symmetric changes to readObjectData would be made as well.
>
> WDYT?
Looks good.
I'm just wondering how far we need to go in making this generic /
customisable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
