[google-appengine] Possible cursor exploit? (was Re: 1.3.1 SDK Prerelease - help us verify)
I don't have time to test this just now, and I hate to waste bandwidth on what (so far) is just idle speculation, but I did spot what looks like a potential security. I figured it'd be better to share it with the group than sit on it until I actually *do* have time to confirm/ deny. On Feb 16, 11:30 pm, ryan ryanb+appeng...@google.com wrote: On Feb 16, 8:46 am, Nick Johnson (Google) nick.john...@google.com wrote: As you point out, in order to use a cursor, you still have to reconstruct the original query, so a user could not modify a cursor to cause you to display records they should not have access to. +1. this is important. Very much agreed. This seems almost like it might be a reason to not pass cursors around in the clear. It contains the complete key of the next record to be returned, along with some extra information about the query. Feel free to experiment and see for yourself, of course. :) specifically, the extra information is your app id and the kinds and some property values, and possibly also property names, of one or more entities that were query results. the specific properties involved are the properties in the query. This is where I had my Wait, that sounds wrong moment. You didn't mention anything about the currently logged in user. Off the top of my head, I can think of 2 mutually exclusive scenarios. They both assume a page requires the user to be logged in, the original query used the login ID as part of the WHERE clause, and there's a cursor to page through results. 1) The user has a bunch of personal...whatever. Bookmarks that he doesn't want to share with his wife. The original query is tied to his google account. He stashes a browser bookmark halfway through the list and logs out of the site. Later, his wife uses the same computer and logs in and checks out the new bookmarks. This one requires her to log into her google account. From what I'm reading, it sounds like she'll see his data. 2) The user has a query that she wants to share. So sends some sort of private site-specific message to one of her friends.In this case, we want the cursor to maintain its original set of results, ignoring the currently logged in user. And we want the friend to be able to access that query from a completely different part of the site. I'm guessing it doesn't check to see if the current user owns that query. In many cases, it would be a waste of time to check. And, if we're using something besides the google user API, it would be a meaningless check. Another possibility that springs to mind: Mr. Cracker With Too Much Time On His Hands has a cursor with data he shouldn't see that belongs to, say, admin portions of the site. He browses the rest of your site, looking for anything else that uses cursors. He replaces those with this one. This one's probably just paranoia on my part. You did mention that cursors store Kind information. So (depending on how the API is implemented), if he happened to plug it into a page with models that had the same properties, it seems like a risk that duck-typing could work in his favor. I know I've written a few testing pages that are designed to dump the details of whichever models I happen to give them query descriptions for. They were always admin-only, and I haven't had one make it into production yet, but... I guess how dangerous this is depends totally on undocumented implementation details, and the individual app. But maybe the (hypothetical) user login issues are worth keeping in mind, I suppose they might suggest other gotchas to list members. Regards, James -- 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-appeng...@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.
[google-appengine] Re: chunked transfer encoding
Just a gut reaction...shouldn't that be self.request.post?
On Feb 20, 2:39 am, jeremy jeremy.a...@gmail.com wrote:
so using netcat as a dummy host, i've confirmed the client is sending
the data i expect:
POST /_datum/blaaah.bin HTTP/1.1
Transfer-Encoding: chunked
Content-Type: multipart/form-data; boundary=A-
mBZUkudNqt56TwNWjHhJy91U2HlskAAyqGEzwn
Host: localhost:8088
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.0-beta2 (java 1.5)
Expect: 100-Continue
2c
--A-mBZUkudNqt56TwNWjHhJy91U2HlskAAyqGEzwn
91
Content-Disposition: form-data; name=content; filename=content
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
and then a lot of scary binary data
but self.request.get('content') in the request handler returns an
empty string
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[google-appengine] Re: Local Django Slow: Could not import strop: Disallowed C-extension or built-in module...
I get this [well, the error about strop...I haven't noticed the fcntl one] on XP running through cygwin, using the source code .zip (as opposed to the msi, in case that makes any difference). I'm about 50% certain that it's coming from the SDK, but it could easily be coming from some built-in python module I'm importing that tries to load a C-optimized library then falls back to a native-python one when that fails. I haven't noticed the delay the OP mentioned, so I haven't cared enough to try to track it down. On Feb 17, 6:37 pm, boson dan.kam...@gmail.com wrote: This is on Mac OS X 10.5.6. I didn't add any external imports, but I'll go back over all of my imports anyway and see if something might be triggering it. On Jan 31, 4:41 am, Waldemar Kornewald wkornew...@gmail.com wrote: Hi, On Jan 29, 10:55 pm, boson dan.kam...@gmail.com wrote: Running Django + app-engine-patch locally... Frequently on requests (can't determine why/when) I get these two log items: DEBUG Could not import strop: Disallowed C-extension or built-in module DEBUG Could not import fcntl: Disallowed C-extension or built-in module Each one takes about half a second to come out. This isn't a big deal, but it is a little bit annoying. Is there any way to tell it to stop trying to import these modules, or speed it up somehow? Which OS do you have? I've never seen those debug messages. Do you possibly import something that uses those modules? Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Versions and datastore consistency (was Re: Deleting a field in datastore)
On Feb 16, 5:52 pm, Alexander Konovalenko alex...@gmail.com wrote: On Tue, Feb 17, 2009 at 04:25, Sridhar Ratnakumar sridhar.ra...@gmail.com wrote: A related question - is there a way to have two versions of datastore so that I can run 'production' and 'staging' instances of my app? In case, if I want to test new features without messing up the production datastore, I can use the staging datastore. If not, what is the appropriate way to do this? I'm not aware of any simple and general solution, It probably does depend on your exact situation (like every other engineering decision, which this one is). But... but your options include: 1) Testing on the development server (SDK) only. Check out the --datastore_path command line option. I think you should be able to create a copy of a dev datastore by copying the --datastore_path file (when no dev server is using it), but I haven't tried it. This is the easiest option, and, if you aren't too worried about being able to roll back changes, or possible data corruption... Just remember: what's deployed on production servers doesn't necessarily match what's on the SDK. 2) Using a separate app. Each app has its own datastore, inaccessible to other apps, so you'll have to migrate your data manually between this staging app and your stable app. This is the path I've taken, and it matches pretty well with the industry standard for enterprise web-sites (whatever that means). You can deploy your code to a server that will match your production environment. If it breaks, no real harm done. If it works, you can change the name (presumably you've already bumped the version) in app.yaml and redeploy pretty much instantly. Actually, this is one of the areas where GAE has a huge advantage over pretty much every other option. The downside, of course, is that you have to burn two apps instead of just one. 3) Emulating versioned datastore manually. You will still have a single shared datastore, but you can write your code so that it never touches other versions' data. Or it can only access some other version's data under very specific circumstances. Or whatever. How this is best done heavily depends on what kind of changes you are trying to introduce to the datastore. If you're doing a bunch of big, complicated, nasty sites, and you desperately need to keep their databases distinct for security reasons, this is the way to go. Personally, I suspect this is what the cloud version of enterprise software looks like. The down-side, of course, is that it's horribly complicated. As one possible compromise between 2) and 3), I'm going to suggest a [n] [honestly] horrendous hack which works for me. I don't know how well this will work for any other web framework. I worked this one out using web2py (about which I have extremely mixed feelings). You have one single GAE app. It dispatches to multiple applications based on the URL. The first directory in the URL defines the web site it dispatches to. The second determines which controller/view it will be using. The third decides which method/particular instance of the controller/view it uses. The rest specify positional parameters to pass to the controller. So: http://myapp.appspot.com/init/default/welcome would dispatch to the init site's default controller and call its welcome method. http://myapp.appspot.com/staging/default/welcome would dispatch the same thing to the staging site. Both sites share the same datastore, which makes this approach dangerous. Like I said, this is really a total trade-off/hack sort of thing. You can add hackery to your model names so one site fudges Model type-names, but that edges you into complication issues about keeping things straight. The plus side of this approach is that, when you're ready to really deploy, you can delete your existing init site, rename staging to init, and upload your changes. If you need to make emergency fixes that you're absolutely confident about, just update init. When you're ready to start toying with a new major (for some value of major release), make a copy of init named staging, merge in your changes (you *are* using source control, right?), rinse, and repeat. You could take this a step further and use the same Model versioning magic suggested in 3). Maybe that should be approach #5? I don't know how this approach would work under django. Every time I try to wrap my head around that I have an allergic reaction. I can't really endorse web2py (every time I dealt with it I just got frustrated because I felt like it was doing too much). But that could just be me. For anyone who's still on the fence, it's definitely worth checking out. Changes to your datastore schema can be risky. It is always good to have a full backup and test the restoration procedure periodically. That really can't be emphasized enough. No matter what environment you're in. Speaking of which, I think I'll back up my source code
[google-appengine] RE: AE 1.1.7 defines has_key on db.Model
Google Groups doesn't give me any option to directly reply to this post. We'll see how this approach works. When this error came up, I wrote a scathing flame. And then I threw it away, mainly because it just isn't productive. Overriding the has_key() method seems like one of the least advisable choices one can make in python. If Guido has signed off on it, then I'm not one to argue. If anyone else decided to do this, without Guido's explicit permission...I'm going to squawk, moan, and do funny walks to draw attention to a decision that seems incredibly...questionable, to me. Like I said, I threw away my original flame, mainly because it wasn't hurting me. Now I seem to be running into exactly the same problem, so I have to complain as well. I've opened a bug report, requested that this get refactored, and just followed the advice to copy google.appengine.ext.db.__init__.py to my own directory and am currently referencing it from there. As a software engineer, I *cringe* from that last part. That's google's documented API. It's written well enough that I feel fairly confident hacking around it...but there isn't much telling how well it maps to the production API (I'm guessing it's pretty close at present, but will change radically in the future...just the nature of the beast). Still, I thought I'd ping this thread to see if anyone else has an opinion. Regards, James -- Forwarded message -- From: Daniel O'Brien (Google) d...@google.com Date: Dec 1 2008, 5:17 pm Subject: AE 1.1.7 defines has_key on db.Model To: Google App Engine It's worth filing this as a feature request (or defect) in the public issue tracker, if you haven't already:http://code.google.com/p/ googleappengine/issues/list As far as I know this method has existed since 1.1.6: Some developers ran into issues involving cheetah, which assumes that anyhas_key method behaves like that of a dict which, as you've noted, the one nodb.Modeldoesn't. Daniel On Dec 1, 1:54 pm, Ken Tidwell google...@gamecabinet.com wrote: Apparently, some bright spark has defined ahas_keymethod ondb.Model. Doing so will preclude the creation of any Model derived from or emulating dictionary classes (such as UserDict or DictMixin). Thehas_keymethod in question does not follow the same semantics as has_keyon dict so the choice of name is unfortunate, to say the least. Any chance the method could be renamed to something less toxic and more suggestive of its actual function (such as key_complete)? ken --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Serving static files
That did the trick. Thank you [both] On Jan 26, 2:50 am, Blixt andreasbl...@gmail.com wrote: Looks to me like there's three spaces in front of static_dir: static. Try removing one of the spaces so that there are only two. Regards, Andreas On Jan 26, 5:41 am, James Ashley james.ash...@gmail.com wrote: I feel like a complete idiot. Here's my app.yaml: application: whatever version: 1 runtime: python api_version: 1 handlers: - url: /static static_dir: static When I try to run dev_appserver, I get this exception/stack trace: $ python ./dev_appserver.py -d ../pyjamas/ ERROR 2009-01-26 04:15:15,236 dev_appserver_main.py] Fatal error when loading application configuration: mapping values are not allowed here in ../pyjamas/app.yaml, line 8, column 14 I've compared it with app.yaml's from various working projects, and I just don't see the difference. What am I doing that's bone-headed here? Thanks, James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Ok I know it's something really dumb but how to upload
Those are all fine options. But the real answer is to write 2 or 3 .BAT files (start your server, upload, and *save to source control* -- that's the most important one) and install the Windows Command Prompt Here extension. :-/ Good luck, James On Jan 19, 6:10 pm, djidjadji djidja...@gmail.com wrote: You can copy and paste by using the System menu of the window. You can open this menu by using Alt-Space or click on the top left icon in the titlebar (for a cmd window it is a small c:\) In this menu you find a submenu for clipboard operations. If you want to copy text to the clipboard you first have to Mark the text and then press enter. 2009/1/19 dartdog dartd...@gmail.com: Just this typing will be a real drag since the conventional Cntrl C and Ctrl V don't work in cmd shell.. Back to the books, but then I suppose the real solution it to pack the whole thing in a bat file!! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Can not delete entity using Data Viewer and a GQL query.
This sounds to me like something that should be reported as a bug. And whoever wrote that error message should be punished with at least 10 papercuts. But that's just me. G On Jan 11, 3:33 pm, murexconsult...@googlemail.com robin_ow...@hedge-row.co.uk wrote: There was a bug in my app and some bad data got into the Datastore. So I want to delete some data. The models have a number of items so rather than paging through them all 20 at a time to find it I ran the GQL query: SELECT * FROM UserUpdates WHERE windAngle=328 This returns one row as expected. I then click on the tickbox beside it and click on Delete. I then get a dialog box asking if I am sure to which I say yes. I then get the error displayed in a red box at the top saying The URL to forward to once the request is fulfilled - Yes the error is a partial sentence and makes no sense. The item is NOT deleted. This is happening to all 4 of my models. However 2 of them only have a few hundred entries, so I was able to page through, find the item and delete it. When I paged through, the deleting was successful. I think that there must be a bug in the data viewer when removing data found using a gql query. Thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: why the computer says NameError: name 'execfile' is not defined
Isn't production running 2.5.ish? On Jan 12, 8:39 pm, bijiasuo2...@gmail.com bijiasuo2...@gmail.com wrote: you should install Python 2.6.1 i have successful, but i don't know why. I don't know Python --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: OpenID, is it good?
On Jan 12, 9:06 pm, jay j...@jaykyburz.com wrote: I thought google was participating in Open ID now? Do our app engine logins support OpenID's? OpenID still seems...fairly immature and not user friendly. Then again, it's been a while since I tried to use it. I probably have the terminology wrong. Last I checked, google was an Open ID provider. If you try to log into a site that accepts Open ID logins, you should be able to use your google account. Or your facebook, myspace, yahoo, etc, etc account. The trouble is finding sites that accept Open ID logins from other providers. No idea why that is, unless it's just the pain of re-writing their user handling code. Well, that and figuring out a graceful way for the user to actually log in. I still haven't ever been able to figure it out, on the few sites I've seen. (Which, I think, is a crying shame. Then again, other people are terrified by the idea that leaking one single login could totally destroy their online identity) On Jan 10, 11:16 am, Mengsong Chen ltcst...@gmail.com wrote: I have just read something about OpenID. It seems a good solution, in particularly for mobile web apps. I wonder what is the general feedback for it? How is it compare it Google Login? Thanks, M --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Model.put() Override?
The simple answer seems to be override the db class. That's totally off the top of my head, and it may be completely unrealistic. Something like (totally untested and almost definitely wrong. Consider it pseudo-code): class my_db(google.ext.db): def put(self, *objects, **kwargs): for o in objects: o.pre_put() super(google.ext.db, self).put(*objects, **kwargs) Then the models that were overriding put() could put that override code in pre_put() instead (and change put() to just call that before calling super().put()...). You'd have to juggle the nuances of things like post_put(), and any side-effects. But it seems like a reasonable compromise. On Jan 14, 2:22 pm, boson dan.kam...@gmail.com wrote: That is a curious situation. I would like to know also if there is a way to inject code into the put-stream regardless of method called, as I have various put() overrides as well. On Jan 13, 9:45 pm, Devel63 danstic...@gmail.com wrote: I overrode the put method on a class derived from Model, primarily because I wanted to do some accounting work when a new object was saved (in the simplest case, just keeping track of a counter). It does its work, then calls super. It works fine. Until I use db.put([ob1,obj2,obj3]) to save a bunch of these, and then of course the individual object.put() functions are never called. Is there a best practice for this? I really liked having it in the put, because then no caller needed to know about it, and it just took care of itself. Is the best thing to precede every put call with an explicit put_prep call? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: typical scenario
http://groups.google.com/group/google-appengine/browse_thread/thread/2baa48709bb94bd3?hl=en has an excellent answer about dispatching to multiple WSGI apps. On Jan 17, 12:11 pm, James Ashley james.ash...@gmail.com wrote: I really don't know much about WSGI, but this works for me. As I understand it, you should probably have 1 WSGI app in the root folder. It will do whatever's appropriate to load whichever sub-app needs to run. Then they should both be able to import from the DB folder. i.e. / -- app.yaml | main.py + app_one | __init__.py | whatever.py + app_two | __init__.py | whatever.py + DB | __init__.py | model_one.py | model_two.py | model_three.py Set up app.yaml to dispatch requests to main.py (or whatever you want to call it). Have it examine REQUEST and dispatch into app_one or app_two as needed (`import app_one.whatever`). Then files in app_one or app_two should be able to `import DB.model_one` If it's anything more than a dead-simple app, I'd break it down further than that. But that's the idea I'm using. On Jan 14, 8:29 am, arnie parvez...@rediffmail.com wrote: I am stuck in a very big problem and could not find any solution for this Writing import DB in the BusinessList folder's businesslist.py file does not work. I have also added __init__.py file [empty] in the DB folder but of no use. Also I have created PYTHONPATH environment variable and gives it the path C:/ but it seems to me that this setting is not working too. I have to upload this folder structure to GAE under one AppID Can anybody suggest a solution? Thanks --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Data Privacy
On Jan 17, 11:17 am, hawkett hawk...@gmail.com wrote: Hi Marzai, Thanks for the detailed response. It would be great to get those clarifications included in the terms of service and/or privacy policy. I can see from my post rating that some people don't share my concern, but data privacy is probably the number one barrier to commercial cloud adoption at the moment. To whomever marked the OP down: he's right. This *is* an incredibly important consideration. However... Clear legal statements BWAHAHAHA! It all depends on the meaning of the word is. Sorry, I couldn't resist. :-) are always better than implied trust, or clarifications made in forums. I don't doubt that the constraints you have outlined are correct, but I read the privacy policy and terms of service to say something significantly different. The privacy policy explicitly lists content (including code) Actually, see section 5.1: * The term Content shall specifically exclude the web application that * you create using the Service and any source code written by you to * be used with the Service (collectively, the Application). and says this - 'We use this information internally to deliver the best possible service to you, A lawyer probably *could* stretch this to include making your private customer data public such as improving the Google App Engine user interface and maintaining a consistent and reliable user experience.' Lots of disagreement among lawyer types about phrases like such as. Be careful of those. The terms of service say this (in section 8, which overrides any rights outlined in section 6) - 'By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content Note the term Content here. *Not* Application. Nothing about your source code. for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.' IANAL, but that whole sole purpose thing seems to actually make this safer for us developers. Then again, lawyers have completely up-ended those silly Congress shall not... clauses in the Bill of Rights, so they could probably use this to justify publicizing your medical records. :-/ When you put these two statements together, Google is able to reproduce, adapt and modify developer contributed code Again, IANAL. But can you take individual pieces of an agreement like this out of context? to improve your UI, and explicitly *does not* require content Just to re-emphasize (yet again, from the Department of Redundancy Department): content seems [to me] to specifically be the user data. *Not* the source code. owner's permission. Apparently that permission is given once the data is uploaded. I'm not trying to be difficult - that is actually what it says - and those documents are actually what business look at when making decisions. And the details are extremely important. Especially when you have to break down and actually talk to the suits. I realise that the terms of service and privacy policy are produced by the legal team and not the engineering team, and the legal guys have a responsibility to protect Google from liability and litigation. Perhaps the legal team isn't fully aware of the importance of data security to GAE adoption. I suspect you aren't giving enough credit to the legal team. It's their job to keep google from getting sued. When google does get sued (which it will), it's their job to ensure that google wins. This must balance against the marketing team's job to actually get people/developers/us to use the product. It is probably the engineering team's responsibility to raise that awareness. You could be right. In almost any other company, I'd agree with you. I'm willing to bet that google's lawyers are at least hip-deep when it comes to privacy concerns. As I understand it, google's business model is to analyze data and use that analysis to make a profit. This seems to be mostly through selling ads. I'm sure there are other forms of revenue (like the people who pay for premium service, enterprise search, etc). If you store data on GAE, you should expect google to be crawling it and making every penny they can out of it. The biggest risk (that I can see) might be google focusing ads from your competitors on your users. A secondary risk seems to be google actually analyzing your data and making it (and the analysis) public. I don't think the TOS allows that, but (yet again) IANAL. It could all happen to deliver the best possible service to you. But I doubt it's the engineering team's responsibility. Maybe someone on that team should (I hate that word) step up to the plate and make sure the legal team appreciates your/our concerns, but you'd really be better off having your lawyers talk to their
[google-appengine] Re: Data Privacy
On Jan 17, 2:54 pm, Andy Freeman ana...@earthlink.net wrote: data privacy is probably the number one barrier to commercial cloud adoption at the moment. Some supporting evidence would be nice because only one person is raising this concern. Maybe it's so huge a barrier that no one else is bothering, maybe the discussion is somewhere else, but I see this concern all the time. From every business-oriented point of view. I'm surprised that anyone else doubts this. I thought it could pretty much be considered a given. Businesses frequently consider data one of their most valuable assets. And they're reluctant to trust it with anyone else. When you put these two statements together, Google is able to reproduce, adapt and modify developer contributed code to improve your UI, and explicitly *does not* require content owner's permission. Actually, there's nothing about the UI. That's in there. Maybe it's a recent addition? However, there's something important missing from this discussion, namely for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy. Have I mentioned before that I really like that whole sole purpose phrase? I think I have. How about some acceptable wording from a service that provides computation and storage resources, together with a link to the whole policy? Ooh, nice question! I 3 nearlyfreespeech.net (I'm completely unaffiliated...the guy who owns it probably hates me). But even they don't have anything as explicit as google's. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: return a variable value from html form to python
I'm not real clear where the various errors are happening, so I'm just
guessing.
Just based on what I'm seeing here, it looks like you're having
javascript (client-side) issues. Something about DTC? Maybe it's a
variable that isn't getting initialized? Or maybe a constant that
needs quotes around it?
Just a guess, and I'm probably totally wrong.
Good luck,
James
On Jan 4, 6:10 am, thebrianschott schott.br...@gmail.com wrote:
Niklas,
Thanks for the idea, but I get the same behavior with that change.
I have even more information that I did not notice
before. When the following line is in process(form) an error
message is thrown in the Firefox error console that reports
the error message below. So somehow the POST and the
self.redirect(/?place=%s % g_place) are not behaving
right together.
form.place.value = String({{place|addslashes}});
Error: DTC is not defined
Source File:http://localhost:8082/?place=DTCLine: 108
Line 108 is the following one.
form.place.value = String({{place|addslashes}});
On Jan 4, 6:27 am, niklasr nikla...@gmail.com wrote:
Hey Brian,
Maybe it's as easy as
g_place = self.request.POST.get('place')
instead of
g_place = self.request.get('place')
Cheers
Niklas Stockholm
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[google-appengine] Re: Datastore Size Scaling
On Jan 4, 6:04 pm, djidjadji djidja...@gmail.com wrote: I have done a few tests and found that the number of items in the datastore does not influence the number of mega-cycles it takes to fetch, create, delete items. That's good to know, thank you. I'll never forget the time I handed a test version to our testers, and I carefully explained that paging didn't work. So, if they tried to look up anything more than about 50,000 records, everything would blow up. They cheerfully agreed, ran a query to look up 2,000,000 records, and screamed bloody murder when (as I predicted), it didn't work. I will not bitch about...any of the rest of it. I will *not* bitch about it. I...where was I? G Oh, yeah. Do you have any solid numbersyou're willing to publish from your tests? Better yet, do you have any statement from google? Just curious, James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Global Time Synchronisation Guarantees
On Jan 1, 12:17 pm, Andy Freeman ana...@earthlink.net wrote: For a number of possible reasons (including the consistency of a running balance), an accounts engine might have a basic specification requirement that invoices are generated in sequence with ascending invoice numbers *and* ascending invoice time/date. Except that consistency doesn't require both. Either one is sufficient and trying to have both merely puts you in the situation of a person with two clocks - you don't know which one is correct. Moreover, it's easy enough to fake an ascending time/date. (Take the max of the system time and epsilon past the most recent entry.) If time is actually an issue, you can't use system time unless it's guaranteed to be accurate, not just consistent. For that, you're probably better off consulting an accurate time source. This was pretty much exactly my thought. Put your own central server on the web and use urlfetch() to get timestamp/invoice numbers. -- James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Announcing: System Status Dashboard, Quota Details Page, and a Preview of Billing
Just for clarification: There seems, to me, to be a big distinction between support for large files (to me, that sounds like serving bigger files that I upload via appcfg) and supporting large files uploaded by end-users (which, to me, implies letting the web app store data in bigger BLOBs). It seems perfectly workable (if a nasty bit of coding) to treat the database BLOBs as a virtual file system, breaking a file into multiple chunks and streaming them back one at a time. But actually uploading such a thing means getting over the 1 MB request limit. Is that part of the plan? Thanks yet again, James On Dec 17, 11:47 am, Marzia Niccolai ma...@google.com wrote: Hi Brian, These two features (billing and large file uploads) are being worked on concurrently but their release dates are not tied together. They both are on the roadmap for Q1, and are still on track for that time. We haven't yet determined the maximum size for large files. -Marzia On Wed, Dec 17, 2008 at 4:40 AM, BrianJinwright br...@ifeets.com wrote: I agree it is possible in s3 just set the ACL of that bucket or object. I think yu Ping's question is a good one. When billing is opened up will can we store files larger than 1MB. If so, how large. Thanks, Brian Jinwright --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: How can we develop apps using SVN?
Check out assembla.com. It has both source control hosting (give mercurial a try...it's a lot more flexible than SVN, the the GUI options still have their quirks) and project management features (which is what it sounds like you want). (Note: I'm not affiliated with them at all. Just a happy customer). On Dec 14, 9:27 am, Stella stella.kovalc...@gmail.com wrote: How can I share App-Engine project through SVN? Is there a way to divide designer's and programmer's task? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] import semantics (was Re: handling classes across multiple .py files)
import models vs. from models import *: There might be some low-level nuance differences, but the important one (to me) is your module's name space. If you do from blah import * you wind up with everything in the other module. This *may* be what you want, but it usually isn't. If there's something in that module with the same name as the one doing the importing, it can lead to bugs that are really hard to track down. You also throw away any clues about where something's defined. More and more, I find myself doing things like import modules.MyCompany.StringUtilities.foo as foo because it's a lot easier to write foo.whatever than specifying the entire namespace, but I'm still using names that are distinctive enough that I don't have to worry about where something came from. (You can do that by adding directories modules/MyCompany/ StringUtilities and then a module named foo.py. Put a file named __init.py__ in each directory in the tree. I know you can do cool things with that file...probably to specify actions that happen before any modules in that directory or subdirectories get loaded, but I've never really cared enough to look into it). AFAICT, it's just a matter of style and preference (and how much effort is some given thing worth). But it's been my experience that from blah import * is just begging for trouble. (from blah import specific is much better). Regards, James On Dec 11, 6:38 pm, djidjadji djidja...@gmail.com wrote: For point 1) Place the model class definitions in 1 or more separate .py files You can put more then 1 model class in a .py file when you use the multiple file approach eq. models.py # all model classes in one file or user.py forum.py comment.py And use import statements like from models import * or from user import * from comment import * in the model files that need other model definitions and in the .py files that handle the requests (the ones named in the app.yaml file) Some people use import models and they have to use customer = models.User(..) instead of customer = User(..) At Python interpreter level it must have a different result, but I have no problem using the from import * method --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Isolated Application Deployment Instances
Maybe I'm missing something. But it doesn't seem like it would take
much effort to write a script to automate it.
Something along the lines of:
instance_names = ('a', 'b', 'c',...)
for name in instance_names:
# change the instance name in app.yaml
# call appcfg.py
You'd probably want to keep the instance names in a database, to
associate with billing, etc, but that could be something for later
down the road.
On Dec 10, 5:25 am, rvjcallanan [EMAIL PROTECTED] wrote:
I am new to GAE (who isn't?) and this subject has been touched on
before in a number of guises but I think we could all benefit from a
little more clarity.
I am developing a proof-of-concept business app which can benefit
hugely from the GAE framework. My ideal scenario is to deploy the app
to each customer as a separate isolated instance, integrated within
his managed Google Apps business account.
The main reasons for this preference are:
1. I would like to keep customer data and bugs isolated
2. Each customer is an island as far as the application data model is
concerned. One big database would require all tables and queries to be
qualified by a customer ID, adding an unnecessary layer of complexity
and impacting performance.
3. I would like each customer to take individual responsibility for
hosting costs
4. I wish to leverage the Google Apps for managing user accounts
within each organisation.
5. I wish to expose my own API to allow for customisation.
Bear in mind that each app instance may have to support a few thousand
users at most (but probably not millions).
Right now, deploying individual app instances in the way described
above is kludgy at best. While it may be feasible to do this manually
for a small number of high-value customers, it is certainly not a
scalable solution. There is also the issue of protecting intellectual
property.
I am wondering if there is anything in the unofficial roadmap to
address this requirement in the future. I would like to start
developing now on the basis that deployment of individual app
instances (and updates) will eventually be a single-click operation.
Is this wishful thinking?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: suddenly, a new error in Cheetah in production GAE, doesn't occur in SDK
Marzia, I don't want to seem disagreeable, unappreciative, or anything like that. But I really have to agree with Ben on this one. It seems to me that this change introduces a bug. I've been using python for 8 years now, and I can't think of any reason for a has_key method to take only one argument (its parameter list is always (self, key_name)). That's a fairly core part of the language. If you're going to introduce a new method that does something vaguely similar, but changes things significantly like this, IMHO, you should really give it a different name. Then again, you do have Guido on hand, and his whim certainly trumps anything anyone else might say. Maybe he's already vetted this decision, and I need to just shut up and mind my own business. Thank you for the help and support you're providing, James On Nov 17, 6:10 pm, Marzia Niccolai [EMAIL PROTECTED] wrote: Hi Ben, It's certainly not our desire to introduce any changes in the App Engine library that would break our users app, but from time to time some parts of the apis and libraries will be modified to fix issues/enhance features. When these fixes happen, it's always possible that this will break a certain subset of applications who are implicitly or incorrectly assuming certain features of the API. Of course, we'd like to avoid this when possible, but sometimes it's difficult to anticipate how some of these changes can affect certain applications. We are certainly working on finding the right balance, and hope that as we continue development with App Engine these kind of things will happen less often. -Marzia --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
