* Generate common/djangoapps import shims for LMS
* Generate common/djangoapps import shims for Studio
* Stop appending project root to sys.path
* Stop appending common/djangoapps to sys.path
* Import from common.djangoapps.course_action_state instead of course_action_state
* Import from common.djangoapps.course_modes instead of course_modes
* Import from common.djangoapps.database_fixups instead of database_fixups
* Import from common.djangoapps.edxmako instead of edxmako
* Import from common.djangoapps.entitlements instead of entitlements
* Import from common.djangoapps.pipline_mako instead of pipeline_mako
* Import from common.djangoapps.static_replace instead of static_replace
* Import from common.djangoapps.student instead of student
* Import from common.djangoapps.terrain instead of terrain
* Import from common.djangoapps.third_party_auth instead of third_party_auth
* Import from common.djangoapps.track instead of track
* Import from common.djangoapps.util instead of util
* Import from common.djangoapps.xblock_django instead of xblock_django
* Add empty common/djangoapps/__init__.py to fix pytest collection
* Fix pylint formatting violations
* Exclude import_shims/ directory tree from linting
This change adds a Django authentication backend which, when installed
will authenticate users based on their LTI identity rather than using
a username/password combination. The authentication method determines
first whether a user with the given username exists and, if so, whether
that user is associated with an LTI identity. It also verifies that
the LTI consumer and user ID passed to the LTI launch match those
stored in the LtiUser table. This will always be the case if the
authentication backend is reached through the LTI code, but it
provides an extra guarantee if the backend is called from elsewhere.
This is an initial authentication implementation that allows LTI users to
log in transparently to edX. The behavior is driven by pilot users at
Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers
to newly-created edX accounts. If an LTI launch comes in with a user_id
field that is not in the database, a new edX account is created with a
random user name and password. This account is then stored in the
database, so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user
is logged in with a different account when they perform an LTI launch,
they will be logged out and then re-logged in using their LTI account.
In order to keep the patch simple, I have split out some refactoring
that needs to be done into a separate branch that I'll post once this
has been merged. Since we no longer redirect to the login page, we don't
need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that
requires. There are also multiple fetches of the LtiConsumer object
(one in the view, one in the signature validation) that the later
patch will consolidate into one.
This branch fixes the previous conflicts with the test refactoring
carried out in PR 8240.
This change cleans up the work in progress request at https://github.com/edx/edx-platform/pull/8176
This is an initial authentication implementation that allows LTI users to log in transparently to
edX. The behavior is driven by pilot users at Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers to newly-created edX
accounts. If an LTI launch comes in with a user_id field that is not in the database, a new edX
account is created with a random user name and password. This account is then stored in the database,
so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user is logged in with a
different account when they perform an LTI launch, they will be logged out and then re-logged
in using their LTI account.
In order to keep the patch simple, I have split out some refactoring that needs to be done into
a separate branch that I'll post once this has been merged. Since we no longer redirect to the
login page, we don't need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that requires. There are
also multiple fetches of the LtiConsumer object (one in the view, one in the signature
validation) that the later patch will consolidate into one.
