Andal.LND/edx-platform
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #34857 from CodeWithEmad/chore/cleanup

Browse Source 
chore: cleanup
This commit is contained in:
Feanil Patel
2024-06-04 09:35:28 -04:00
committed by GitHub
parent 83af6537dd 53da608097
commit 6b0789a255
45 changed files with 448 additions and 423 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
openedx/core/djangoapps/course_apps/docs/decisions/001-course-apps.rst
View File

@@ -1,12 +1,13 @@
Course Apps API
_______________
###############
Status
======
******
Proposal
Context
=======
*******
The new `Course Authoring MFE`_ includes a new UX called "Pages and Resources"
for configuring different aspects of the course experience such as progress,
@@ -27,7 +28,7 @@ enable/disable these apps using the API.
Decision
========
########
We propose to call such individual course features "Course Apps". They can be
introduced as a new type of Open edX plugin. Any functionality that can be
@@ -39,16 +40,29 @@ some bits of metadata, such as a name, a description etc. Additionally we will
need a common interface for such apps so they can be enabled/disabled using
a standard common interface.
To do this we can follow the example of existing plugins, [such as Course
Tabs](https://github.com/openedx/edx-platform/blob/636b2ca4c5add531cfce755fdb8965599acd79e0/common/lib/xmodule/xmodule/tabs.py#L24-L243),
To do this we can follow the example of existing plugins, `such as Course Tabs`_,
which provide a specific Python class that the plugin can inherit from, or
implement. The required metadata and features, can be implemented as class
attributes, and methods on this class.
We can then discover the installed apps using the existing tooling for plugins
using a subclass of PluginManager designed for this purpose. Here is an example
for [Course
Tabs](https://github.com/openedx/edx-platform/blob/636b2ca4c5add531cfce755fdb8965599acd79e0/openedx/core/lib/course_tabs.py#L13-L47)
using a subclass of ``PluginManager`` designed for this purpose.
Here is an example for `CourseTabs`_:
.. code-block:: python
class CourseTabPluginManager(PluginManager):
"""
Manager for all of the course tabs that have been made available.
All course tabs should implement `CourseTab`.
"""
NAMESPACE = COURSE_TAB_NAMESPACE
@classmethod
def get_tab_types(cls):
"""
Returns the list of available course tabs in their canonical order.
It might not always make sense for an app installed in this way to be
automatically show up for use on all courses. So each app will expose a method
@@ -85,14 +99,17 @@ In the case of Course Apps, the standard plugin API will automatically discover
all installed apps. Inactive apps will be filtered out during the availability
check.
Course App Plugin Class
-----------------------
.. _such as Course Tabs: https://github.com/openedx/edx-platform/blob/636b2ca4c5add531cfce755fdb8965599acd79e0/common/lib/xmodule/xmodule/tabs.py#L24-L243
.. _CourseTabs: https://github.com/openedx/edx-platform/blob/636b2ca4c5add531cfce755fdb8965599acd79e0/openedx/core/lib/course_tabs.py#L13-L47
To be loaded as a Course App, you need to provide an entrypoint in `setup.py`
with the namespace "openedx.course_app". The entry should point to a Python
Course App Plugin Class
=======================
To be loaded as a Course App, you need to provide an entrypoint in ``setup.py``
with the namespace ``openedx.course_app``. The entry should point to a Python
class with the following basic structure:
.. code-block :: python
.. code-block:: python
class CourseApp:
# The app id should match what is specified in the setup.py entrypoint
@@ -143,7 +160,7 @@ such a class and have these class methods call back to the existing code for
availability checks and enabled checks.
Course Apps API
---------------
===============
Each app has some associated metadata:
@@ -218,9 +235,8 @@ link should only be provided for Course Apps that don't have a UI in the course
authoring MFE yet. If a partial UI exists, the MFE settings view can always link
back to the old studio view from there.
Consequences
============
************
- A new Course Apps API that consistently uses a standard mechanism (a plugin
class) for discovering Course Apps, determining their availability and

2
openedx/core/djangoapps/oauth_dispatch/docs/decisions/0006-enforce-scopes-in-LMS-APIs.rst
View File

@@ -99,7 +99,7 @@ unprotected microservices.
4. Associate Available Scopes with Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to allow open edX operators to a priori limit the
In order to allow Open edX operators to a priori limit the
types of access an Application can request, we will allow them
to configure Application-specific "available scopes".

8
openedx/core/djangoapps/oauth_dispatch/docs/decisions/0009-jwt-in-session-cookie.rst
View File

@@ -28,7 +28,7 @@ user interacts with the overall application, the user's experience may lead them
each accessing APIs on various backends. Stateless authentication (via self-contained JWTs) would allow scalable
interactions between microfrontends and microservices.
Note: User authentication for open edX mobile apps is outside the scope of this decision record. As a brief note, we
Note: User authentication for Open edX mobile apps is outside the scope of this decision record. As a brief note, we
believe any decisions in this record will neither affect the current authentication mechanisms used for mobile
apps nor impact forward compatibility when/if mobile apps are consolidated to use a similar (if not the same)
authentication mechanism as outlined here for web apps.
@@ -69,7 +69,7 @@ Login -> Cookie -> API
recombined JWT in a temporary cookie specified by JWT_AUTH_COOKIE_.
* The `Django Rest Framework JWT`_ library we use makes use of the JWT_AUTH_COOKIE_ configuration setting.
When set, the JSONWebTokenAuthentication_ class `automatically extracts the JWT from the cookie`_. Since all
open edX REST endpoints that support JWT-based authentication derive from this base class, their authentication
Open edX REST endpoints that support JWT-based authentication derive from this base class, their authentication
checks will make use of the JWTs provided in the JWT-related cookies.
#. **Introduce forgiving JWTs for backward compatibility.**
@@ -121,7 +121,7 @@ JWT Cookie Lifetime
* For simplicity and consistency, the cookies and their containing JWT will expire at the same time. There's
no need to have these be different values.
* Given this, JWT cookies will always have expiration values, unlike `current open edX session cookies that may
* Given this, JWT cookies will always have expiration values, unlike `current Open edX session cookies that may
have no expiration`_.
* A configuration setting, JWT_AUTH_COOKIE_EXPIRATION, will specify the expiration duration for JWTs and their
@@ -141,7 +141,7 @@ JWT Cookie Lifetime
which will remove them from the user's browser cookie jar. Thus, the user will be logged out of all the
microfrontends.
.. _`current open edX session cookies that may have no expiration`: https://github.com/openedx/edx-platform/blob/92030ea15216a6641c83dd7bb38a9b65112bf31a/common/djangoapps/student/cookies.py#L25-L27
.. _`current Open edX session cookies that may have no expiration`: https://github.com/openedx/edx-platform/blob/92030ea15216a6641c83dd7bb38a9b65112bf31a/common/djangoapps/student/cookies.py#L25-L27
.. _JWT blacklist: https://auth0.com/blog/blacklist-json-web-token-api-keys/
.. _`JWT ID (jti)`: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#jtiDef

2
openedx/core/djangoapps/oauth_dispatch/docs/how_tos/testing_manually.rst
View File

@@ -1,7 +1,7 @@
Manually Testing OAuth2 Provider implementation
-----------------------------------------------
This document explains how to manually test the open edX LMS' OAuth2 Provider
This document explains how to manually test the Open edX LMS' OAuth2 Provider
implementation. In order to verify that it correctly implements the
`OAuth2 standard`_, use a publicly available 3rd party standard OAuth2 client.
The steps here show how to use `Google's OAuth2 Playground`_ as the client for

8
openedx/core/djangoapps/safe_sessions/tests/test_middleware.py
View File

@@ -326,9 +326,9 @@ class TestSafeSessionMiddleware(TestSafeSessionsLogMixin, CacheIsolationTestCase
self.request.path = '/xblock/block-v1:org+course+run+type@html+block@block_id'
self.verify_success()
@override_settings(MOBILE_APP_USER_AGENT_REGEXES=[r'open edX Mobile App'])
@override_settings(MOBILE_APP_USER_AGENT_REGEXES=[r'Open edX Mobile App'])
def test_success_from_mobile_app(self):
self.request.META = {'HTTP_USER_AGENT': 'open edX Mobile App Version 2.1'}
self.request.META = {'HTTP_USER_AGENT': 'Open edX Mobile App Version 2.1'}
self.verify_success()
def verify_error(self, expected_response_status):
@@ -364,9 +364,9 @@ class TestSafeSessionMiddleware(TestSafeSessionsLogMixin, CacheIsolationTestCase
self.request.META['HTTP_ACCEPT'] = http_accept
self.verify_error(expected_response)
@override_settings(MOBILE_APP_USER_AGENT_REGEXES=[r'open edX Mobile App'])
@override_settings(MOBILE_APP_USER_AGENT_REGEXES=[r'Open edX Mobile App'])
def test_error_from_mobile_app(self):
self.request.META = {'HTTP_USER_AGENT': 'open edX Mobile App Version 2.1'}
self.request.META = {'HTTP_USER_AGENT': 'Open edX Mobile App Version 2.1'}
self.verify_error(401)
@override_settings(ENFORCE_SAFE_SESSIONS=False)

2
openedx/core/lib/.coveragerc
View File

@@ -8,7 +8,7 @@ parallel = true
ignore_errors = True
[html]
title = Open edx Core Lib Python Test Coverage Report
title = Open edX Core Lib Python Test Coverage Report
directory = reports/openedx/core/lib/cover
[xml]

2
openedx/core/lib/mobile_utils.py
View File

@@ -10,7 +10,7 @@ from django.conf import settings
def is_request_from_mobile_app(request):
"""
Returns whether the given request was made by an open edX mobile app,
Returns whether the given request was made by an Open edX mobile app,
either natively or through the mobile web view.
Args: