Hi Matthew, Answers inline (pablo). Thanks for the feedback :)
Thanks -----Original Message----- From: Matthew Brylka [mailto:m...@tynenet.co.uk] Sent: Tuesday, June 15, 2010 10:06 AM To: stonehenge-dev@incubator.apache.org Subject: Re: [jira] Commented: (STONEHENGE-121) Proposal for M3 Hi Pablo, Sorry - didn't know that it's up already. Another few matters for consideration: - Do we save request (send it to tracking service) if it was invalid? (Pablo) Yes, we do as long as the request message is a valid xml. - If we save request that is invalid, how do we know if it's not a security risk? We must not allow test client to access data that was invalid based security validation or logic. Allowing every request to go back to test client (even if's getting it from database) could corrupt the test client structure and application integrity. (Pablo) We are only storing the message if it is a valid xml. Good point, we should probably perform more validations on the messages before storing it in the repository. - What do we do if there was a fatal error within application and the request/response couldn't be sent to the tracking service. (Pablo) The tracking service currently stores two things, request/response messages and debug info. If the service failed for some reason, the details should be available as part of the debug info. - What do we do if the tracking service has problems with writing the data to the database? How should the service handle it? (Pablo) Good question. At this point, I am not sure if would be a valid point to store the messages/debug info in another place when the tracking service is not available. It would be great to hear some feedback about this. In my point of view, there two things we should accomplish: 1) Test service always gets 'some' kind of feedback, even if the request was corrupted. Simple message 'request corrupted' will do it. 2) Define a set of rules, that the service implementations could use to determine if the message was valid or not (from the security validation point of view). This will protect us from request forgery and strange injection attacks. (Pablo) Are you talking about validations in the testing service available as part of the framework we are building ?. ps. Language specific client implementations will not protect us. Kind Regards, Maciej Brylka On 15 June 2010 13:40, Pablo Cibraro <pablo.cibr...@tellago.com> wrote: > Hi Maciej, > > Yes, that's the idea, we want to store the whole raw message. Regarding the > storage for this message, we already have a tracking service in place for > that purpose. This is a restful service (In this prototype, we used OData > services for a sake of simplicity) that is currently storing the messages > into a database. > > Regards > Pablo. > > -----Original Message----- > From: Matthew Brylka [mailto:m...@tynenet.co.uk] > Sent: Tuesday, June 15, 2010 5:06 AM > To: stonehenge-dev@incubator.apache.org > Subject: RE: [jira] Commented: (STONEHENGE-121) Proposal for M3 > > Hi Pablo, > > If we plan to save the original header information - I would suggest to save > the whole raw message. > > The only tricky part if to watch out for initial language parsers. For > example PHP does interpret the message before you can output it. > > Another questions pops into my head - where are we going to save it? > Good place would be a tracking/logging service that would manage the > information and put it in a proper repository. > > Kind Regards, > Maciej Brylka > > -----Original Message----- > From: Pablo Cibraro [mailto:pablo.cibr...@tellago.com] > Sent: Friday, May 21, 2010 5:23 AM > To: stonehenge-dev@incubator.apache.org > Subject: RE: [jira] Commented: (STONEHENGE-121) Proposal for M3 > > Thanks Ben. Any feedback that you could give will be very well appreciated!. > Regarding the messages, I was thinking that we should include a way to show > complete messages with the WS-* headers, so the developer can compare the > messages generated between different WS stacks. > > Pablo. > >
