search

straight55b / app-engine-patch

Automatically exported from code.google.com/p/app-engine-patch
0 stars 0 forks source link

Error running manage.py update in repository version #153

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Download repository version of appenginepatch
2. Change app id to something relavent
3. run python managy.py update

What is the expected output? What do you see instead?

update gets to the Running syncdb step and then dies with
urllib2.HTTPError: HTTP Error 302: Found

(I've pasted the traceback at the bottom of this issue report)

I can get the same error by using python manage.py shell --remote and then
typing
>>> from myapp import models
>>> person = models.Person(first_name='Andrew', last_name='Smith')
>>> person.put()

Whether this is a 302 response that appengine is failing to handle (in
which case I'm reporting this issue in the wrong place!) or it's
appenginepatch failing to handle the 302 I don't know.

Traceback from python manage.py update...

Traceback (most recent call last):
  File "manage.py", line 18, in <module>
    execute_manager(settings)
  File "/Users/Andrew/Documents/code/appenginepatch-sample/__init__.py",
line 370, in execute_manager

  File "/Users/Andrew/Documents/code/appenginepatch-sample/__init__.py",
line 315, in execute

  File
"/Users/Andrew/Documents/code/appenginepatch-sample/common/zip-packages/django-1
.1.zip/django/core/management/commands/update.py",
line 65, in run_from_argv
  File
"/Users/Andrew/Documents/code/appenginepatch-sample/common/zip-packages/django-1
.1.zip/django/core/management/commands/update.py",
line 48, in run_appcfg
  File "/Users/Andrew/Documents/code/appenginepatch-sample/__init__.py",
line 178, in call_command

  File
"/Users/Andrew/Documents/code/appenginepatch-sample/common/zip-packages/django-1
.1.zip/django/core/management/base.py",
line 227, in execute
  File
"/Users/Andrew/Documents/code/appenginepatch-sample/common/zip-packages/django-1
.1.zip/django/core/management/base.py",
line 356, in handle
  File
"/Users/Andrew/Documents/code/appenginepatch-sample/common/zip-packages/django-1
.1.zip/django/core/management/commands/syncdb.py",
line 66, in handle_noargs
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/ext/db/__init_
_.py",
line 1400, in count
    return self._get_query().Count(limit=limit)
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/api/datastore.
py",
line 984, in Count
    self._ToPb(limit=limit), resp)
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/api/apiproxy_s
tub_map.py",
line 68, in MakeSyncCall
    apiproxy.MakeSyncCall(service, call, request, response)
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/api/apiproxy_s
tub_map.py",
line 240, in MakeSyncCall
    stub.MakeSyncCall(service, call, request, response)
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/ext/remote_api
/remote_api_stub.py",
line 184, in MakeSyncCall
    response)
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/ext/remote_api
/remote_api_stub.py",
line 147, in MakeSyncCall
    request_pb.Encode()))
  File
"/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-de
fault.bundle/Contents/Resources/google_appengine/google/appengine/tools/appengin
e_rpc.py",
line 344, in Send
    f = self.opener.open(req)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.
py",
line 380, in open
    response = meth(req, response)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.
py",
line 491, in http_response
    'http', request, response, code, msg, hdrs)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.
py",
line 418, in error
    return self._call_chain(*args)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.
py",
line 353, in _call_chain
    result = func(*args)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.
py",
line 499, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 302: Found

Original issue reported on code.google.com by idrinkto...@gmail.com on 5 Jun 2009 at 1:07

GoogleCodeExporter commented 9 years ago 
Works over here, so I'd say this must be an App Engine bug for one of your 
appids.

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 1:31

GoogleCodeExporter commented 9 years ago 
What so that's it? *your* version works on *your* operating system and *your*
computer so therefore there is no bug?

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 1:47

GoogleCodeExporter commented 9 years ago 
OK, could you please try to use remoteapi with some other appid, some other OS, 
and
then, please also try to do the same with the beta1 version on our website, so 
you
can really nail down that the problem exists on all appids and on which 
platforms and
with which AEP versions? That would really save me a ton of work.

What you probably can't know is that the whole remoteapi communication is done 
via
Google's SDK while app-engine-patch merely calls a simple function to activate
remoteapi. Since your traceback indicates that it's a simple HTTP communication 
error
it's very very unlikely that the problem is anywhere in app-engine-patch. I 
think
it's either a problem with urllib on your platform or it's a temporary issue on
Google's servers (we had a few such "temporary" bug reports here, already).

Also, please bear with me that I can't really invest hours into tracking down
everyone's bugs. I'm alone and I earn no money with this and at least 50% of all
issues here are not related to AEP, at all, and some people even post issues 
asking
for help with bugs in *their* own code (as if this were a public help-desk 
system).
This is quite a lot of work for a single person, so I really have to prioritize 
my time.

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 2:45

GoogleCodeExporter commented 9 years ago 
Hello. 

Actually I am aware that the remote_api was part of google's sdk. The reason I'm
using the repository version is that I understand from the wiki that the 
--remote
option is only available in that version and obviously I need all the
appenginepatch/django set up to run for me to be able to use the remote_api in 
any
meaningful way, though if it is present in the 1.1 beta from the site then I 
will
happily test on that version.

What I have established so far is that the errors appear to be associated in 
some way
with the use of google apps account. 

So far I have tested as follows 
(google = standard google account. google apps = google apps account)
FAIL = update fails
OK = update ok and remote shell ok

App Owned By    User Type   Result
google apps     google apps FAIL
google apps     google      FAIL
google          google      OK
google          google apps FAIL

I tried the tests for the google apps accounts with two entirely different 
domains
and got the same results so it's not just my apps account which is borked.

Next I'm going to test the remote_api against some non appengine-patch code 
with the
same accounts. If it falls over the same way then I guess we'll know the error 
lies
with google appengine and I will have, as I said before, posted this issue in 
the
wrong place!

The platform I am on is OS X by the way. If it turns out that this bug is
appengine-patch related then I have vm's I can use to test it on Linux and 
Windows
platforms too if needed.

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 3:02

GoogleCodeExporter commented 9 years ago 
Hello

Further to my last message, I have just tested the remote api using the code 
provided
in the google appengine remote api article from
http://code.google.com/appengine/articles/remote_api.html and a super simple non
appingine-patch application and I successfully used the remote api console to 
create
a datastore entity despite the fact that I uploaded this application under the 
same
appid and google apps account I was using when I reported the issue with 
manage.py
update.

It does appear therefore that the issue is in some way related to using a 
google apps
account *with* appengine-patch. (At least under OS X)

I'll test the same situation under windows and linux to make sure it isn't 
specific
to either os x or my environment but I won't get a chance to do that until 
tomorrow
at the earliest.

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 3:34

GoogleCodeExporter commented 9 years ago 
Did you specify a host when using the basic remoteapi console? In 
app-engine-patch
you can specify that in settings.py (at the bottom there is remote_host).

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 3:37

GoogleCodeExporter commented 9 years ago 
Hello

The basic remote api console defaults to using (my appid).appsopot.com, so 
there was
no need. I also double checked using the live dataviewer on 
appengine.google.com just
to be sure I hadn't done something dumb like just creating the datastore entity
locally ;)

For the tests I carried out against the appenginepatch-sample app from the
respository the only thing I changed was the appid.

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 3:59

GoogleCodeExporter commented 9 years ago 
My initialization code is almost exactly the same as mentioned in the article. 
The
only difference is that I activated the cookie store, so you don't have to 
enter the
password on each manage.py run. Anyway, I tested the console with an apps 
account and
it doesn't work. It always says "Invalid username or password." Only after three
failed login attempts it exists with your exception. Is that the same behavior 
as on
your machine?

On the App Engine discussion group, quite a few people mentioned problems with 
using
google apps accounts with App Engine. Google knows about it, but didn't mention 
when
they'll fix it.

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 4:29

GoogleCodeExporter commented 9 years ago 
Hello

No, I can log in just fine using an apps account. The issue is when I try to do
anything further, such as create a data store entity (and that is only with an
appengine-patch app.)

When you say you tested the console with an apps account what exactly do you 
mean?
(the basic console app or manage.py shell --remote)

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 4:40

GoogleCodeExporter commented 9 years ago 
I tested with both by accessing the datastore.

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 4:42

GoogleCodeExporter commented 9 years ago 
Hello

No, that isn't the same as on my machine. On my set up there is no issue 
logging in
and it fails immediately (i.e. as soon as I do something which acts on the 
datastore
such as a put()

Original comment by idrinkto...@gmail.com on 5 Jun 2009 at 5:04

GoogleCodeExporter commented 9 years ago 
Could you please try to delete your appcfg_cookies file? I don't know where it's
located on OSX.

Original comment by wkornew...@gmail.com on 5 Jun 2009 at 6:44

GoogleCodeExporter commented 9 years ago 
Hello

Yup, tried that. Had to work out how to do that before I could test all those
different users and accounts. (For future reference, on os x it is in your home
directory)

Looking at my schedule for next week and will probably not be able to test on 
other
Operating Systems till Tuesday unless the stuff I have to do on Monday (php. 
yuk.)
goes quickly.

Original comment by idrinkto...@gmail.com on 6 Jun 2009 at 6:33

GoogleCodeExporter commented 9 years ago 
Reopening, for now.

Original comment by wkornew...@gmail.com on 8 Jun 2009 at 8:43

GoogleCodeExporter commented 9 years ago 
Any progress on tracking this down?

Original comment by wkornew...@gmail.com on 11 Jun 2009 at 4:12

GoogleCodeExporter commented 9 years ago 
Hello

I haven't had a chance to test on other platforms yet. pretty snowed under at 
the
moment! Will get back to you as soon as I have though

Original comment by robotlov...@gmail.com on 12 Jun 2009 at 9:15

GoogleCodeExporter commented 9 years ago 
Does your traceback contain this:

Please go to
https://www.google.com/accounts/DisplayUnlockCaptcha
and verify you are a human.  Then try again.

Could you please try to go to that address and unlock your account?

Original comment by wkornew...@gmail.com on 16 Jun 2009 at 5:59

GoogleCodeExporter commented 9 years ago 
Hello, 

No, that isn't in my traceback. The account is not locked as far as I know. I 
ported my code to appengine_helper 
(I needed it to work now and I'm not using the admin interface any more) and I 
can use the remote api with the 
same accounts and appids with no issues

Original comment by robotlov...@gmail.com on 16 Jun 2009 at 6:41

GoogleCodeExporter commented 9 years ago 
Could you please try the attached django-1.1.zip (just copy it into common/zip-
packages, replacing your old django zip file)?

Original comment by wkornew...@gmail.com on 16 Jun 2009 at 7:05

Attachments:

GoogleCodeExporter commented 9 years ago 
I suppose you can't help me with this?

Original comment by wkornew...@gmail.com on 24 Jun 2009 at 5:25

GoogleCodeExporter commented 9 years ago 
Hello

Yes, I can help but as I already explained I am extremely busy right now. I do 
(finally) have some free time on my 
hands Friday and Monday so I will look into re-testing this issue and trying 
out the attached file.

Thanks

Andy

Original comment by robotlov...@gmail.com on 25 Jun 2009 at 10:43

GoogleCodeExporter commented 9 years ago 
OK, thanks, just wanted some feedback about the status of this ticket.

Original comment by wkornew...@gmail.com on 25 Jun 2009 at 11:47

GoogleCodeExporter commented 9 years ago 
Still too busy? It's really just a few minutes. Otherwise I have to remove this 
due to 
inactivity.

Original comment by wkornew...@gmail.com on 8 Jul 2009 at 1:57

GoogleCodeExporter commented 9 years ago 
Sorry, this fell off my radar a little since I ported to appengine_helper but I 
am happy to test it for you. To be 
honest I've rather forgotten *what* I'm supposed to be testing. 

You want me to test the appengine_patch 1.1 upload process but using the 
supplied .zip file?

Original comment by robotlov...@gmail.com on 8 Jul 2009 at 2:24

GoogleCodeExporter commented 9 years ago 
I wanted to know if remoteapi works for you with the django-1.1.zip in comment 
19. The 
problem was that your google apps accounts couldn't login via remoteapi.

Original comment by wkornew...@gmail.com on 8 Jul 2009 at 2:32

GoogleCodeExporter commented 9 years ago 
Hello

I have tested both the attached .zip against the 1.1 branch and the june 18th 
release of app-engine-patch-
1.0.2.1 release and both fail at the syncdb step (i.e. when using remote api) 
when using a google apps account.

Original comment by robotlov...@gmail.com on 9 Jul 2009 at 11:46

GoogleCodeExporter commented 9 years ago 
I really can't explain why the same login (I hope you really used the same 
login) 
should work with django-helper and fail with aep. The other zip contained 100% 
exactly 
the same remoteapi login code.

Original comment by wkornew...@gmail.com on 10 Jul 2009 at 4:37

GoogleCodeExporter commented 9 years ago 
I don't know either. For the test against the 1.0.2.1 release I simply 
downloaded the file, changed the app id and 
ran manage.py upload. As before, when using a google apps account the process 
fails at the syncdb step where 
it uses the remote API.

Are you no longer getting the same issue when using a google apps account for 
the app/authentication?

Original comment by robotlov...@gmail.com on 10 Jul 2009 at 9:39

GoogleCodeExporter commented 9 years ago 
I do get that issue, but it happens with absolutely all apps (aep, the 
console.py 
script you mentioned, django-helper, etc.). Also, Google already said that 
Google Apps 
accounts don't work and recently Alexander Vasiljev reported posted about this 
problem, 
too. Alexander found out that only one Google Apps account works: the domain 
admin. All 
others fail. What's strange is that you said you only get the problem with aep 
and 
after you switched to django-helper it went away. Could it be that you tested 
with 
different accounts (using the domain admin with django-helper and some other 
account 
with aep)? That could explain the disparity.

Original comment by wkornew...@gmail.com on 10 Jul 2009 at 9:51

GoogleCodeExporter commented 9 years ago 
Hello

I don't get the issue at all with django-helper or with the console app from 
the Remote API article. Aside from 
when I have used different accounts to test this issue I have used the same 
google apps account for all my 
GAE development. It is not the domain administrator either.

"Also, Google already said that Google Apps accounts don't work" Could you 
point me to where they have said 
this. I am planning to deploy a couple of applications into clients google apps 
accounts and that is a little 
worrying!

With the google apps account you are using to test this, has the GAE 
application been added to the google 
apps account via the dashboard?

Original comment by robotlov...@gmail.com on 11 Jul 2009 at 5:52

GoogleCodeExporter commented 9 years ago 
Hi,
yes, we added the account via the dashboard.

Also, please take a look at the reply from Nick Johnson in this thread (I think 
I 
also saw other discussions, but this is the only one I could find right now):
http://groups.google.com/group/google-
appengine/browse_thread/thread/b4d0fe4010561585/6881cc2f7bbc7c24

Did you also use the same appid when testing?

Is one of your appids configured to only accept Google Apps accounts?

Original comment by wkornew...@gmail.com on 13 Jul 2009 at 8:49

GoogleCodeExporter commented 9 years ago 
Hello

Firstly, thanks for the link to the comment thread.

In answer to your question, the appid I have been using for development of the 
project which was previously 
using appengine-patch was configured to use only google apps accounts and the 
admin user is a member of 
that google apps domain.

If you have a look at comment 4 and 5 I have also carried out testing with a 
non google apps appid which was 
configured to allow authentication from any google account.

I have to admit I'm pretty stumped. It seems strange that we are experiencing 
different behavior from the very 
similar tests. 

My one idea to help track down the issue is for me to create a very simple app 
which works under both 
appengine-helper and appengine-patch but which will (presumably) display the 
issues with remote api under 
appengine-patch.

I can then send this to you and you could compare with the results you get in 
your environment. 

Let me know what you think

Thanks

Andy

Original comment by robotlov...@gmail.com on 13 Jul 2009 at 1:42

GoogleCodeExporter commented 9 years ago 
Hey Andy,
independent of the tool I use, I always get the same results as in your comment 
4. It 
would be great if you could run those tests with exactly the same appid & user 
combinations on both aep and the helper. The test app just needs a very simple 
model 
which can be used via the remote shell - no need to write something fancy.

Thanks!

BTW, in the tests you might have to set the remote_host (see bottom of 
settings.py) 
if you use a custom domain.

Original comment by wkornew...@gmail.com on 13 Jul 2009 at 2:52

GoogleCodeExporter commented 9 years ago 
Hello

I created a test app as discussed and got a rather unexpected result as the 
appengine patch version worked!

Just to be clear, the account I tested this under was a google apps account. I 
uploaded with a google apps 
user from that domain (the appid creator) and (and I'm pretty sure this is 
critical) the app had been added to 
the google apps domain using the instructions found here --> 
http://www.google.com/support/a/bin/answer.py?hl=en&answer=91077

With previous versions of appengine patch this has not been the case, and you 
yourself are having problems 
with appengine patch and google apps domains so this really wasn't the result I 
was expecting at all!

Full Source Code is attached. You will need to set the appid.

The test application is called testapp and I tested the remote api as follows
./manage.py shell --remote
from testapp.models import TestModel
t = TestModel('I am from appengine patch')
t.put()

I then checked the appengine data viewer for my app and the model instance had 
been created.

Good news, but slightly confusing...

Original comment by robotlov...@gmail.com on 14 Jul 2009 at 3:25

Attachments:

GoogleCodeExporter commented 9 years ago 
OK, I don't have an appid set to a domain like you did, but I think I can now 
explain 
what the issue is when you try to access a page with required login ("login: 
admin" 
in the case of remote_api):

When you're not logged in you get redirected to the login page. Now, there are 
two 
cases:

When you bind your appid to an apps domain you get redirected to the 
/a/yourdomain.com version, so login works.

When you don't bind your appid to an apps domain you get redirected to the 
normal 
Google Accounts login page, but you'd have to get redirected to the 
/a/yourdomain.com 
version in order to use a Google Apps account.

This means that you always have to bind your appid (i.e., the login system) to 
a 
domain.

Since you've found a solution that works for you I can close this issue. Now, 
it 
would be really cool to welcome you back as an app-engine-patch user. ;)

Original comment by wkornew...@gmail.com on 14 Jul 2009 at 4:21

GoogleCodeExporter commented 9 years ago 
BTW, your code doesn't work for my appids (which all aren't setup like in your 
test).

Original comment by wkornew...@gmail.com on 14 Jul 2009 at 4:21

GoogleCodeExporter commented 9 years ago 
Hello. Yes, that makes sense.

Too late to port the current app back to appengine patch but I shall certainly 
look at using it for the next one I 
do.

Thanks

Andy

Original comment by robotlov...@gmail.com on 14 Jul 2009 at 5:04