RFR[15] JDK-8244683: A TSA server used by tests

sha.jiang at oracle.com sha.jiang at oracle.com
Wed Jun 3 14:14:48 UTC 2020


Hi Max,

On 2020/6/3 17:17, Weijun Wang wrote:
> TimeStampCheck.java:
>
> - Can you please inline all those private getXyz() calls in Interceptor into getRespParam()? I would like to see all these customizations in one place. Just add a blank line in between and it will be clean enough for me.
OK

>
> TsaParam.java:
>
> - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals.
One usage of this class is carrying all parameters delivered by HTTP
request. Do you mean they should be grouped in different classes?

>
> The overall design is good, but I have a feeling that the interface and implementation can be further separated. I can see that there are a lot of methods and classes that will not be touched by TimeStampCheck at all. Should these things be taken out to be another implementation which is parallel to the one in TimeStampCheck? Maybe TsaHandler::createSigner will be abstract.
All RespInterceptor methods are used by TimeStampCheck.
DefaultRespInterceptor is used by standalone TSA server. In this style, no
more RespInterceptor implementation is needed.

>
> There are quite some public constructors in the classes. Are they meant to be called by a user? Or by a child class? Or just internal?
The public constructors in TsaServer can be called by applications for
making standalone servers.

>
> Also, for those protected methods (Ex: parseRequestParam and createResponse in TsaSigner), do you meant to override it in the future?
Possibly.
For example, a sub parseRequestParam() may need to parse extensions from
request. A test may directly twist the byte[] returned by createResponse(),
or even an overridden createResponse() just returns an empty byte[].

>
> Can you give examples on how to use this server? Will it always use DefaultRespInterceptor? If so, will the default impl in RespInterceptor.java ever be used?
I'll use this server as standalone-like service. The custom TSA fields
just be delivered by HTTP request query string. I won't provide a custom
RespInterceptor, and DefaultRespInterceptor is enough to me.

Best regards,
John Jiang




More information about the security-dev mailing list