I’m trying to make a request against a Google REST API to get a list of all the Google Classroom courses. The code I’ve got is below (in the form’s init function):
email_addr = google.auth.login(["https://www.googleapis.com/auth/classroom.courses"])
print "User logged in as %s" % email_addr
access_token = google.auth.get_access_token()
headers = {'Authorization': 'Bearer' + access_token}
courses = anvil.http.request(
"https://classroom.googleapis.com/v1/courses",
json=True, headers=headers)
print courses
and I’ve set up the OAuth client ID in the API console, copied the client ID and secret into the Google API section (under Access your users’ Google Drive Files - is this the right spot? If so, perhaps it should be renamed for the case where you’re trying to access any old API?), and enabled the APIs in the Google API console.
I get the following error message on the line which calls get_access_token():
AttributeError: '<invalid type>' object has no attribute 'get_access_token'
at Form1, line 14
OK; I’ve found one problem; the docs say to use get_access_token() while autocomplete shows the method to be get_user_access_token() - the docs are out of date.
1 Like
Another problem with the docs: the headers example given is incorrect - it needs a space between ‘Bearer’ and the access token, so should read:
headers = {'Authorization': 'Bearer ' + access_token}
Thank you for this bug report! I’ve fixed both typos in the docs; you’ll see this on the public site in the next day or so.
Is the API otherwise working OK for you?
1 Like
Thanks.
Mostly working fine, however I’ve hit one relatively big problem, but I’m unsure whose jurisdiction the problem lies in. Our school uses a transparent proxy with a SSL MITM cert (so the school can restrict and spy on what users are doing). This is not uncommon for schools (and some businesses in fact). This is causing a problem with the Google API call. If I run the app on a non-school network, it works fine, but fails when using the school’s MITM’ed network. The Google Login shows up and seems to succeed, but when trying to get the access token I get a Exception: Connection to server failed
. I haven’t sniffed the traffic to work out where the issue is at.
Seperately, a minor niggle is the fact that the oauth client id and secret need to be entered in the ‘Access your users’ Google Drive files’ even though I’m not accessing the Google Drive files. Perhaps renaming this section (Access your users’s Google Drive files and other API access?) would make it less confusing for others.
Looking at the network traffic in Chrome’s Dev tools, it seems that a lot (perhaps all?) websocket calls are failing over the MITM network. I don’t really know what they’re for in this context, but that’s the main difference between the MITM network and a ‘normal’ one.
The app I’m building is all client-side (i.e. I haven’t made any server components). Is there still some server-end stuff that goes on regardless? Is there any server-based stuff that interacts with Google Auth/API calls?
Yes, all server calls (including the back-end to the Google service, which can be used from client or server code) go via a secure WebSocket connection. If your MITM-box is blocking those, you’re going to have a bad time!
I’m not sure what logic your proxy box is using to decide what to block; I’m afraid I can’t offer any advice more specific than “talk to your network administrator”!
Thanks; I have talked to our network admin, and indeed he says there are sometimes problems with websockets. He has advised that whitelisting the particular hosts fixes the problem - is there a list or a pattern of hosts that accept websockets in anvil?
Cheers,
Every Anvil app is served from its own hostname, for security reasons (this gives them separate “origins” so one app can’t mess with another in your browser).
By default, all Anvil apps are served from <something>.anvilapp.net
, so if you whitelist *.anvilapp.net
you’ll get most of them. (If you give your app a custom domain like app.mydomain.com
, of course, you’ll need to whitelist that separately.)
1 Like
Thanks; using the Chrome inspector, it seems that there are also a heap of calls to *.api.drift.com
That’s just for the live chat in the IDE. Nothing bad will happen if you block them, just that the live chat will stop working.
IT have finally whitelisted the specified domains, and it works now. Thanks for your help!
1 Like
Found another problem with the docs: get_refresh_token() is not get_user_refresh_token() but the docs still show the old one
Nice catch! Fixed; will go out shortly. (Generally speaking, in these situations, if it’s the docs vs the autocompleter, the autocompleter is correct, and you should tell us that the docs are wrong, exactly as you just did
)