integrate google oauth #50
Conversation
we don't need password hashes for oauth-authenticatd users
we don't need password hashes for oauth-authenticatd users
this lets us keep logic in views and just use oauth to fill out forms
refactor logic here too so that captains are now notified in all cases, and it is not possible to join a team twice
| @@ -13,3 +13,6 @@ class Config: | |||
| MYSQL_USERNAME = os.environ.get('MYSQL_USERNAME', 'spaceship-app') | |||
| MYSQL_PASSWORD = os.environ.get('MYSQL_PASSWORD', 'aa7925b6f7b') | |||
| MYSQL_DB = os.environ.get('MYSQL_DB', 'spaceship') | |||
|
|
|||
| GOOGLE_CLIENT_ID = os.environ.get('GOOGLE_CLIENT_ID', '700492634886-qbhv3gss1a59lm5p93gr7plo872auaba.apps.googleusercontent.com') | |||
There was a problem hiding this comment.
we should probably treat this cred the same as the sendgrid key, where if you want google oauth to work locally you can pull the secret off the k8s cluster. i can work on that.
There was a problem hiding this comment.
ack, i'll merge this first, since it seems harmless and least likely to mess up others' workflows for now
There was a problem hiding this comment.
tracked in issue #53
| password = register.data['password'] | ||
|
|
||
| if name and email_address: | ||
| with db.atomic() as transaction: |
There was a problem hiding this comment.
mmm, we have a bit of copy-pasta. i think our views are starting to get a little heavy, i'd like to refactor some of this code into service objects or some equivalent way to encapsulate business logic (since service objects seem very RoR-oriented)
There was a problem hiding this comment.
hrm, yeah, we could just move related sets of db mutation and queries out into functions in logically named files. i'll take a look at this after some ui tweaks and other stuff for mvp is in.
There was a problem hiding this comment.
tracked in issue #52
* 'oauth' of github.com:spaceshipearth/pyspaceship: k8s: add a port variable to mysql config db: use a connection pool views: add a logger explicitly open and close connections for each request use mission title to link to mission research details
|
thanks for reviewing, I addressed some comments in a followup patch and left open one discussion about refactoring. |
|
oops didn't mean to close, apparently |
Integrates google oauth into captain registration, login, and invite flows.
Views can now link users to /google/login with session['oauth_next_url'] set to a
callback url. After authentication, google will redirect to /google/auth, which will
redirect to session['oauth_next_url'] with session['oauth_user_info'] filled with user
data. This allows us to modify existing view logic to grab data from the session
store instead of from form fields.
The use of global session store isn't ideal, but there doesn't seem to be a better
way. As a precaution, oauth session keys should always be popped by consuming
views, and are cleared for non-consuming views by an @app.before_request
handler.
This patchset also includes some UI changes to make the sign in button fit in more
sensibly with the existing UI, and a few fixes for minor bugs in the enlist flow.
Fixes #1