> > > As it stands GAE does not allow cross data store queries, > > > and from my perspective that is an aspect of the security > > > architecture. 106 wants that aspect 'relaxed'. > > > How do you know how the current GAE code actually works? > > I read the API docs - how do you manage it?
I'm not the one asserting that there are hard boundaries between GAE datastores that the GAE run-time can't pierce. It is generally believed that GAE is built on top of BigTable, which has a lot of internal Google users. I don't know that all of them can work with only one datastore; I'd guess that several require to access multiple datastores simultaneously. So, if there is a BigTable-level "only one datastore" and/or "can't switch" restriction, I'd be very surprised if was universal or could only be pierced by suid applications. Why are you so certain that there are enough any google internal applications that require "just one datastore" and/or "can't switch" that they'd bake that option into BigTable? If there aren't any, you get to argue why they'd add it just for GAE even though GAE can provide that segregation in its run-time.... FWIW, while I haven't seen Google's BigTable API, the published info labs.google.com/papers/bigtable-osdi06.pdf, mentions an "open" call. Yes, there are probably access restrictions on said open call, but what are the odds that there's a user per GAE application and said application's datastore is only accessible to said user? > > 106 or any of the variants that I've mentioned would merely make "open > > datastore" available through some appropriate safeguards and would be > > just as secure as the current system. > > Let's examine the token idea - and assume you have obtained N tokens > securely. Not so fast. Who said anything about application visible tokens? In fact, it could be just "change_to_application_userstore", where a userstore is an ordinary GAE datastore. This could easily be written so it doesn't take any parameters from application code, which makes it just as secure as an "open datastore" call done at process startup. Or, it could support one token, so the application has access to the "default" datastore and a datastore determined by such a call. Again, that call need not take parameters from application code. On Jan 5, 6:34 am, hawkett <hawk...@gmail.com> wrote: > On Dec 30 2008, 3:14 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > No, I would prefer GAE to implement the system completely, using > > > existing elements. > > > I was unaware of the weight that your preferences have. > > Isn't that what a feature request is? Should I raise feature requests > for other people's preferences? What a strange statement. > > > I note that your implementation requires new elements, namely > > additions to app.yaml. > > And you fail to note that I said it was not a requirement. e.g. you > could achieve the same thing when you deploy the app (e.g. when you > choose to tie it to a domain or not), or via configuration in admin > console. > > > > As it stands GAE does not allow cross data store queries, > > > and from my perspective that is an aspect of the security > > > architecture. 106 wants that aspect 'relaxed'. > > > How do you know how the current GAE code actually works? > > I read the API docs - how do you manage it? > > > 106 or any of the variants that I've mentioned would merely make "open > > datastore" available through some appropriate safeguards and would be > > just as secure as the current system. > > Let's examine the token idea - and assume you have obtained N tokens > securely. You can easily introduce a bug in your application code > that uses the wrong token for the wrong end-user. Secure access, > buggy exposure of customer data. Your idea does not prevent the cited > bug, because it is not an alternative to strict data partitioning. > This is not a solution to the concerns of the original poster. > Perhaps I have misunderstood your implementation? > > > I don't know Google's code either, but it is generally believed that > > BigTable is used in many internal Google applications. The easy way > > to make BigTable available to applications is via such a routine > > called byapplication-space code. To the extent that GAE's datastore > > is "just" a BigTable wrapper.... > > I think you are probably over-simplifying the meaning of BigTable. > BigTable is indeed used by many internal applications (as I understand > it), and as previously stated, I would expect (don't know) that the > data segregation required to achieve this would not be implemented by > each of those internal applications, but by lower level features in > BigTable. Move common use cases to the platform level. > > On Dec 30 2008, 3:14 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > No, I would prefer GAE to implement the system completely, using > > > existing elements. > > > I was unaware of the weight that your preferences have. > > > I note that your implementation requires new elements, namely > > additions to app.yaml. > > > > It would allow some great additions, such as a > > > common billing and payment engine - something most app developers > > > would love to have taken off their plate. > > > There are lots of other implementations that have that property, as > > well as the others described below. > > > > As it stands GAE does not allow cross data store queries, > > > and from my perspective that is an aspect of the security > > > architecture. 106 wants that aspect 'relaxed'. > > > How do you know how the current GAE code actually works? > > > One possible implementation that satisfies every currently observable > > behavior involves an "open datastore" routine that is passed the name > > of the relevant datastore and called by Google code that lives > > inapplicationspace. This routine returns a token that is used by every > > datastore access routine. (A given process may access the datastore > > on behalf of urls that require login as well as ones that don't so > > whatever mechanism connects a process to a datastore probably does not > > require any user credentials. However, "open datastore" may use app- > > specific credentials baked into theapplicationby google's set up > > code.) There are a number of places where "open datastore" could be > > called. > > > 106 or any of the variants that I've mentioned would merely make "open > > datastore" available through some appropriate safeguards and would be > > just as secure as the current system. > > > I don't know Google's code either, but it is generally believed that > > BigTable is used in many internal Google applications. The easy way > > to make BigTable available to applications is via such a routine > > called byapplication-space code. To the extent that GAE's datastore > > is "just" a BigTable wrapper.... > > > On Dec 30, 6:17 am, hawkett <hawk...@gmail.com> wrote: > > > > > "The system" in this case is the combination of the GAE platform and > > > > anapplicationrunning on said platform. > > > > No, I would prefer GAE to implement the system completely, using > > > existing elements. How? In app.yaml, you specify that your > > >applicationsupports mapping multiple google apps user spaces to your > > > app. Currently it only allows one. This is anapplication > > > marketplace type concept. When my app is added, a new data partition > > > is created for their users. Most importantly I am the administrator > > > of the app and all of the data partitions - this is different to > > > deploying my app to their GAE account - it still resides in my > > > account, and the customer has no administrative rights beyond what I > > > give the in myapplicationcode. I need only have one app deployed. > > > > With this model, registration, user provisioning, authentication and > > > data partitioning are all handled external to myapplicationcode > > > using building blocks that are already present in the GAE offering. > > > The only change to myapplicationcode from right now is an entry in > > > app.yaml. It's not even particularly complicated - especially for me, > > > theapplicationdeveloper. I can imagine implementations that don't > > > even require the app.yaml entry. > > > > I'll admit (as I'm sure you will) that this thread has led me to think > > > more deeply about the implementation of the use case from my original > > > post, but the above is not excessive, and is much preferable to > > >applicationcode. It would allow some great additions, such as a > > > common billing and payment engine - something most app developers > > > would love to have taken off their plate. > > > > Yet another feature this would allow - version migration for > > > customers. I deploy separate versions of my app, and have the ability > > > to move customer data partitions between app deployments. An obvious > > > use case is that some customers may be happy to try new features in > > > beta, others may want to wait for release versions. It is worth > > > noting that google apps essentially supports this feature currently > > > with the checkbox indicating that you want the latest features. > > > > These are all major development efforts that carry significant risks > > > to your customers, and are mostly diversions to core creative > > >applicationdevelopment. Common use cases should be moved to the > > > platform layer, freeing the developer to actually build their > > >application. This, I think, is a good summary of the stated goals of > > > GAE platform. > > > > I'll add the above implementation as a suggestion to 945 to clear up > > > any misunderstanding about platform vsapplication. > > > > > The GAE security architecture is not based on "not allowing cross data > > > > store queries". It's based on authenticated access to partitioned > > > > datastores, which is a very different thing. > > > > I did say - > > > > '...security architecture of GAE is based on trustable external > > > authentication, data partitioning, mapping that data partition to the > > > authenticated entity, and not allowing cross data store queries' > > > > I realise they are different things, that's why I listed them > > > separately. As it stands GAE does not allow cross data store queries, > > > and from my perspective that is an aspect of the security > > > architecture. 106 wants that aspect 'relaxed'. > > > > While I don't think GAE will implement cross data store queries using > > > the data API (I still think exposing anapplicationAPI to access said > > > data, or supporting one data partition for many apps is the right > > > choice), a possible implementation that would be acceptable to me is > > > adding an entry to app.yaml specifying how strict data partitioning > > > should be for anapplication. For my use case I would choose the > > > strictest option, and for yours something less so. It's not ideal, as > > > an error in app.yaml could lead to the cited bug, but the risk profile > > > much less, and more easily auditable. > > > > On Dec 30, 12:53 am, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > 'The system spawns a virtual instance of the app - or at least allows > > > > > mapping a single datastore partition to the authenticated entity. You > > > > > coudl extend it by allowing multiple datastores per authenticated > > > > > entity and choosing the appropriate one at authentication time.' > > > > > > I haven't mentionedapplicationcode at all. If you have interpreted > > > > > 'the system'' to mean myapplicationcode, then I think you are being > > > > > disingenuous. > > > > > "The system" in this case is the combination of the GAE platform and > > > > anapplicationrunning on said platform. > > > > > > What's the point of a feature request for my ownapplicationcode? > > > > > Oh really? The reason that this requires a feature request is that it > > > > isn't (currently) possible for anapplicationrunning on GAE to > > > > request the creation of another datastore. (One could call an outside > > > > agent to request anotherapplication, but ....) > > > > > > Do you support request 106? > > > > > Yes. > > > > > > Do you oppose 945? > > > > > Not sure. > > > > > > At the moment, I am getting the idea you support 106, > > > > > but not the implication that it would support queries across > > > > > datastores. > > > > > 106 allows anapplicationto access multiple datastores, so why would > > > > I > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
