Hello Burak, I think you are making valid points for real business applications involving sensitive data. However, I wonder how many times a javascript client will be used for such applications. In the traditional HTML model, the client will only expose data that the server feels safe enough to expose - all other data remains on the (middleware) server. But I don't know enough about these issues - the data I am dealing with (bibliographic data) is not really sensitive - no need to encrypt anything except passwords.
What I would propose, however, concerning your SOAP contribution, is to reorganize the contribution structure according to the new contribution skeleton, i.e., separationg library code from demo application,. Also, I would propose to put the backend in a dedicated directory (I use "services" for the PHP and Python jsonrpc servers on the same level as the "source" directory). I think this would make including and using your contrib much easier. Best, Christian Burak Arslan-2 wrote: > > panyasan wrote: >> But I would be interested why you think that authentication etc. should >> be >> part of the transport? I like the idea of having a transport that is as >> transparent and simple as possible, an leave all the rest to the >> application >> and the backend. > > hi christian, > > having authentication as part of the transport as a standard will let us > put the authentication implementation inside the core library -- saving > some developer time, thus lowering the cost of qooxdoo adoption. > > having integrity and confidentiality as part of the transport is a > direct result of the routability property. SSL/TLS only works between > two points. if your message is supposed to be traveling through multiple > nodes, you need to encrypt the message itself -- tunneling it as > plaintext through an encrypted tunnel won't be enough. it's just like ip > vs ipsec. > >> It seems to me that security and authentication >> requirements are just too diverse - no one single implementation can >> satisfy >> individual use cases. The simpler the transport, the simpler you can >> debug >> it without having to use external tools. >> >> > > i think you're somewhat right for authorization and audit > implementations, but authentication, along with integrity and > confidentiality of the communication between the client and the server > are common requirements. i think those requirements can only be > implemented using a well-defined sequences of cryptographic operations. > so why not define a standard, implement them in the core library and > save everybody else the hassle? > > best regards, > burak > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://n2.nabble.com/rpc-in-qooxdoo-tp4058077p4064489.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
