The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.
In a structure like:
@override_settings(MODULESTORE=store_a)
class BaseTestCase(ModuleStoreTestCase):
def setUp(self):
# use store
@override_settings(MODULESTORE=store_b)
class ChildTestCase(BaseTestCase):
def setUp(self):
# use store
In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.
To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.
[PLAT-419]
Makes logistration available at /login and /register as well as /accounts/login/ and /accounts/register/. In addition:
- Adds support for redirect URLs in third party auth for combined login/registration page
- Adds support for external auth on the combined login/registration page
- Removes old login and registration acceptance tests
- Adds deprecation warnings to old login and register views
- Moves third party auth util to student_account
- Adds exception for microsites (theming)
This reverts commit f40447b3c8.
Conflicts:
lms/urls.py
Revert "Add support for external auth on the combined login/registration page"
This reverts commit 988753395f.
Conflicts:
lms/templates/courseware/mktg_course_about.html
lms/urls.py
Add support for redirect URLs in third party auth for combined login/registration page
Remove old login/registration acceptance tests
Add deprecation warnings to old login and register views
Move third party auth util to student_account
Add exception for microsites
Change third party auth login failure code to a 401, to detect authentication
success with no linked account.
If already authenticated, redirect immediately to the dashboard.
Use "Location" header correctly for 302 redirects from student views.
Add utility functions for simulating a running third-party auth pipeline.
Add a utility function for checking whether third party auth is enabled.
Respect default values sent by the server
Add Python APIs for account/profile information to user_api
Updating profile page to have social linking
Authors: Renzo Lucioni, Alasdair Swan, Stephen Sanchez, Will Daly
Also, removed the client-side analytics for logging in.
Ensures that analytics are collected for third-party-auth logins.
Fixed failing tests related to third-party-auth.
Move the open edx logo inside the div
Adding a bunch of placeholder views.
indenting.
Making some styles work against LMS sass.
Adding back the old edx footer and associated icons, with a feature flag.
This change adds three new configuration variables to third_party_auth's LinkedIn provider:
* SOCIAL_AUTH_LINKEDIN_OAUTH2_SCOPE,
* SOCIAL_AUTH_LINKEDIN_OAUTH2_FIELD_SELECTORS,
* SOCIAL_AUTH_LINKEDIN_OAUTH2_EXTRA_DATA
Being able to configure these additional settings is useful if you want
the LinkedIn provider to pre-populate the email field when a new user
registers via the linkedin provider.
The Google provider prepoulates the email field by default, but if you
want LinkedIn to do the same, these two settings should be set to:
SOCIAL_AUTH_LINKEDIN_OAUTH2_SCOPE = ['r_basicprofile', 'r_emailaddress']
SOCIAL_AUTH_LINKEDIN_OAUTH2_FIELD_SELECTORS = ['email-address']
For more info see:
http://psa.matiasaguirre.net/docs/backends/linkedin.html
third_party_auth contains a working settings mechanism, the start of the provider interface + 3 implementations (Google, Mozilla Persona, LinkedIn), and a stub for the auth pipeline. Modified existing lms settings files to use but deactivate the module.