Third Party Service Keys

[hunt3131]

I'm working on a couple more outlets and they both use api keys and
the like. Since the only other outlet that currently uses any kind of
auth is the Desktop notifier, and the real keys shouldn't be in the
repo, it might be nice to figure out some conventions for dealing with
this in the future. Maybe there is a better way to do this, but this
is what I did:

- Added dev_keys.py for keys to live in during development. It isn't
tracked so you are free to add anything in here while working on
adding an outlet without committing the keys.

dev_keys.py looks something like this, with the real keys that you
get after signing up for whatever service (notifo is lowercased since
it looks better to write keys.notifo.secret):

class notifo():
secret = <api secret>
username = <username>


Then when the keys module is being imported in outlet_types.py
(probably a better way to do this):

try:
import keys
except ImportError:
try:
import dev_keys
keys = dev_keys
except ImportError:
keys = None


So if you don't have any of the key files it won't blow up (at least
until you try to send a notification to an outlet that uses one). In
your outlet class you can just use keys.notifo.secret and
keys.notifo.username, then when the keys get added to the real key
file, it should still work. When it comes time to deploy it Jeff will
have to get the real keys from you and add them to the real key file,
or maybe create an account himself and set it up.

Lastly, I added test_keys.py, which you can use to add some fake keys
for your outlet to be used in the test suite, and just make sure that
is the key file that is used for the tests. These keys can be fake
since you don't want to actually go across the wire anyways.

Does that sound reasonable? Any suggestions about better ways to do
this?

[Jeff Lindsay]

So these are keys for each user? Wouldn't it be similar to the Prowl
outlet in that it keeps a key for each Prowl outlet a user creates?

--
Jeff Lindsay
http://progrium.com

[Hunter Gillane]

I was trying to avoid having to ask them for their api key, so this would be key for a single service that we set up on Notifo. It seems like it would be easier (from a user's standpoint) to just ask them for their username and take care of subscribing them to the Notify.io service we set up on Notifo behind the scenes. The alternative is that they would have to go to the Notifo site and subscribe to the Notify.io service manually. The only downside to setting up a single Notifo service is that is there is a limit of 10,000 notifications/month for free on Notifo. If you'd rather just have them give us their api key, let me know.

--
Hunter Gillane
President - ACM UCI Chapter
hunter....@gmail.com
(949) 370-3783

[Jeff Lindsay]

Yeah, you're right it's better we handle the API key when possible to
avoid them the integration step, but as long as that doesn't get in
the way of us being able to notify a particular user. If Notifo's API
allows you to notify any user then that's fine. I assume they have
some kind of approval step like we do but that it's taken care of on
their side.

For global keys, I like to avoid separate key modules ignored in the
repo because it's too easy to deploy a cloned repo and then everything
breaks because the key module wasn't uploaded. Unfortunately App
Engine doesn't have any kind of environment variables. For this
purpose I've made a module called keymaster:

https://github.com/hackerdojo/hd-signup/blob/master/keymaster.py

See that project's main.py at the bottom for how to install it. Then
you hit /_km/key and install keys that will be stored encrypted and
only settable (not viewable) by admins.

-jeff