Migrate Studio video endpoints to authz permissions

Abierto
  • ¿Algo no está bien?
#605 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
authorization

Línea de trabajo

Start with the asset permission pattern in cms/djangoapps/contentstore/asset_storage_handlers.py and the video entry points cms/djangoapps/contentstore/views/videos.py and cms/djangoapps/contentstore/video_storage_handlers.py. First resolve whether videos should reuse file permissions or get dedicated permissions; the issue identifies this as an open product and authz decision. Done means each listed endpoint enforces the appropriate read or write permission, legacy fallback remains, and tests cover roles and methods.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

willow
Description

The Studio video endpoints (/videos/<course_key> and related) do not use authz permissions. The ones that check access go through get_course_and_check_access, which only looks at legacy roles, so users with authz-only roles (e.g. Editor, Auditor) get 403. Even for legacy users, one check covers list, upload and delete, with no read/write distinction. Several related endpoints do not check course access at all.

Current Behavior
  • videos_handler (views/videos.py:97) → handle_videos → _get_and_validate_course (video_storage_handlers.py:634) → get_course_and_check_access (views/course.py:167) → has_studio_read_access → get_user_permissions (common/djangoapps/student/auth.py:83). get_user_permissions only considers legacy roles (GlobalStaff, OrgInstructorRole, CourseInstructorRole, etc.).
  • GET (list), POST (upload) and DELETE share the same check. An Auditor would be able to upload and delete if they passed it.
  • generate_video_upload_link_handler and video_encodings_download also go through _get_and_validate_course, with the same legacy check.
  • Some endpoints have no course permission check, only login or authentication:
    • video_images_handler (handle_video_images): only @login_required; the course key is used only for the upload path.
    • transcript_preferences_handler (handle_transcript_preferences): only @login_required.
    • get_course_youtube_edx_videos_ids (get_course_youtube_edx_video_ids): only view_auth_classes(), and it reads the course structure.
  • The comment in _get_and_validate_course says "assume all studio users that have access to the course can upload videos".
Expected Behavior

All video endpoints enforce authz permissions, with read separated from write:

  • Listing videos and downloading encodings requires view permission.
  • Uploading, changing images/transcript preferences and deleting require the matching edit/create/delete permission.
  • Users with authz-only roles work according to their permissions. Legacy behavior is unchanged when authz is not enabled for the course.
Steps to reproduce
  1. Log in as a user with an authz-only role (Editor or Auditor) and no legacy course role.
  2. Open /videos/course-v1:Ax+Ax+2026 (Studio, port 8001).
  3. Observe the 403.
  4. (No-check endpoints) Log in as any authenticated user with no access to a course and POST to /video_images/<course_key>/<edx_video_id> or /transcript_preferences/<course_key>; the request is not rejected for lack of course access.
Acceptance Criteria
  • The permission model for videos is decided (see Proposed Solution) and any missing permissions are added to openedx-authz.
  • _get_and_validate_course (or its callers) uses user_has_course_permission with an authz permission and the legacy fallback.
  • GET videos_handler and video_encodings_download require the view permission; POST and generate_video_upload_link require create/edit; DELETE requires delete.
  • video_images_handler, transcript_preferences_handler and get_course_youtube_edx_videos_ids check course permission.
  • Users without the right permission get 403; an Auditor cannot upload or delete.
  • Legacy roles keep their current access when authz is disabled for the course.
  • Tests are added or updated for each role and method.
Proposed Solution

Follow the pattern used by the assets handler (_authz_enforce_file_permissions in asset_storage_handlers.py:100): a minimum view permission, then create/edit/delete checks on top when enable_authz_course_authoring(course_key) is on, each with a LegacyAuthoringPermission fallback.

Open question: reuse the existing files permissions (COURSES_VIEW_FILES, COURSES_CREATE_FILES, COURSES_EDIT_FILES, COURSES_DELETE_FILES) or add dedicated video permissions. Videos live in the same "Files & Uploads"-style area for users, but the code comment mentions a future dedicated video-uploader role, so this needs a product/authz decision.

Technical Notes
  • Files: cms/djangoapps/contentstore/views/videos.py, cms/djangoapps/contentstore/video_storage_handlers.py, cms/urls.py:181.
  • video_images_upload_enabled and get_video_features only return feature flags and likely need no change.
Related Issues

Related to openedx/openedx-authz#286.

Lenguaje dominante
Python
Estrellas
0
Forks
10
Merge medio
5 d 9 h
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openedx/openedx-authz

Todos los issues de openedx/openedx-authz

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.