Move to an Application-based model (maybe)

[jleclanche]

Copied from #205:

Following up on that, I would like to look into potentially adding an Application model. Doing so seems like a more appropriate approach than what's been presented in the PR. Secret storage is still an open question, I do not want to force users to store private keys or anything like that in the database. Maybe we can do a mixed approach with secrets in the settings, apps in the db? I don't know. Needs a design doc.

This is intrinsically linked to multi-app support (#348).

This is open for the taking. If you work on this please write a design proposal first, as the most important part of this is designing the API and making sure it's easy to migrate to and/or backwards compatible.

[matthewh]

What's the reason for not accepting PR #348 as is?

[jleclanche]

• Security issue of private keys in db is not figured out
• It's adding unrelated functionality to both APNS and GCM without documentation nor explanations
• The Application-based model is something I like, but I want it to be done right.

Mostly that last one though. Right now, in the PR, apps are a kludge.

[matthewh]

I think one additional level of abstraction is needed. We should be able to group "applications" into logical units. For instance, if I have an iOS and Android clients those are two different "applications" but I want a "group" that contains both of those so that I can do things like "Notify all users of Application Group: MyApp that there will be scheduled downtime." That should cover both iOS and android clients. I'd propose an Application is the top level container for a set of configurations covering iOS, Android, WNS, etc. Each platform specific variation would be called a Variant. If we are tied to Application being left as the platform specific configuration then I guess we are stuck with Application Group or Project or something similar.

I think storing keys/key material/etc in a DB is essential. We do not want to restart our push service every time there is a change. Plus the current setup requires a backend programmer/engineer to make the change. By moving this material into a DB, and exposing this via the Django Admin (or other UI), we allow the mobile client developers to update their information. One approach would be to create a secondary DB and place the keys there. With Django, we could configure two databases in settings, by default DPN would use the default DB for both. It sounds like some concept of storage adapters for private material would be useful. Out of the box DPN uses the current settings configuration. Developers could swap in a DB storage module if desired.

[jleclanche]

My main concern is that I do not want to force users to store sensitive data like that in the database, unencrypted. I want to make sure users can do it differently if they need to. If that means creating some sort of replaceable backend to get the data out of there and have it pull from the unencrypted db by default, I'm fine with it.

[jleclanche]

I agree regarding app groups.