Hi Anders,
On 01/02/17 14:11, Anders Rundgren wrote:
Hi Sergey,
Thank you very much for looking into this, I really appreciate it!
Np at all, many thanks for getting engaged with the CXF community :-)
A snag is that JCS relies on ES6-compatible JSON serialization which is
standard
in the JavaScript world (Browsers and Node.js), but not (yet) in Java.
That is OK. The important thing is what goes on the wire and a given
Java based JSON parser (as long as it is Java based) can produce
whatever real JSON which is needed for some feature to interoperate with
the remote HTTP consumers/producers.
Introducing yet another JSON parser/serializer [1] in the CXF package is
probably
not what people want so maybe I should start by creating JCS support for
"Jackson"?
The question is, given a custom bean, like MyDocument (which may have
some properties), how to intercept the JSON serialization process, so
that the signature can be calculated on the flight and the payload be
augmented with the @signature property.
If MyDocument has JAXB annotations and depends on a JAXB XML to JSON
conversions then perhaps we can register a JCS XMLStreamWriter (and
XMLStreamReader on the read side) which is possible for ex with CXF
JSONProvider (Jettison based).
If Jackson allows to intercept the serialization process then perhaps it
is possible to use Jackson.
May be the simplest option to start, for POC, is to have CXF filters
caching the stream, and then reading it, adding or validating the
signature, and then letting the request flow.
For YASMIN integration I'm thinking of something like the following:
https://cyberphone.github.io/doc/web/yasmin.html#apimapping
How you could add signature support through annotations is not entirely
clear.
Sure that cab investigated later on...
Thanks, Sergey
Cheers,
Anders
PS I will use the issue you created
https://issues.apache.org/jira/browse/CXF-6532
for future discussions on basic JCS integration.
1]
https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/package-summary.html
On 2017-02-01 14:07, Sergey Beryozkin wrote:
Hi Anders
Thanks for sharing the link to a new scheme :-)
FYI, as far as CXF is concerned, CXF users do all sort of services,
SOAP, pure REST, or simply HTTP with whatever communication scheme they
prefer :-).
As far as YASMIN is concerned from the prospect of having something like
that done in CXF, I'd like to consider it possibly done in 2 steps:
1. Support JCS - we'd let CXF users JCS-sign arbitrary JSON payloads,
they won't need to be YASMIN-bound. JCS allows for that, so we could
have a JAX-RS JCS filter or MessageBodyWriter which signs JSON.
2. Offer some YASMIN-specific model support etc with the implicit
conversion of the custom data to YASMIN payloads.
What do you think ? We can discuss 1. at
https://issues.apache.org/jira/browse/CXF-6532
FYI a CXF JCS empty module (not included in the Maven build) is already
available in the source
Thanks, Sergey
On 28/01/17 05:50, Anders Rundgren wrote:
This is a considerably updated version of the scheme I sent earlier.
Enjoy!
-------------------------------------------------------------
WebSocket [1] is claimed to be the most efficient communication method
for interactive Web applications.
REST [2] is essentially incompatible with WebSocket although some people
try to merge them. That's IMO fairly pointless, since they are building
on different concepts.
YASMIN [3], OTOH was designed from scratch to support both event-based
communication like WebSocket and postMessage(), as well as traditional
request/response schemes.
Anders
1] https://tools.ietf.org/rfc/rfc6455.txt
2] https://en.wikipedia.org/wiki/Representational_state_transfer
https://cyberphone.github.io/doc/web/REST-in-peace.html
3] https://cyberphone.github.io/doc/web/yasmin.html
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
