CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses
Expertiza
Expertiza is an open-source learning management system developed with Ruby on Rails, aimed at enhancing collaborative learning through peer review and teamwork. It enables educators to create assignments in various formats, supports peer assessments, and allows students to work individually or in teams. Designed to foster critical thinking and interactive learning, Expertiza provides educators with tools to monitor progress and facilitate feedback, making it a valuable platform for managing assignments and promoting collaborative education.
Introduction
The “UI and Backend for Courses” project aims to improve course management in Expertiza by developing a user-friendly interface with React and TypeScript and implementing robust backend CRUD operations. The backend supports role-based access control, allowing Admins, Instructors, and TAs to perform course-related actions according to their permissions, ensuring secure and efficient course management.
Problem Statement
The primary goal of this project is to create an efficient and user-friendly system for managing courses within Expertiza, with a strong emphasis on backend role-based permissions. The system should allow different user roles—Admin, Instructor, and TA—to interact with course data in ways appropriate to their responsibilities. Admins and Instructors require full access to create, read, update, and delete courses, enabling them to manage course information comprehensively. Teaching Assistants (TAs), however, should have limited access, restricted to reading and updating course information only, without the ability to create or delete courses. This role-based control ensures that only authorized users can make significant changes, enhancing both security and data integrity within the course management system.
Design Goals
1. Role-Based CRUD Operations: Implement precise role-based access control, allowing Admins and Instructors full CRUD permissions on courses, while restricting TAs to read and update access only. This ensures data integrity and security by controlling access based on user roles.
2. Efficient Data Handling: Design CRUD operations to handle large datasets efficiently, optimizing database queries to support quick data retrieval and updates, which is essential for managing potentially extensive course information.
3. Error Handling and Validation: Ensure robust error handling and input validation on all endpoints to prevent invalid data from entering the system and to provide clear error responses, improving system reliability and user feedback.
4. API Documentation and Testing: Use RSwag to document and test each CRUD endpoint, generating interactive Swagger documentation to streamline development, ease future integrations, and facilitate testing of all course-related operations.
5. Modular and Scalable Architecture: Structure the backend with modular components and adhere to design principles (e.g., SRP, DRY) to make the system maintainable and scalable, allowing for future extensions with minimal code duplication and impact on existing functionality.
Design
Implementation Plan
Create Action:
The create action allows Admins and Instructors to add new courses. Data validations and security checks ensure data integrity. Upon success, the response includes the new course details in JSON format.
Read Action:
The read action retrieves course details and displays them on the UI. Admins, Instructors, and TAs can access this functionality, ensuring secure data handling and JSON-formatted output.
Update Action:
The update action enables Admins and Instructors to modify course details. TAs have limited permissions, restricted to updating certain fields. Validation checks ensure data accuracy and integrity.
Delete Action:
Only Admins and Instructors can delete courses. The delete action requires authentication, and a success message is returned upon completion.
Role-Based CRUD Operations
• Admin and Instructor: Full access to all actions.
• TA: Restricted to reading and updating, ensuring role-specific data control and security.
Design Principles
Single Responsibility Principle (SRP)
• Definition: A class or function should have only one reason to change, meaning it should focus on a single task or responsibility.
• Implementation in the Project: Each function in the course management module (e.g., create, update, delete, and read functions) is designed to handle only one specific action related to course management. For example, the create function is solely responsible for handling the addition of new courses, while update handles modifications to existing courses. By isolating these responsibilities, changes in one function (e.g., adding new validations to create) don’t impact others. This separation allows for easier testing, debugging, and future modifications without introducing unintended side effects.
Don’t Repeat Yourself (DRY) Principle
• Definition: Redundant code should be minimized by consolidating repetitive functionality into reusable functions or modules.
• Implementation in the Project: Shared functionalities, such as data validation, error handling, and database operations, are extracted into helper modules that can be reused across different functions. For instance, if multiple actions (like create and update) require data validation, the validation logic can be placed in a helper function and invoked as needed. This approach reduces redundancy, making the code more concise, easier to maintain, and less error-prone. It also enhances scalability, as any updates to the validation logic need only be made in one place.
Encapsulation
• Definition: Data and methods should be contained within their respective classes or modules, with controlled access to prevent unintended modification or misuse.
• Implementation in the Project: Backend controllers in the project are designed to handle only essential data and expose only necessary functionality. Access to instance variables and controller actions is restricted, and sensitive operations are encapsulated within protected functions. For instance, only authorized roles (like Admin and Instructor) can access certain CRUD operations. Encapsulation also promotes data integrity by ensuring that only authorized functions can modify or interact with critical data fields, preventing unauthorized access or accidental changes.
Separation of Concerns (SoC)
• Definition: Different parts of the application should address distinct concerns, making it easier to manage, maintain, and extend the system.
• Implementation in the Project: The project separates UI components from backend functionality, ensuring that the user interface handles user interactions, while backend controllers manage data processing and business logic. For example, frontend components (React) are responsible for displaying data and interacting with users, while backend APIs (built with Rails) handle data operations. This clear separation allows for independent development and testing of the UI and backend, making the system more modular and manageable.
Role-Based Access Control (RBAC)
• Definition: Access to specific functionalities should be limited based on the user’s role, enhancing security and usability.
• Implementation in the Project: In the course management system, only Admins and Instructors have full CRUD permissions, while TAs are restricted from creating and deleting courses. This role-based control is implemented on the backend to ensure secure and appropriate access, preventing unauthorized actions. By enforcing these restrictions at the code level, the system maintains data security and ensures that only users with the proper permissions can perform certain actions.
Open-Closed Principle (OCP)
• Definition: Software components should be open for extension but closed for modification. This means that new functionality should be added by extending the code, not altering existing code.
• Implementation in the Project: In cases where new functionalities or roles need to be added to the course management system, the system can be extended with additional modules or classes instead of modifying existing ones. For example, if a new role with specific permissions needs to be introduced, the system could extend existing role classes or implement additional functions rather than altering the core structure. This reduces the risk of breaking existing functionality and improves code stability.
Interface Segregation Principle (ISP)
• Definition: Classes should not be forced to implement interfaces they do not use. Interfaces should be tailored to the specific needs of each role.
• Implementation in the Project: The backend API provides different levels of access and functionality based on user roles. Admins and Instructors have access to all course-related operations, while TAs have limited permissions. Instead of building a single, broad interface, role-specific methods are designed to accommodate each user type’s specific needs. For instance, functions for creating or deleting courses are inaccessible to TAs. This segregation keeps interfaces clean and focused, enhancing usability and security.
Testing with RSwag
Integration Testing
Purpose: RSwag will be used to create comprehensive integration tests for each action within the Courses controller, verifying the integrity of CRUD operations.
CRUD Operations: Integration tests will cover Create, Read, Update, and Delete actions, ensuring that each operation interacts with the database correctly and adheres to the business rules. These tests will validate that:
• Admins and Instructors can perform all CRUD actions.
• TAs have restricted access, limited to read and update operations only.
Swagger UI Integration
Purpose: Integrating RSwag with Swagger UI will provide an interactive API documentation interface for users and developers to engage with the Courses endpoints.
Functionality: Swagger UI will accurately reflect the structure of API endpoints, enabling developers to experiment with each endpoint interactively. Each endpoint will display required parameters, expected response codes, and example inputs, offering a convenient and intuitive way to understand and test API functionality.
Parameter Validation
Purpose: Validation of input parameters ensures data integrity and prevents errors due to invalid data.
Tests: Various values for endpoint parameters, such as course IDs, instructor IDs, and query strings, will be evaluated. Tests will cover scenarios including missing, incorrect, or invalid parameter types to verify that the API handles these gracefully.
Outcome: The system will return appropriate error messages and status codes if invalid data is provided, ensuring robust input validation and secure data handling.
Error Handling
Purpose: To confirm that the system provides meaningful responses to errors and handles exceptional cases gracefully.
Scenarios Tested:
• Validation Failures: Verify that endpoints return specific error messages and status codes (e.g., 400 Bad Request) when required fields are missing or invalid.
• Resource Not Found: Ensure that requests for non-existent resources return appropriate responses (e.g., 404 Not Found).
• Unauthorized Access: Validate that unauthorized actions, such as a TA trying to delete a course, result in a 403 Forbidden response.
• Server Errors: Confirm that unexpected server issues (e.g., database connectivity issues) return a 500 Internal Server Error message with an appropriate response.
Outcome: Consistent error handling will guide users with clear and descriptive messages, improving usability and debugging.
Security Testing
Purpose: To safeguard API endpoints from potential security threats, ensuring data security and system integrity.
Tests Conducted:
• SQL Injection: Validate that input fields are protected against SQL injection attacks by testing with malicious SQL code.
• Cross-Site Scripting (XSS): Ensure that user input fields are sanitized to prevent XSS attacks, which could compromise data security.
• Authentication and Authorization: Test that only authenticated users can access the Courses API and that permissions are enforced based on user roles (Admin, Instructor, TA).
• Data Leakage Prevention: Verify that sensitive data is not exposed unintentionally in API responses or error messages.
Outcome: These security tests will confirm the robustness of authentication and authorization measures, protecting the Courses API from vulnerabilities.
Documentation Verification
Purpose: To ensure that API documentation is accurate, clear, and up-to-date.
Process:
• Review Documentation: RSwag-generated documentation will be reviewed to confirm that it accurately represents the functionality of each endpoint, including parameters, expected responses, and example requests.
• Regular Updates: Documentation will be updated as new features are added or endpoints are modified, maintaining consistency with the actual API functionality.
• User-Friendliness: The documentation will include clear descriptions and examples for each endpoint, making it accessible for both technical and non-technical users.
Outcome: Up-to-date, accurate documentation will enhance usability and facilitate easier adoption of the Courses API.
Relevant Links
- Github Repository: https://github.com/yuktasree/reimplementation-back-end
Team
Mentor
- Anvitha Reddy Gutha <agutha@ncsu.edu>
Members
- Harshvardhan Sangram Patil <hspatil@ncsu.edu>
- Suraj Raghu Kumar <sraghuk@ncsu.edu>
- Yuktasree Muppala <ymuppal2@ncsu.edu>