gmane.comp.java.cayenne.user

Re: ROP security

Aristedes Maniatis — 2013-05-17T00:45:49

Thanks that very interesting.




In my case I also want to prevent users from deleting objects they should not be able to. So I can deal with that with a mixture of validation rules in the entities themselves and preventing SQLtemplate from being able to be used from the client.


Ari

Re: Change data by an external process (non cayenne)

Mike Kienenberger — 2013-05-16T18:26:36

Yeah, I still have internal change events under my Cayenne 1.1 web app
project sending notifications to other sessions, and it's probably
causes most, if not all, of the few remaining weird errors I see.

At some point, I am going to totally disable it, leaving contexts
completely isolated.


On Thu, May 16, 2013 at 2:20 PM, Andrus Adamchik <andrus< at >objectstyle.org> wrote:

Re: Change data by an external process (non cayenne)

Andrus Adamchik — 2013-05-16T18:20:08


Yeah, the more I've been dealing with this over the years, the more I think our cross-context syncing features are for single user GUI apps. They should be disabled in the web apps. They don't scale (pinging all unrelated contexts in the app with random garbage), they interrupt whatever the context is currently doing, etc.

This is why I am such a fan of cache groups that are simply marked as expired. No objects are touched by an event. Events are small (essentially the event is a cache group name, no matter how many objects are affected) and hence almost infinitely scaleable.

Andrus


On May 16, 2013, at 8:49 PM, Mike Kienenberger <mkienenb< at >gmail.com> wrote:

Re: Change data by an external process (non cayenne)

Mike Kienenberger — 2013-05-16T17:49:32

Something to keep in mind for web apps is that you probably do not
want to have a data refresh at some arbitrary point during a request,
only at the beginning of a request.  It's generally better to have
your data be a second or two out of date than to have the value of an
object or object's relationships change mid-stream while you are
working with it.

I've been using the LAST_EXTERNAL_UPDATE method for several years now,
and I haven't had any regrets.   I've considered changing it over to
jms or a similar notification framework, but there weren't any
compelling reasons to do so.   This way there's no dependencies in the
external processes (most of which are not maintained or written by
me), and it's also easy to manually execute a database update and
insure that the change will become visible to the active web sessions
immediately.   On the other hand, external changes to our database are
rare.   Normally only a couple times a day.


On Thu, May 16, 2013 at 1:34 PM, Andrus Adamchik <andrus< at >objectstyle.org

Re: Change data by an external process (non cayenne)

Andrus Adamchik — 2013-05-16T17:34:45

Actually if cross-context events are in effect (which is the default), invalidating an object from a given ObjectContext will automatically invalidate it across peers. 

I would still approach it via query cache and cache groups though. All that is needed is that all contexts access those objects via a query instead of storing a direct reference.

Andrus

On May 16, 2013, at 12:14 PM, Markus Reich <markus.reich< at >markusreich.at> wrote:

Re: ROP security

Andrus Adamchik — 2013-05-16T15:11:08

On May 16, 2013, at 6:01 PM, John Huss <johnthuss< at >gmail.com> wrote:

Cool!


Here is an alternative:

   query.getMetadata(entityResolver).getObjEntity();


Agreed. You just AND it with your own qualifier and the caller will never get more objects than he's supposed to.

Andrus

Re: ROP security

John Huss — 2013-05-16T15:01:06

Here's some code we started on to do this kind of thing.  It never made it
to production, but it was close.  This just defines some methods that can
be overridden to implement security based on your specific requirements.

https://www.dropbox.com/s/g247uxpalps5xse/AuthHessianService.java

One thing I have found cumbersome is inspecting SelectQuery objects to
figure out what they are - because SelectQuery.getRoot() returns plain
Object you have to screw around to figure out what it really is.  Also
inspecting the qualifier is a little difficult, but generally that's not a
great idea anyway - better to just add things to the qualifier even if it
results in duplicate clauses.

John

On Wed, May 15, 2013 at 6:49 PM, Aristedes Maniatis <ari< at >ish.com.au> wrote:

Re: Change data by an external process (non cayenne)

Markus Reich — 2013-05-16T09:14:33

:-) sorry, I try it more detailed

I have a multiuser Tomcat Webapp, the DB (Oracle) is also updated by other
processes. A refresh is not enough to show the changed data, so my idea is
to make a servlet, which invalidates certain DataObjects (mostly it's just
one) of all thread binded contexts.
So when the user refreshes the UI and the data gets selected again, the
changed values are shown.
So it would be enough to make object hollow.

Markus


2013/5/16 Andrus Adamchik <andrus< at >objectstyle.org>

Re: Change data by an external process (non cayenne)

Andrus Adamchik — 2013-05-16T06:05:49

The question is too generic, so the answer is "yes" :) Could you describe the scenario in a bit more detail? 

Also does your interface needs to know when an object is invalidated right at that moment or is it enough to make the object "hollow" so that it is refetched lazily on next access?

Andrus

On May 16, 2013, at 7:52 AM, Markus Reich <markus.reich< at >markusreich.at> wrote:

Re: ROP security

Andrus Adamchik — 2013-05-16T05:55:36

An explicit security layer provided by Cayenne would be a great improvement to ROP. 

I am currently working on something like this for [JS -> JAX-RS -> Cayenne] stack with AJAX requests dynamically converted to Cayenne ops, and hence also prone to client hacking attempts. This one is easier to secure than ROP, as you can attach rules to individual REST resources, and also sandbox the client to just send query qualifiers and orderings (while the actual query object is created on the server explicitly). But of course something similar can be achieved in ROP.


This may be achieved with a wrapper around ClientServerChannel (can be created via DI customization) overriding 'onQuery'. I'd go with "deny all/allow SelectQuery, RelationshipQuery, ObjectIdQuery" rule. These 3 queries can be tightened up a bit too - you can filter on a root entity (and prefetch paths) and deny certain entities to certain roles. You may also add restricting qualifiers to SelectQuery (and apply the same to the results of RelationshipQue

Re: Change data by an external process (non cayenne)

Markus Reich — 2013-05-16T04:52:49

would it be possible to work with a servlet to invalidate certain objects?

Is there a way to get all ObjectStores of all Threads or is the only
solution to set the DataContext as attribute in the session?


2013/5/15 Andrus Adamchik <andrus< at >objectstyle.org>

ROP security

Aristedes Maniatis — 2013-05-15T23:49:17

We have a ROP Cayenne application we'd like to lock down a bit more tightly. In particular, in a situation where we don't trust the client application hasn't been hacked, we'd like to restrict certain activity from the client. I'm thinking of:

1. preventing SQLTemplate/EJBQL queries completely
2. adding entity listeners to catch certain write behaviour (we can't do a lot about reading data since that's easy to do at the controller level, on the client, but pretty hard to construct rules at the model level on the server)
3. creating 'partial' object entities which are missing some attributes. Sort of hollow, but only hollow on some attributes.


Has anyone attempted anything similar to the above? (2) should be easy enough, but not sure about the other requirements.


Cheers
Ari

Re: Change data by an external process (non cayenne)

Markus Reich — 2013-05-15T18:30:24

thank for the hint with the cache groups


2013/5/15 Andrus Adamchik <andrus< at >objectstyle.org>

Re: Prefetch paths

Markus Reich — 2013-05-15T18:26:30

thank you for this great snippet :-)


2013/5/15 Daniel Abrams <dabrams< at >gmail.com>

Re: Prefetch paths

Daniel Abrams — 2013-05-15T13:56:57

We do something similar to this.  Here is a snippet that will prefetch all
the relationships on a given entity.  If you want to do this via compound
keypaths, you would need to parse the keys and do this recursively, but
that might be a little dangerous in terms of fetching lots of data.

        DataContext dataContext = (DataContext) object.getObjectContext();
        ObjEntity objEntity =
dataContext.getEntityResolver().lookupObjEntity(object.getClass());

        for (Relationship relationship : objEntity.getRelationships())
        {
query.addPrefetch(relationship.getName());
        }




On Wed, May 15, 2013 at 9:42 AM, Andrus Adamchik <andrus< at >objectstyle.org>wrote:

Re: Prefetch paths

Michael Gentry — 2013-05-15T13:51:02

Personally, it seems like a bad idea to me.  If you add a relationship or
two and it automatically started prefetching them all due to wildcards, I
could see performance tanking quickly.  I'd rather explicitly state
prefetches when I know I want the data more immediately.

mrg


On Wed, May 15, 2013 at 9:42 AM, Andrus Adamchik <andrus< at >objectstyle.org>wrote:

Re: Change data by an external process (non cayenne)

Andrus Adamchik — 2013-05-15T13:48:49

I'd use query.setCacheStrategy(..) / query.setCacheGroups(..) to cache the results, and then define expiration time for a given set of cache groups for whatever cache provider is in use (EhCache most likely, so this will go into ehcache.xml). 

If you want real-time refresh, EhCache might be configured to listen to cache group refresh events via JMS. Your external process would send such events via ActiveMQ (that supports a bunch of command-line friendly protocols, not just JMS) whenever the data is changed.

Andrus
 

On May 15, 2013, at 4:28 PM, Markus Reich <markus.reich< at >markusreich.at> wrote:

Re: Prefetch paths

Andrus Adamchik — 2013-05-15T13:42:21

Yeah, Mike is right. No way to use a wildcard. All paths should be explicit. 

(Thinking whether it might be a good idea to add that in the future … )

On May 15, 2013, at 4:36 PM, Markus Reich <markus.reich< at >markusreich.at> wrote:

Re: Prefetch paths

Markus Reich — 2013-05-15T13:36:15

oops, sorry, it should be like this

query.addPrefetch("paintings.*");


2013/5/15 Michael Gentry <mgentry< at >masslight.net>

Change data by an external process (non cayenne)

Markus Reich — 2013-05-15T13:28:29

Hi,

is there really no better way than described here:
http://markmail.org/message/plnaj4zj4gxrt6hk

regards
Meex

Re: Prefetch paths

Michael Gentry — 2013-05-15T13:25:57

Hi Markus,

I don't see a wildcard there, but I don't think you can use wildcards on
prefetches.  I think you have to specify each one.

mrg


On Wed, May 15, 2013 at 8:48 AM, Markus Reich
<markus.reich< at >markusreich.at>wrote: