Closed GVRV closed 12 years ago
App keys/secrets are configured in the database, not in a settings file. Why not is mentioned in the documentation:
"Consumer keys, tokens make use of the Django sites framework. This is especially helpful for larger multi-domain projects, but also allows for for easy switching between a development (localhost) and production setup without messing with your settings and database."
@pennersr I understand that, however most django installations do not use different django sites for dev/staging/production environment - they usually use different settings modules that override the necessary settings values for the given environment, and therefore it would be helpful to be able to set the APP ID and APP SECRET in the settings file as opposed to the database (maybe in addition to?) like many other popular django applications.
You can influence the app ids/secrets that are used via the settings by choosing an alternate settings.SITE_ID. I prefer not to introduce too many ways to achieve the same result. So, unless there are any clear benefits from doing so (other than the fact that this may be more popular) I have currently no plans move the ids/secrets into the settings.
It is hard to provide tangible proof of benefits apart from saying that because this is a popular method for configuring django sites, supporting it would help reduce friction in the adoption of the library.
I understand. Please note that tokens are typically app id/secret dependent. So, by simply moving these to the settings you run the risk of completely invalidating your database tokens by changing a setting. At least the way it is setup now you can switch from e.g. localhost development to production without running the risk of mixing up tokens or invalidating them (assuming you use a different SITE_ID to differentiate production from development).
Seconding this - I never configure anything from the database, always via settings files specific to local, dev, stage, production, etc. Having one component of my site configuration coming from the database is a big headache.
A few points:
token.app.secret
If you really don't want to manage the configuration in the database, how about:
post_syncdb
signal that reads the app config from your settings and creates the SocialApp models accordingly.All in all, adding this functionality if it weren't foreseen in the allauth core beforehand is rather non trivial. Whereas pushing your settings via a post_syncdb
signal can be done quite easily.
There's no mention of it in the documentation, so is it possible to change the APP id and secret of the various authentication providers from just the settings files? If so, the documentation should probably mention it. If not, why not?