feat: core rpc cookie#189
Conversation
WalkthroughThis changeset introduces several functions to enhance directory path handling and authentication logic. A new generic function for obtaining user data directory paths and a specific function for DashCore have been added. The cookie path is now dynamically generated based on network type and optional development network name. Additionally, the logic for retrieving chain locks in the backend task is refactored and consolidated in a new method. Changes in provider initialization now include a network parameter and a cookie-based authentication flow with a fallback to user/password handling. Changes
Sequence Diagram(s)sequenceDiagram
participant C as Caller
participant P as Provider
participant F as Filesystem (Cookie)
participant S as Config Source
C->>P: Initialize Provider with network & config
P->>F: Retrieve cookie via core_cookie_path
alt Cookie exists and valid
F-->>P: Return cookie data
P->>P: Parse cookie and create Client with cookie auth
else Cookie missing/invalid
F-->>P: Return error/not found
P->>S: Retrieve user/password from config
P->>P: Create Client with user/password auth
end
P-->>C: Return initialized Client
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/app_dir.rs (1)
46-57: Handle potential panic in network matching.The function uses
unimplemented!()for unknown network types, which could cause a runtime panic.Consider handling all possible network variants to avoid runtime panics:
pub fn core_cookie_path(network: Network, devnet_name: &Option<String>) -> Result<PathBuf, std::io::Error> { core_user_data_dir_path().map(|path| { let network_dir = match network { Network::Dash => "", Network::Testnet => "testnet3", Network::Devnet => devnet_name.as_deref().unwrap_or(""), Network::Regtest => "regtest", - _ => unimplemented!(), + _ => { + tracing::warn!("Unsupported network type: {:?}", network); + "" + }, }; path.join(network_dir).join(".cookie") }) }src/context_provider.rs (1)
25-47: Add validation for cookie file content.The cookie parsing assumes the file contains exactly one colon separator, but there's no validation or error handling for malformed cookies.
Consider adding validation for the cookie format:
let (user, pass) = if let Ok(cookie) = cookie { // split the cookie at ":", first part is user (__cookie__), second part is password let cookie_parts: Vec<&str> = cookie.split(':').collect(); - let user = cookie_parts[0]; - let password = cookie_parts[1]; - (user.to_string(), password.to_string()) + if cookie_parts.len() == 2 { + let user = cookie_parts[0]; + let password = cookie_parts[1]; + (user.to_string(), password.to_string()) + } else { + tracing::warn!("Malformed cookie file: expected format 'user:password'"); + ( + config.core_rpc_user.clone(), + config.core_rpc_password.clone(), + ) + } } else { // Fall back to the pre-set user / pass if needed ( config.core_rpc_user.clone(), config.core_rpc_password.clone(), ) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/app_dir.rs(1 hunks)src/backend_task/core/mod.rs(3 hunks)src/context.rs(3 hunks)src/context_provider.rs(2 hunks)
🔇 Additional comments (7)
src/app_dir.rs (2)
12-20: Good abstraction of directory path logic.The creation of a generic
user_data_dir_pathfunction improves code reusability and maintains consistent directory path resolution across the application.
26-44: Appropriate platform-specific directory handling.The implementation correctly handles platform differences, especially for Linux where
.dashcoreis in the home directory, while using the standard application directories for other platforms.src/context.rs (3)
1-1: Appropriate import of the new directory utility functions.The import correctly references the new functions added to the app_dir module.
74-74: Updated Provider initialization with network parameter.The Provider::new call now correctly includes the network parameter, aligning with the updated method signature.
90-109: Well-structured cookie authentication with fallback.The implementation follows a good pattern: attempt cookie authentication first, then fall back to user/password if that fails. The error message is informative and helps with debugging.
src/backend_task/core/mod.rs (2)
97-139: Good refactoring for chain lock retrieval.The creation of a centralized
get_best_chain_lockmethod reduces code duplication and improves maintainability. The error handling is comprehensive and provides detailed messages.The same cookie validation suggestion applies here as in the context_provider.rs file regarding potential malformed cookie files.
60-65: Clean implementation of chain lock retrieval.The code now uses the new
get_best_chain_lockmethod in a clean and readable way, passing the appropriate network configurations.
This PR implements a change in behavior where cookie authentication with dash core will be the default attempted configuration.
When dash core is launched with RPC on, but w/o a user/pw combo it will use cookie authentication by default. Where the cookie is placed in core's directory. As long as DET can read this cookie it can use it.
This branch changes the default behavior to always try cookie auth, but doesn't change any of the setup process, so the vast majority of users will still use user/pw auth.
Summary by CodeRabbit
New Features
Refactor