ju/ednx/JD-1: Microsite aware key-secret pairs for oauth

[mariajgrimaldi]

Description

This PR allows each tenant to have its own key-secret pair.

Changes and justification

• Changes KEY_FIELD from KEY_FIELDS = ('backend_name') to KEY_FIELDS = ('site_id', 'backend_name',): this allows to create differents OauthProviderConfig per site.

For example:

With KEY_FIELDS = ('backend_name'), we could only have a max of active OauthProviderConfig equals the number of available backends.
Say that we have an active OauthProviderConfig for Google and Facebook, if we add a new one for Google even with different data but with the same backend -for Google-, the old config will be updated and the new one will be the active.

Here some proof of that:

1. I had a Provider Configuration with the backend: google-oauth2 for the site .ngrok.io
   

2. After I added a new Config for test-cert with the same backend, this happened:
   

But with KEY_FIELDS = ('site_id', 'backend_name') we can have the same max but per site, so we can have for each site a new config but with different backends.

For this, I followed this PR: /edx/edx-platform/pull/17276

• Pass site_id to current method calls: after changing KEY_FIELDS the current will use them as lookup fields to find the current configs, so now we have to pass the site_id.

• Override provider_id to cast field: adding site_id to KEY_FIELDS makes provider_id to change and add site_id (which is a number).

• Change get_setting so the key can be searched in settings: this makes it more flexible to store key/secrets, they can be stored using the OauthProviderConfig or the tenant settings.

Consequences

• current method override is no longer used
• THIRD_PARTY_AUTH_ENABLED_PROVIDERS is no longer used
• From what I understand, KEY_FIELDS makes unique active configurations. So, if in PROD there are two configurations with the same SITE and BACKEND the active configuration will be the latest one.
• Because we change how current is called, some tests fail. I already fixed them.

Data changes
https://docs.google.com/document/d/1CMoG_YoaYIuIGLQG2kDbvMQ4k0QNpu4GXAd3bSplCxA

Questions and possible answers

• why not use site_id and slug instead of backend? Well, here's the reason:
  Here

  edunext-platform/common/djangoapps/third_party_auth/provider.py

  Line 34 in 9a69118

  oauth2_backend_names = OAuth2ProviderConfig.key_values('backend_name', flat=True)

  instead of searching for backend_name, that the max is the number of backends available, we would need to look for slugs that normally exceed the number of backends available

LMS logs during the login process using Google:

[felipemontoya]

I would like to understand the consequences of the key change as well as the data changes that we would need to do in the PROD data for this to work with the current clients

[andrey-canon]

why is this necessary, there is a consequence if this returns None instead of False ?

[mariajgrimaldi]

I cherry-picked this from ir/ednx/JD-1. I'm gonna do some tests to check if there's a consequence

[mariajgrimaldi]

do you know why is this change? I can't figure it out. @felipemontoya

[felipemontoya]

I remember something about this needing to be turned on when the server starts (aka the yml file) and then be turned off for all the tenants which dont have a need for it.

[mariajgrimaldi]

do you agree to merge this? @felipemontoya

[felipemontoya]

Maybe I missed something or we already tried and something was not working, but in this particular point I think we should consider again modifying the .current method.

[felipemontoya]

I remember something about this needing to be turned on when the server starts (aka the yml file) and then be turned off for all the tenants which dont have a need for it.