0

I'm having some trouble understanding and implementing the Google Directory API's users watch function and push notification system (https://developers.google.com/admin-sdk/reports/v1/guides/push#creating-notification-channels) in my Python GAE app. What I'm trying to achieve is that any user (admin) who uses my app would be able to watch user changes within his own domain.

I've verified the domain I want to use for notifications and implemented the watch request as follows:

directoryauthdecorator = OAuth2Decorator(
approval_prompt='force',
client_id='my_client_id',
client_secret='my_client_secret',
callback_path='/oauth2callback',
scope=['https://www.googleapis.com/auth/admin.directory.user'])

class PushNotifications(webapp.RequestHandler):
      @directoryauthdecorator.oauth_required
      def get(self):
          auth_http = directoryauthdecorator.http()
          service = build("admin", "directory_v1", http=auth_http)

          uu_id=str(uuid.uuid4())
          param={}
          param['customer']='my_customer'
          param['event']='add'
          param['body']={'type':'web_hook','id':uu_id,'address':'https://my-domain.com/pushNotifications'}
          watchUsers = service.users().watch(**param).execute()

application = webapp.WSGIApplication(
                         [
                          ('/pushNotifications',PushNotifications),
                          (directoryauthdecorator.callback_path, directoryauthdecorator.callback_handler())],
                         debug=True)

Now, the receiving part is what I don't understand. When I add a user on my domain and check the app's request logs I see some activity, but there's no usable data. How should I approach this part?

Any help would be appreciated. Thanks.

rok
  • 557
  • 4
  • 20

2 Answers2

0

The problem

It seems like there's been some confusion in implementing the handler. Your handler actually sets up the notifications channel by sending a POST request to the Reports API endpoint. As the docs say:

To set up a notification channel for messages about changes to a particular resource, send a POST request to the watch method for the resource.

source

You should only need to send this request one time to set up the channel, and the "address" parameter should be the URL on your app that will receive the notifications.

Also, it's not clear what is happening with the following code:

param={}
param['customer']='my_customer'
param['event']='add'

Are you just breaking the code in order to post it here? Or is it actually written that way in the file? You should actually preserve, as much as possible, the code that your app is running so that we can reason about it.

The solution

It seems from the docs you linked - in the "Receiving Notifications" section, that you should have code inside the "address" specified to receive notifications that will inspect the POST request body and headers on the notification push request, and then do something with that data (like store it in BigQuery or send an email to the admin, etc.)

Nick
  • 3,581
  • 1
  • 14
  • 36
  • Think you misunderstood my initial post. I know that my code sets up the notifications channel. The setup seems to be successful. I'm having trouble interpreting data after that. The application's logs show that something happens each time I change stuff (add a new user) on my test domain, but I don't seem to get any relevant data back and even though I 'listen' for POST requests in my app as well, I never get anything back. – rok Feb 16 '17 at 14:12
  • It doesn't seem odd that you're re-establishing the notification channel each time you receive a POST request? Or that you don't inspect the request body for any data? – Nick Feb 16 '17 at 19:58
0

Managed to figure it out. In the App Engine logs I noticed that each time I make a change, which is being 'watched', on my domain I get a POST request from Google's API, but with a 302 code. I discovered that this was due to the fact I had login: required configured in my app.yaml for the script, which was handling the requests and the POST request was being redirected to the login page, instead of the processing script.

rok
  • 557
  • 4
  • 20