I think I get the OP's requirements. The main use cases that I can think of are wanting to give a tier of developer-users a server-side scripting capability but limit and/or monitor their access to the datastore. For such use cases manually monitoring developers is neither possible nor desirable. Think of it as equivalent to the capability that "setuid" and "sudo" give to general UNIX users. Such use cases may seem "off the reservation" for most customer facing webapp developers, but I can see them fairly common for GAE4B applications where the line between intranet and internet is blurred. I don't see a practical way to handle this in Python without Google's help, and it may be too much of a corner case for them at this time. But it does seem like a valid interesting question and possibly a feature request.
John On Sep 25, 12:41 pm, Robert Kluin <[email protected]> wrote: > Having a front-end to your datastore just to prevent other devs > accessing it is just going to add much complexity and will probably > cause problems. One major concern would be the amount of latency it > is going to introduce latency to your app. > > I think you need to look at why you are keeping the other devs out to > decide what to do. > > I think Eli made several good general suggestions: > 1) Use version control. > 2) Only give app admin access to a few devs. > 3) Have a 'testing' instance(s) on production other devs can access so > code can be properly tested during development. > > If you are implementing some type of QC, are protecting the data, or > just don't trust your coders: > 1) make them submit changesets to a staging repository. > 2) review all changesets and, if accepted, push them upstream to your > production repository. > 3) do what ever testing you do. > 4) push the reviewed and tested code to your production environment. > > If you are trying to protect some proprietary business logic I would > do something similar to above. Setup a repository with the main > front-end code in it for devs to access and include some type of stubs > for your logic in it. Keep your BL in a separate repository only you > have access to. Setup your build environment to properly replace the > stubs with the real modules before testing and deploying. > > Robert > > > > On Fri, Sep 24, 2010 at 13:47, rvjcallanan <[email protected]> wrote: > > Ok I get it: "A lock is only to keep an honest man out!". Bump! > > > On Sep 24, 2:37 pm, rvjcallanan <[email protected]> wrote: > >> A little early perhaps...bump! > > >> On Sep 24, 10:50 am, rvjcallanan <[email protected]> wrote: > > >> > Hi all, > > >> > I have a requirement to place a thin "security" layer between the > >> > Datastore and my App proper. I need to be able to lock down this layer > >> > and prevent other coders from bypassing it and performing raw > >> > Datastore operations directly. > > >> > I am thinking about a dual App approach where one App is a wrapper for > >> > its own datastore and the other App implements the main functionality > >> > (persisting to the Datastore of the first App via a simple API). This > >> > is obviously not ideal for a number of reasons which I won't go into. > > >> > My question: Is there any way of achieving the same level of > >> > modularisation within a single App? Python seems weak in that > >> > respect. I am not familiar with the Java implementation of the GAE. > >> > Does it fare any better? Are there any non-language mechanisms > >> > available to help here? > > >> > Note: I don't want to get into a separate debate about trust and > >> > security. > > >> > TIA > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
