API Reference

This section provides a comprehensive overview of the public classes, functions, and modules available in the lback framework.

Core

This file serves as the initialization point for the ‘lback_framework/lback/core’ package. It is designed to expose the fundamental building blocks and core functionalities of the Lback web framework. This package centralizes the definition and management of the framework’s internal mechanisms, including application control, request/response handling, configuration, error management, routing, and server operations.

—

Key Components Exposed by this Package:

1. AppController (from .app_controller): The central orchestrator of the Lback application. This class is responsible for managing the application lifecycle, dispatching requests to the appropriate handlers, and coordinating various framework components like middleware, routing, and response generation. It acts as the main entry point for processing incoming HTTP requests.

2. BaseMiddleware (from .base_middleware): The foundational class for all middleware components within Lback. Middleware are components that process requests and responses before or after they reach the main application logic. This base class defines the interface and common behavior for custom middleware implementations.

3. Cache, CacheItem (from .cache): Components for managing application-level caching. * Cache: Provides an interface for storing and retrieving data in a temporary,

   fast-access storage. It’s used to reduce redundant computations or database queries.

   • CacheItem: Represents a single item stored within the cache, potentially including

     metadata like expiration times.

4. Configuration Management (from .config_manager and .config): A set of utilities and classes for handling application configuration and settings. * SettingsFileHandler: Manages reading and writing application settings from configuration files. * load_config: A function to load the application’s configuration from various sources. * load_settings_module: A function to load settings from a Python module. * update_config: A function to dynamically update configuration settings. * start_settings_watcher: Initiates a process to monitor configuration files for changes. * sync_settings_to_config: Synchronizes settings from a source to the active configuration. * get_project_root: A utility function to determine the root directory of the Lback project. * Config: The main class representing the application’s configuration, holding all settings.

5. dispatcher (from .dispatcher_instance): Likely a pre-initialized instance of a signal dispatcher or event manager. This component allows different parts of the framework (and application) to communicate with each other by sending and receiving signals or events, promoting a loosely coupled architecture.

6. ErrorHandler (from .error_handler): Manages the handling and rendering of application errors and exceptions. This component intercepts unhandled exceptions, logs them, and generates appropriate error responses (e.g., custom error pages or JSON error messages) to the client.

7. Exceptions (from .exceptions): A collection of custom exception classes specific to the Lback framework. These exceptions provide more granular control over error handling and allow for specific error responses based on the type of issue encountered. * FrameworkException: Base exception for all Lback framework-specific errors. * Forbidden: Raised when a user attempts to access a resource they are not authorized for (HTTP 403). * HTTPException: Base exception for all HTTP-related errors. * BadRequest: Raised for invalid client requests (HTTP 400). * NotFound: Raised when a requested resource or URL is not found (HTTP 404). * RouteNotFound: Specifically raised when no matching route is found for a URL. * MethodNotAllowed: Raised when an unsupported HTTP method is used for a route (HTTP 405). * Unauthorized: Raised when authentication is required but has failed or not been provided (HTTP 401). * ConfigurationError: Raised for issues related to application configuration. * ValidationError: Raised when data validation fails. * ServerError: Raised for internal server errors (HTTP 500).

8. setup_logging (from .logging_setup): A function responsible for configuring the application’s logging system. It sets up loggers, handlers, and formatters to ensure that application events, errors, and debugging information are captured and stored appropriately.

9. Middleware Management (from .middleware_loader and .middleware_manager): Components for loading, creating, and managing middleware within the framework. * load_middlewares_from_config: Loads middleware definitions from the application configuration. * create_middleware: Instantiates a middleware class. * import_class: A utility function to dynamically import a Python class by its string path. * MiddlewareManager: Manages the execution order and application of multiple middleware components

   to incoming requests and outgoing responses.

   • Middleware: A class or interface representing a single middleware component.

10. Response Handling (from .response): Classes for constructing various types of HTTP responses. * RedirectResponse: Creates an HTTP redirect response. * Response: The base class for all HTTP responses. * HTMLResponse: Creates an HTTP response with HTML content. * JSONResponse: Creates an HTTP response with JSON content.

11. Routing (from .router): Components for defining and managing URL routing within the application. * Route: Represents a single route definition, mapping a URL pattern to a view handler. * Router: The central component responsible for matching incoming request URLs to the

    appropriate route and dispatching them to the corresponding view.

12. Server (from .server): Components related to running the Lback web server. * Server: The main class for the HTTP server, responsible for listening for incoming

    requests and handing them off to the application.

    • initialize_core_components: A function to initialize essential framework components

      before the server starts.

    • wsgi_application: The WSGI (Web Server Gateway Interface) application callable,

      which is the entry point for WSGI-compatible web servers.

13. SignalDispatcher (from .signals): A system for implementing signals (or events) within the framework. This allows different parts of the application to send notifications and react to them, promoting a decoupled architecture.

14. Templates (from .templates): Components for rendering HTML templates. * TemplateRenderer: The main class for rendering templates, often integrating with

    a templating engine (e.g., Jinja2).

    • default_global_context: Provides default variables or functions available

      to all templates.

    • custom_uppercase: A custom filter or function for template rendering.

    • custom_url_tag: A custom tag for generating URLs within templates.

15. Type Definitions (from .types): Custom type hints or definitions used throughout the framework for clarity and type checking. * Request: A type hint for the HTTP request object. * HTTPMethod: An enumeration or type hint for HTTP methods (GET, POST, etc.). * TypeConverter: A base class or type for URL path converters. * UploadedFile: A type hint for objects representing uploaded files. * UUIDConverter: A URL path converter specifically for UUIDs. * IntegerConverter: A URL path converter specifically for integers.

16. URL Utilities (from .urls_utils): Utilities for managing URL patterns. * Include: A function or class to include URL patterns from other modules,

    allowing for modular URL configuration.

17. WebSocketServer (from .websocket): A component for handling WebSocket communication, enabling real-time, bidirectional communication between the server and clients.

18. WSGI Entry Point (from .wsgi_entry): Utilities related to the WSGI application setup. * create_wsgi_app: A function to create the WSGI application instance. * setup_logging: A function to configure logging specifically for the WSGI environment.

Auth App

This file serves as the initialization point for the ‘lback_framework/lback/auth_app’ package. It is designed to expose the core components necessary for handling user authentication and authorization processes specifically for web-based applications within the Lback framework. This package centralizes the definition and management of user-facing authentication flows, including rendering login/registration pages and processing form submissions.

—

Key Components Exposed by this Package:

1. Web Authentication Views (from .web_auth_views): A collection of views specifically designed to render HTML pages and handle form submissions for user authentication processes in a web application context. These views manage the user interface aspects of authentication.

   • show_login_page: Renders the HTML page containing the user login form.

   • show_register_page: Renders the HTML page containing the user registration form.

   • show_reset_password_confirm_page: Renders the HTML page for users to confirm and set

     a new password after a reset request.

   • show_request_password_reset_page: Renders the HTML page where users can request a

     password reset link (e.g., by entering their email).

   • handle_login_submit: Processes the form submission from the login page, authenticates

     the user, and manages session creation.

   • handle_register_submit: Processes the form submission from the registration page,

     validates user data, and creates a new user account.

   • handle_reset_password_confirm_submit: Processes the form submission for setting a new

     password after a reset request, validating the token and new password.

   • handle_request_password_reset_submit: Processes the form submission for requesting a

     password reset, typically sending an email with a reset link.

   • verify_email_web_view: A web view to handle email verification links, confirming a user’s

     email address.

   • logout_user_view: Handles user logout requests, terminating the user’s session.

2. urlpatterns (from .urls): A list or collection of URL patterns specifically for the authentication application. These patterns map incoming HTTP requests to the appropriate web authentication views, defining the routing for all user-facing authentication functionalities (e.g., /login/, /register/, /password-reset/).

3. API Authentication Views (from .auth_views): A set of views that likely provide API endpoints for authentication functionalities, which might be consumed by client-side applications (e.g., single-page applications) or mobile apps, rather than rendering full HTML pages.

   • register_user_view: An API endpoint for user registration.

   • login_user_view: An API endpoint for user login.

   • request_password_reset_view: An API endpoint for initiating a password reset process.

   • reset_password_view: An API endpoint for completing the password reset process.

   • verify_email_view: An API endpoint for email verification.

Admin App

This file serves as the initialization point for the ‘lback_framework/lback/admin’ package. It is designed to expose the core components necessary for building and managing the administrative interface within the Lback web framework. This package centralizes the definition and management of administrative functionalities, including views for data management, an admin registry, and URL patterns for the admin site.

—

Key Components Exposed by this Package:

1. admin (from .admin): This likely refers to the main Admin class or instance that orchestrates the entire administrative site. It’s responsible for managing registered models, dispatching requests to appropriate admin views, and potentially handling global admin configurations. It acts as the central hub for the administrative interface.

2. Admin Views (from .auth_views and .generic): A collection of pre-built views designed to handle common administrative operations on data models. These views abstract away boilerplate logic for managing users, and performing CRUD operations on generic models within the admin interface.

   • admin_user_add_view: A specific view for adding new administrative users.

     This view typically handles the form submission, validation, and creation of new admin user accounts.

   • admin_user_list_view: A specific view for listing existing administrative users.

     It displays a table or list of admin users, often with options for searching, filtering, and pagination.

   • generic_add_view: A generic view for adding new instances of any registered model.

     This view provides a standardized interface for creating new records dynamically.

   • generic_list_view: A generic view for listing instances of any registered model.

     It displays a table or list of records for a given model, offering general management capabilities.

   • generic_delete_view: A generic view for deleting instances of any registered model.

     It handles the logic for removing records from the database.

   • generic_change_view: A generic view for updating existing instances of any registered model.

     This view provides an interface for modifying existing records.

   • generic_detail_view: A generic view for displaying the detailed information of a single

     instance of any registered model.

3. AdminRegistry (from .registry): A central registry where application models are registered to be managed by the administrative interface. This class keeps track of which models have an admin interface defined for them, and how they should be displayed and interacted with. It’s crucial for dynamically generating admin forms and lists.

4. urlpatterns (from .urls): A list or collection of URL patterns specifically for the admin site. These patterns map incoming HTTP requests to the appropriate admin views, defining the routing for all administrative functionalities (e.g., /admin/users/, /admin/products/add/).

5. Admin Page Views (from .views): Specific views related to the core administrative user experience, such as login, dashboard, and logout functionalities.

   • admin_login_page: The view responsible for rendering the administrative login form.

   • admin_dashboard_page: The main dashboard view displayed after a successful

     administrative login, providing an overview of the system.

   • admin_login_post: The view that handles the submission of the administrative

     login form, processing credentials and authenticating the user.

   • admin_logout_post: The view that handles administrative logout requests,

     terminating the user’s admin session.

Middleware

This file serves as the initialization point for the ‘lback_framework/lback/middlewares’ package. It is designed to expose the core components necessary for implementing various middleware functionalities within the Lback web framework. This package centralizes the definition and management of middleware that process requests and responses globally or for specific routes, enhancing application behavior for concerns like authentication, security, logging, and session management.

—

Key Components Exposed by this Package:

1. AuthMiddleware (from .auth_midlewares): A middleware component responsible for handling authentication processes. This middleware intercepts incoming requests to verify user credentials or session tokens, ensuring that only authenticated users can access protected resources. It integrates with the framework’s authentication system.

2. BodyParsingMiddleware (from .body_parsing_middleware): A middleware component designed to parse the body of incoming HTTP requests. This is crucial for handling different content types (e.g., JSON, form data, multipart/form-data for file uploads) and making the parsed data easily accessible to view functions.

3. CORSMiddleware (from .cors): A middleware component that implements Cross-Origin Resource Sharing (CORS) policies. This middleware adds appropriate HTTP headers to responses, allowing web browsers to permit cross-origin requests to the Lback application, which is essential for single-page applications (SPAs) or APIs consumed from different domains.

4. CSRFMiddleware (from .csrf): A middleware component that provides Cross-Site Request Forgery (CSRF) protection. This middleware helps prevent malicious attacks where unauthorized commands are transmitted from a user that the web application trusts. It typically involves generating and validating CSRF tokens.

5. DebugMiddleware (from .debug): A middleware component that provides debugging functionalities, typically active only in development environments. This might include displaying detailed error messages, logging request/response information, or providing tools for inspecting application state during development.

6. LoggingMiddleware (from .logger): A middleware component responsible for logging incoming requests and outgoing responses. This middleware captures information such as request method, URL, status code, and response time, providing valuable data for monitoring and debugging the application.

7. MediaFilesMiddleware (from .media_files_middleware): A middleware component for serving user-uploaded media files. This middleware handles requests for files stored outside the static files directory, typically in a designated media folder, ensuring they are served correctly by the application.

8. Security Middlewares (from .security_middleware): A collection of middleware components focused on enhancing the application’s security posture.

   • SecurityHeadersConfigurator: A utility or class for configuring various security-related

     HTTP headers (e.g., X-Content-Type-Options, X-Frame-Options, Content-Security-Policy).

   • SecurityHeadersMiddleware: Applies the configured security headers to all outgoing responses,

     mitigating common web vulnerabilities.

   • SQLInjectionDetectionMiddleware: A middleware specifically designed to detect and potentially

     prevent SQL injection attempts by analyzing incoming request data for malicious patterns.

   • SQLInjectionProtection: A utility or class that provides the core logic for SQL injection

     protection, often used by the detection middleware.

9. SessionMiddleware (from .session_middleware): A middleware component that enables session management for the application. This middleware establishes and maintains user sessions across multiple requests, allowing the application to store and retrieve user-specific data (e.g., login status, shopping cart contents) between interactions.

10. SQLAlchemySessionMiddleware (from .sqlalchemy_middleware): A middleware component specifically for integrating SQLAlchemy sessions with the request lifecycle. This middleware typically manages the creation, usage, and closing of database sessions for each incoming request, ensuring proper database connection management.

11. StaticFilesMiddleware (from .static_files_middleware): A middleware component for serving static assets (e.g., CSS, JavaScript, images) directly from the application. This middleware intercepts requests for static files and serves them efficiently, typically in development environments, before a production web server takes over.

12. TimerMiddleware (from .timer): A middleware component designed to measure and log the time taken to process each request. This middleware can be useful for performance monitoring and identifying bottlenecks in the application’s request-response cycle.

Authentication

This file serves as the initialization point for the ‘lback_framework/lback/auth’ package. It is designed to expose the core components necessary for handling various authentication and authorization mechanisms within the Lback web framework. This package centralizes the definition and management of security-related functionalities, including different authentication schemes, password management, and permission enforcement.

—

Key Components Exposed by this Package:

1. SessionAuth (from .session_auth): Manages session-based authentication for users. This component is typically responsible for creating and managing user sessions, storing session data (e.g., user ID) on the server and providing a session ID to the client (often via cookies). It handles login, logout, and session validation to maintain user state across requests.

2. PermissionRequired (from .permissions): A decorator or utility class used to enforce permissions on views or specific actions. This component ensures that only users with the necessary permissions are allowed to access certain resources or perform specific operations. It integrates with the authentication system to check a user’s assigned roles or permissions.

3. PasswordHasher (from .password_hashing): Provides utilities for securely hashing and verifying user passwords. This component is critical for protecting sensitive user credentials by converting plain-text passwords into irreversible hash values before storage, and then securely comparing them during login attempts without exposing the original password. It typically supports various hashing algorithms.

4. OAuth2Auth (from .oauth): Implements support for the OAuth 2.0 authorization framework. This component enables Lback applications to integrate with external identity providers (e.g., Google, Facebook) for user authentication and authorization, allowing users to grant limited access to their data without sharing their credentials directly with the application.

5. JWTAuth (from .jwt_auth): Implements JSON Web Token (JWT) based authentication. This component handles the creation, signing, and validation of JWTs, which are commonly used for stateless authentication in APIs. It allows users to obtain a token upon successful login, which they then include in subsequent requests to prove their identity without needing to re-authenticate with each request.

6. AdminAuth (from .adminauth): Specifically handles authentication logic for the administrative interface. This component might extend or specialize the general authentication mechanisms to cater to the unique requirements of admin users, potentially including stricter security policies or different login flows for administrative access.

Forms

This file serves as the initialization point for the ‘lback_framework/lback/forms’ package. It is designed to expose the core components necessary for building, validating, and rendering web forms within the Lback web framework. This package centralizes the definition and management of form fields, form classes, validation mechanisms, and various input widgets, providing a comprehensive system for handling user input.

—

Key Components Exposed by this Package:

1. Date and Time Fields (from .fields_datetime): A collection of specialized form fields designed to handle date and time input.

   • DateTimeField: A form field for capturing both date and time values. It handles

     parsing and formatting of datetime strings.

   • TimeField: A form field specifically for capturing time values.

   • DateField: A form field specifically for capturing date values.

2. File Fields (from .fields_file): A form field dedicated to handling file uploads.

   • FileField: A form field for allowing users to upload files. It manages file

     data and provides mechanisms for validation and storage.

3. Basic Form Fields (from .fields): A set of fundamental form fields for common data types.

   • BooleanField: A form field for capturing boolean (True/False) input, typically

     rendered as a checkbox.

   • CharField: A form field for capturing single-line text input, suitable for

     names, titles, or short descriptions.

   • ChoiceField: A form field that allows users to select one option from a predefined

     set of choices, often rendered as a dropdown (<select>) or radio buttons.

   • EmailField: A specialized form field for capturing email addresses, typically

     including built-in validation for email format.

   • IntegerField: A form field for capturing integer (whole number) input.

4. Form Classes (from .forms): The core classes for defining and managing forms.

   • Form: The base class for creating web forms. It orchestrates the collection of

     fields, handles data binding, and manages the overall validation process for user input.

   • FormMetaclass: The metaclass used by the Form class, responsible for processing

     field definitions when a form class is created.

5. ModelForm (from .models): A specialized form class designed to work directly with Lback’s database models.

   • ModelForm: A form class that automatically generates form fields based on a

     given database model’s fields. It simplifies the process of creating forms for creating or updating model instances, often handling validation and saving to the database.

6. Validation (from .validation): Components for handling form and field validation errors.

   • ValidationError: A custom exception or class used to signal that form or field

     validation has failed. It typically carries messages detailing the specific validation issues.

7. Date and Time Widgets (from .widgets_datetime): HTML input widgets specifically designed for date and time fields.

   • DateInput: A widget for rendering a date input field in HTML, often using

     type=”date” for native browser date pickers.

   • DateTimeInput: A widget for rendering a datetime input field in HTML, often

     using type=”datetime-local” or similar.

   • TextInput: A generic text input widget, which might be used as a fallback

     or for custom date/time string input.

8. File Widgets (from .widgets_file): An HTML input widget for file uploads.

   • FileInput: A widget for rendering a file upload input field in HTML (<input type=”file”>).

9. Basic Widgets (from .widgets): Common HTML input widgets for various form fields.

   • TextInput: A widget for rendering a standard single-line text input field (<input type=”text”>).

   • Textarea: A widget for rendering a multi-line text input area (<textarea>).

   • PasswordInput: A widget for rendering a password input field (<input type=”password”>),

     masking the input for security.

   • CheckboxInput: A widget for rendering a checkbox input field (<input type=”checkbox”>).

   • Select: A widget for rendering a dropdown list (<select>) for choice fields.

Models

This file serves as the initialization point for the ‘lback_framework/lback/models’ package. It is designed to expose the core components necessary for defining and managing the application’s data models within the Lback web framework. This package centralizes the definition of database schemas, relationships between entities, and provides utilities for interacting with the underlying database.

—

Key Components Exposed by this Package:

1. AdminUser, Role, Permission (from .adminuser): These classes define the data models related to the administrative users and their access control within the application.

   • AdminUser: Represents an administrative user account, typically with elevated

     privileges for managing the application’s backend.

   • Role: Defines a specific role that can be assigned to users (e.g., ‘admin’, ‘editor’).

     Roles are used to group permissions and simplify access control management.

   • Permission: Represents a specific action or resource that a user can be

     granted access to (e.g., ‘can_edit_products’, ‘can_view_reports’).

2. BaseModel (from .base): The foundational base class for all data models within the Lback framework. This class typically provides common functionalities and attributes that all models share, such as primary key definitions, timestamp fields (created_at, updated_at), and potentially methods for common database operations.

3. DatabaseManager (from .database): A component responsible for managing the database connection and session lifecycle. This class typically handles the initialization of the database engine, creation of database sessions, and other low-level database interactions, providing a centralized point for database access.

4. Product (from .product): A specific data model representing a product within the application. This class defines the schema for product-related data, such as name, description, price, and other relevant attributes. It’s an example of an application-specific model.

5. Session (from .session): A data model representing a user’s session. This class is used to store and manage session-specific data on the server side, enabling the application to maintain user state across multiple requests (e.g., login status, shopping cart).

6. User, Group, UserPermission (from .user): These classes define the data models related to standard application users and their access control.

   • User: Represents a general user account within the application.

   • Group: Defines a group that users can belong to, often used to assign

     permissions or roles to multiple users collectively.

   • UserPermission: Represents a direct permission granted to a specific user,

     allowing for fine-grained access control beyond roles or groups.

API

This file serves as the initialization point for the ‘lback_framework/lback/api’ package. It is designed to expose the core components necessary for building robust RESTful APIs within the Lback web framework. This package centralizes the definition and management of API functionalities, including views, serializers, mixins, and documentation tools.

—

Key Components Exposed by this Package:

1. APIDocs: Manages and generates comprehensive API documentation for the Lback framework. This component is crucial for creating structured and interactive documentation (e.g., OpenAPI/Swagger specifications) that details all available API endpoints, their expected request formats, and their response structures. It aids developers in understanding and integrating with Lback-powered APIs by providing metadata like API title, version, and description, and can register endpoints for automatic documentation generation.

2. Generic API Views (from .generics): A suite of pre-built, reusable classes designed to handle common RESTful operations (CRUD - Create, Read, Update, Delete) with minimal boilerplate code. These views abstract away repetitive logic, allowing for rapid API development.

   • GenericAPIView: The foundational class for all generic API views, providing core mechanisms for

     handling HTTP requests, interacting with serializers, and managing querysets.

   • ListAPIView: Designed for retrieving collections of resources, handling HTTP GET requests

     for listing multiple instances of a model, often with pagination and filtering support.

   • CreateAPIView: Handles HTTP POST requests for creating new resources, deserializing incoming data,

     validating it, and saving new model instances.

   • RetrieveAPIView: Processes HTTP GET requests for fetching a single resource instance,

     typically identified by a primary key or unique identifier.

   • UpdateAPIView: Supports HTTP PUT (full update) and PATCH (partial update) requests for

     modifying existing resources.

   • DestroyAPIView: Handles HTTP DELETE requests for removing existing resource instances.

   • ListCreateAPIView: A composite view combining listing (GET) and creation (POST) functionalities

     on the same endpoint.

   • RetrieveUpdateDestroyAPIView: A comprehensive view for single-resource management,

     combining retrieval (GET), updating (PUT/PATCH), and deletion (DELETE).

3. Mixins (from .mixins): Reusable classes that provide specific behaviors to generic views, allowing for flexible composition of API functionalities. These mixins encapsulate common logic for model operations.

   • ListModelMixin: Provides logic for listing a queryset of model instances.

   • CreateModelMixin: Provides logic for creating a new model instance.

   • RetrieveModelMixin: Provides logic for retrieving a single model instance.

   • UpdateModelMixin: Provides logic for updating an existing model instance.

   • DestroyModelMixin: Provides logic for deleting a model instance.

4. Serializers (from .serializer): Essential components for data serialization and deserialization. They are crucial for converting complex data types (like model instances) into formats suitable for API responses (e.g., JSON) and converting incoming data back into model instances for processing.

   • Field: The base class for all serializer fields, defining common behavior for data representation,

     validation, and conversion.

   • BooleanField: A serializer field for handling boolean values.

   • BaseModelSerializer: The base serializer class designed for integration with Lback’s models,

     simplifying conversion between model instances and serializable data structures.

   • IntegerField: A serializer field for handling integer numbers.

   • StringField: A serializer field for handling text-based data (strings).

   • RelatedField: A serializer field for representing relationships between different models.

   • DateTimeField: A serializer field for handling date and time values, managing conversion

     to and from various string formats.

5. View Classes (from .view): Fundamental view classes that serve as the entry points for handling web requests within the Lback framework.

   • APIView: The primary base class for defining API views, providing a robust foundation for handling

     different HTTP methods and orchestrating the request-response cycle for API endpoints.

   • BaseView: A more general-purpose base view class that might serve as a fundamental building block

     for views not strictly adhering to REST principles, or for traditional web page rendering.

Utilities

This file serves as the initialization point for the ‘lback_framework/lback/utils’ package. It is designed to expose a collection of various utility functions and helper classes that are commonly used across different parts of the Lback web framework. This package centralizes general-purpose functionalities that do not fit neatly into other specific framework components, enhancing code reusability and simplifying common development tasks.

—

Key Components Exposed by this Package:

1. AdminUserManager (from .admin_user_manager): A utility class specifically designed for managing administrative user accounts. This component provides helper methods for common operations related to admin users, such as creating, retrieving, updating, or deleting admin user records, potentially integrating with the AdminUserRepository.

2. AppSession (from .app_session): A utility or class for managing application-specific session data. This might be a higher-level abstraction over the core session management, providing convenient methods for storing and retrieving data relevant to the current user’s application session.

3. EmailSender (from .email_sender): A utility class or function for sending emails from the application. This component abstracts away the complexities of configuring and interacting with email servers, providing a simple interface for sending various types of emails (e.g., password resets, notifications).

4. File Handlers (from .file_handlers): A set of utility functions for handling file operations, particularly related to uploaded files.

   • validate_uploaded_file: A function to validate properties of an uploaded file,

     such as its size, type, or allowed extensions, before saving.

   • save_uploaded_file: A function to securely save an uploaded file to a specified

     location on the server’s file system.

   • delete_saved_file: A function to remove a previously saved file from the server.

5. Filters (from .filters): A collection of utility functions that can be used for filtering or transforming data.

   • file_extension_filter: A filter to process or validate file extensions.

   • split_filter: A filter to split strings based on a delimiter.

   • date_filter: A filter to format or parse date values.

6. Response Helpers (from .response_helpers): Utility functions that simplify the creation of common HTTP responses.

   • json_response: A helper function to quickly create and return an HTTP response

     with JSON content, setting appropriate headers.

7. SessionManager (from .session_manager): A utility class for lower-level management of user sessions. This component might handle the creation, retrieval, updating, and deletion of session data, interacting directly with the session storage mechanism.

8. Shortcuts (from .shortcuts): A collection of convenience functions designed to simplify common tasks in views or other parts of the application, reducing boilerplate code.

   • render: A shortcut function to render an HTML template and return an HTMLResponse.

   • redirect: A shortcut function to create an HTTP redirect response.

   • return_403: A shortcut to return an HTTP 403 Forbidden response.

   • return_404: A shortcut to return an HTTP 404 Not Found response.

   • return_500: A shortcut to return an HTTP 500 Internal Server Error response.

   • _get_model_form_data: A private or internal helper to extract form data related to a model.

   • paginate_query: A helper to paginate a database query result.

   • json_response: (Duplicated, likely for direct import convenience) A shortcut to return a JSON response.

9. Static Files (from .static_files): Utilities for managing and serving static assets.

   • static: A function to generate URLs for static files.

   • find_static_file: A function to locate a static file within the project’s static directories.

10. URL Utilities (from .urls): Utilities related to URL pattern definition.

    • path: A function for defining individual URL routes, mapping a URL pattern to a view.

11. UserManager (from .user_manager): A utility class specifically designed for managing standard user accounts. This component provides helper methods for common operations related to users, such as creating, retrieving, updating, or deleting user records, potentially integrating with the UserRepository.

12. Validation (from .validation): Components for general data validation beyond form-specific validation.

    • ValidationError: A custom exception or class used to signal that validation has failed.

    • PasswordValidator: A utility class or function for validating password strength and complexity.

    • validate_json: A function to validate if a given string is valid JSON or conforms to a schema.

Commands

This file serves as the initialization point for the ‘lback_framework/lback/commands’ package. It is designed to expose the core components necessary for executing various command-line utilities and management tasks within the Lback web framework. This package centralizes the definition and management of administrative and development-related commands, allowing developers to interact with the framework from the terminal.

—

Key Components Exposed by this Package:

1. AdminCommands (from .admin): A collection of command-line utilities specifically designed for administrative tasks. These commands typically facilitate the management of the Lback admin interface, such as creating superusers, managing admin configurations, or performing other admin-specific operations from the terminal.

2. AppCommands (from .app): A set of command-line utilities related to managing individual applications or modules within the Lback project. These commands might include functionalities for creating new app templates, managing app-specific configurations, or performing operations relevant to the lifecycle of an application.

3. setup_database_and_defaults (from .db_seed): A function or utility responsible for seeding the database with initial data or default configurations. This command is crucial for setting up a fresh development environment or for populating a database with essential data required for the application to function correctly (e.g., default user roles, initial settings).

4. MigrationCommands (from .migration): A collection of command-line utilities for managing database schema migrations. These commands typically integrate with a migration tool (like Alembic) to create new migration scripts, apply pending migrations to the database, or revert previous migrations, ensuring database schema changes are managed in a version-controlled manner.

5. ProjectCommands (from .project): A set of command-line utilities related to managing the overall Lback project. These commands might include functionalities for initializing a new Lback project, setting up project-wide configurations, or performing operations relevant to the entire project’s structure and environment.

6. RunnerCommands (from .runner): A collection of command-line utilities for running the Lback application or specific development servers. This typically includes commands to start the development server, run tests, or execute other processes necessary for developing and deploying the Lback application.

Repositories

This file serves as the initialization point for the ‘lback_framework/lback/repositories’ package. It is designed to expose the core components necessary for implementing the repository pattern within the Lback web framework. This package centralizes the definition and management of data access logic, providing an abstraction layer over the database for specific models. It encapsulates the mechanisms for retrieving, storing, and querying data, promoting a clean separation of concerns between the application’s business logic and data persistence.

—

Key Components Exposed by this Package:

1. AdminUserRepository (from .admin_user_repository): A repository class specifically designed for interacting with AdminUser data. This component provides methods for performing CRUD (Create, Read, Update, Delete) operations on administrative user records, abstracting away the direct database interactions for AdminUser models. It might include specialized queries relevant to admin user management.

2. PermissionRepository (from .permission_repository): A repository class dedicated to managing Permission data. This component offers methods for accessing, creating, updating, and deleting permission records. It ensures that permission-related database operations are handled consistently and efficiently, supporting the application’s authorization system.

3. RoleRepository (from .role_repository): A repository class focused on handling Role data. This component provides methods for performing CRUD operations on role records, which are used to group permissions and assign them to users. It centralizes the data access logic for roles, supporting the role-based access control (RBAC) system.

4. UserRepository (from .user_repository): A repository class specifically designed for interacting with standard User data. This component provides methods for performing CRUD operations on general user records, abstracting away the direct database interactions for User models. It might include specialized queries for user authentication, profile management, or other user-centric operations.

Security

This file serves as the initialization point for the ‘lback_framework/lback/security’ package. It is designed to expose the core components necessary for implementing various security measures and protections within the Lback web framework. This package centralizes the definition and management of security-related functionalities, including firewall rules, HTTP security headers, rate limiting, and protection against SQL injection, ensuring the application’s robustness against common web vulnerabilities.

—

Key Components Exposed by this Package:

1. AdvancedFirewall (from .firewall): A component that provides advanced firewall capabilities for the Lback application. This class is responsible for defining and enforcing security rules at the network or application level, controlling access to resources based on various criteria such as IP addresses, request patterns, or user roles. It helps in preventing unauthorized access and mitigating denial-of-service (DoS) attacks.

2. SecurityHeadersConfigurator (from .headers): A utility or class for configuring and applying various HTTP security headers to outgoing responses. This component helps to protect the application against a range of client-side attacks (e.g., XSS, clickjacking) by instructing browsers on how to behave when interacting with the application’s content. Examples of headers include Content-Security-Policy (CSP), X-Frame-Options, and X-Content-Type-Options.

3. RateLimiter (from .rate_limiter): A component that implements rate limiting functionality. This class is used to control the number of requests a client can make to the server within a given timeframe. It helps in preventing abuse, brute-force attacks, and resource exhaustion by limiting the frequency of requests from a single source.

4. SQLInjectionProtection (from .sql_injection): A component dedicated to providing protection against SQL injection vulnerabilities. This class implements mechanisms (e.g., input sanitization, parameterized queries, or pattern detection) to prevent malicious SQL code from being injected into database queries through user input, thereby safeguarding the integrity and confidentiality of the application’s data.