Hi everyone
- authenticate the user (with a standard user/password parameter),
- do basic security stuff (for example, prevent code injection in
parameters),
I would definitely advocate the use of BASIC authentication as the
standard authentication approach. That way we don't need to do anything
unusual in terms of security, and we hook into an existing RFC-mandated
standard. Digest and certificate are two other alternatives, but digest
is generally suboptimal as it requires server side sessions to store the
nonce value. Certificates (X509) are great, if you have a clever way of
integrating with them.
In terms of authorization, like protecting particular service endpoints
or the other Java layers that it calls, this should be the
responsibility of the server and be beyond the scope of the Qooxdoo
Server API. Well, maybe we should specify a particular exception to be
thrown if the user is unauthorized or fails to authenticate, and also
provide a way of querying roles associated with the user. Something like:
public String[] authenticate(String username, String password);
With the String[] being a list of roles, and those roles being unable
and identifiable by Qooxdoo client-side widgets, such as being able to
hide or disable various UI controls.
I am happy to discuss security in a depth and develop a security
protocol for this integration API, as I've got a background in it due to
my involvement leading the Acegi Security project
(http://acegisecurity.org).
- convert JSON data in the parameters into native data structures
- call an named object and object method (for example,
"bibliography.getRowsBySql") - this could be a java object or a php
object - objects could also be template files which return HTML
This is already done for free by the various JSON-RPC implementations
out there. See http://json-rpc.org/wiki/implementations for a full list
of implementation. Note there are four PHP implementations, which should
make the PHP users on this list happy! :-)
- return data, indicating the mimegtype of the data (for example,
text/json, text/javascript, text/plain, text/html, x-application/xul,
text/xml, or what have you)
I don't see why you'd need to deal with this. JSON just returns a
JavaScript object that the client can eval() directly.
do you really plan to develop a backend with these features? this is a
whole applicationserver. i don't know the PHP world, but with java and
python you have lots of them.
I'd imagine the main value-add of the Qooxdoo Server API is:
- Selecting, standardising on and reusing existing technologies as far
as possible (eg BASIC authentication, JSON-RPC, XML etc)
- Using XML to define the Qooxdoo application, but without limiting the
ability to use hand-crafted JavaScript
- Well-defined server endpoints for key infrastructure integration
functions (eg a JSON-RPC service name and method signature for things
like callbacks, obtaining a list of roles etc)
- Tooling support for XML definition (namely XML schemas etc to permit
type-safe validation and auto-completion in XML editors)
- Design patterns (such as using data transfer objects, client-side
editors to edit the transfer objects, how localization is handled,
layout of directory structures etc)
- Sample application showing full interoperability
- Ultimately developing GUI tools to assist rapidly build a Qooxdoo
application, dialog editors etc using the XML syntax
As can be seen, most of this is not server-side specific at all. The
server-side platform would only need to implement the well-defined
server endpoints in the preferred language. This should be relatively
easy to achieve and minimise porting efforts. Are others seeing this API
as doing something more? Less? Other ideas? Maybe the key Qooxdoo
authors could comment on the viability of using XML in this manner
(versus hand-crafting JavaScript)?
Best regards
Ben
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
