Changing app id and app secret for production environment

[GVRV]

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?

[pennersr]

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."

[GVRV]

@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.

[pennersr]

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.

[GVRV]

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.

[pennersr]

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).

[lsemel]

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.

[pennersr]

A few points:

• The site apps also features configuration coming from the database (domain name)
• The current mechanism allows for looking up the app key/secrets, given a token, in a clean way, simply by token.app.secret
• I am running multi-domain projects where the app various per site, all running in a single Django project instance. For such setups, not having this functionality causes a headache.

If you really don't want to manage the configuration in the database, how about:

• Using fixtures
• Or, use a 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.