Hello;
This was the same kind of problem I envisaged being the case with a
similar technology -- WebObjects. I know this isn't a WebObjects
list, but I _think_ the same principals may apply. I can't see how,
at the application-server side that you can control authorisation
around data access if data access is automatically vended for an
object-graph over the wire. You do want to control security at the
user interface level as well of course or it would be confusing for
the users, but it would not seem to me to be good to rely on the
clients always being well behaved or not having security-related bugs.
At a basic level; in my applications, I have employed the application-
server as a JSON-RPC provider with various end-points and methods to
be accessed from JSON-RPC clients. Some of the methods require a
session to access and thus can keep an object-graph between requests
on the server-side. Each method has some sort of logic (factored out
or not) to check authorisation (nearly always using the session in
some way) in order to process some inbound request. If data objects
are returned to the client from methods then they are serialised into
JSON and the client is able to communicate back to the server using
global-ids. This approach works well for me _so_far_ although I am
sure it's not exactly the same level of elegance of having the object-
graph in the client-side.
cheers.
I am wondering about security (user, query, role level). What
approaches
have been taken by those using ROP for a some time?
We are implementing this in our Swing (Cayenne ROP) application at
the moment. The best framework we've seen is the acegisecurity
library. Quite robust and very useful. In our case though it is not
quite what we need so we are going to roll our own using some ideas
from that library.
We've found in our Swing app that we want to tie security to GUI
widgets and not database entities. In other words, we thought about
security at a Cayenne level which would have been quite easy once
https://issues.apache.org/cayenne/browse/CAY-400 gave us user
definable properties. However we had major issues about how that
would map to the GUI. We want some users to be able to edit
students in our system, but not to be able to see certain financial
data related to that student. They might be able to see other
financial data relating to courses though. It wasn't possible to
express this as a simple set of table or field properties at the
Cayenne level.
So the approach we are taking is to relate security to Swing panels
and tabs, creating add/edit/view type rights which automatically
flow down to the editable fields within those panels.
You didn't mention whether your app was Swing or web based...
___
Andrew Lindesay
www.lindesay.co.nz
