Oauth 2.0 handler functions for Tornado

There are a few small improvements I can see:

1. Your get_current_user() function is slightly misleading. Currently, you return None if there is no current user, or True if there is. This function isn't returning the current user, its returning if there is a current user.

   If I assume the return value of get_secure_cookie() is a basic string, the method can actually be reduced to this single line:

   # On a valid return, the return value will be a non-empty string == True.
   # Otherwise, it will either be None or '', both of which == False.
   return self.get_secure_cookie('trakr')
   

   Since, this function is just passes through of the return value of another function, it really isn't necessary. Unless you wanted to keep it to describe what the return value of self.get_secure_cookie() could mean, I would suggest removing it entirely.

2. In your get() functions you have this if structure:

   if get_current_user():
       self.redirect('/product')
       return
   

   followed by:

   if self.get_argument('code', None):
       ...
   elif self.get_secure_cookie('trackr'):
       self.redirect('/products')
       return
   

   First you check for a current user; if there is none you continue on. Then, if you get a False return value from self.get_argument('code', None), you immediately check again. From what I can tell from your snippet, unless you expect a user to get logged in during the time it takes to evaluate two if statements, the second user check is redundant.

3. I would change your naming conventions a bit. The G and F at the beginnings of your classes can be understood when looking at the source code. However, away from the source the F and G can be ambiguous.

   I would recommend using the names: FacebookLoginHandler and GoogleLoginHandler.

   Also, instead of trackr I would use the full work tracker. Saving 1 character isn't worth it.

4. I would use str.format() instead of string concatenation. You only do this once and with only two strings. However, string formatting is more Pythonic and it, personally, describes better what the final string will look like:

   'Hello' + ' ' + 'world' + '!'   vs.   '{} {}!'.format('Hello', 'world')
   

5. My final point is more personal preference than a sure-fire Python convention. Whenever you have to split up a single statement onto multiple lines, you indent the next line 4 spaces in. As alluded to earlier, this fine:

   yield self.authorize_redirect(
       redirect_uri=settings.fb_redirect_url,
       client_id=self.settings['facebook_api_key'], 
       extra_params={'scope': 'email'}
   )
   

   As a small aside, I don't like having the ending param on a line by itself; its too C/Java-like.

   However, my personal preference is to indent them to line up (or as close to in line) with the section of the statement they are related to. Take this 'simple' example:

   # Technically OK.
   some_long_variable_name = [foobar for foobar in map(ord, 'Hello World!')
       if foobar < 97]
   
   # My preference.
   some_long_variable_name = [foobar for foobar in map(ord, 'Hello World!')
                              if foobar < 97]
   

   In the first statement above, its slightly difficult to tell at a glance the if statement is in the list comprehension. Even though they are related syntactically, they currently aren't related spatially.

   Now in the second statement, the if statement and the rest of the comprehension are related spatially which, personally, helps the code make more sense at a glance.

   Here is how I would structure your code:

   yield self.authorize_redirect(redirect_uri=settings.fb_redirect_url,
                                 client_id=self.settings['facebook_api_key'], 
                                 extra_params={'scope': 'email'})
   

Otherwise, your code looks pretty good. I really wanted to look more into a single Login class because your two classes are so similar. However, a solution did not come quickly to mind and creating one would go past the bounds of typical code review.