Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Tenant specific config support via .cac.toml #246

Merged
merged 1 commit into from
Sep 30, 2024
Merged

Conversation

ayushjain17
Copy link
Collaborator

Problem

Tenant specific configuration not present

Solution

Get tenant-config via cac using cac_toml which reads Superposition.cac.toml

@@ -17,4 +17,4 @@ path = "src/bin.rs"
clap = { version = "4.3.0", features = ["derive"] }
pest = "2.6"
pest_derive = "2.6"
toml = { version = "0.8.8", features = ["preserve_order"] }
toml = { workspace = true }
Copy link
Collaborator

@knutties knutties Sep 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ayushjain17 - Will this pick-up the preserve_order if someone just includes cac_toml outside of this workspace? Could we validate that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes this will set the features for the crate, in the same way it is specified in the workspace Cargo.toml
have verified this

Copy link
Collaborator

@Datron Datron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if we can avoid the type ceremony regarding TenantConfig being a trait. Else this is fine

@@ -257,6 +257,46 @@ impl Display for RegexEnum {
}
}

pub trait SuperpositionTenantConfig {
Copy link
Collaborator

@Datron Datron Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be a struct with pub members right? Why define tenant config as a trait behaviour? No one can implement this elsewhere and pass it around. Why are we making it generic? Note: If the answer summarizes to "We will need this in the future", my response is "lets add it in the future". This is unecessary code complexity right now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this is because of internal asks for auth? The tenant config struct internal to Juspay will be different I'm assuming

@@ -64,69 +48,16 @@ async fn main() -> Result<()> {
prefix => "/".to_owned() + prefix,
};

let cac_host: String = get_from_env_unsafe("CAC_HOST").expect("CAC host is not set");
let cac_port: u16 = get_from_env_unsafe("PORT").unwrap_or(8080);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we needed this

@Datron Datron self-requested a review September 27, 2024 06:47
@Datron Datron self-requested a review September 27, 2024 07:25
@ayushjain17 ayushjain17 force-pushed the tenantConfig branch 4 times, most recently from d223128 to 008b169 Compare September 27, 2024 14:15
.wrap_fn(|req, srv| {
let user = User::default();
let state = req.app_data::<Data<AppState>>().unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ayushjain17 , can you explain why this change is needed?

@@ -234,30 +244,48 @@ async fn create(
// creating variants' context in CAC
let http_client = reqwest::Client::new();
let url = state.cac_host.clone() + "/context/bulk-operations";
let headers_map = construct_header_map(tenant.as_str(), custom_headers.config_tags)?;
let user_str = serde_json::to_string(&user).map_err(|err| {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are we trying to achieve with x-user header?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someone who has access for only making changes in experimentation and not in context-aware-config, for them all requests of experimenation would start failing as the when these api calls would be made to make changes in context-aware-config, the authorization would fail due to lack of access.

So Internal authorization has been added
Now since this Internal auth would not have the details of the current user, and on validating it would give the details of a super-user then the audit logs would show wrong info regarding the maker of the contexts in context-aware-config, so in this case since experimentation has already decoded the user, it just forwards the user data

And this user data is only to be consumed if the Internal auth check is successful

@Datron Datron self-requested a review September 30, 2024 06:52
Copy link
Collaborator

@Datron Datron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

want to understand Authorization internal before approving

"Authorization",
format!("{} {}", user.get_auth_type(), user.get_auth_token()),
header::AUTHORIZATION,
format!("Internal {}", state.superposition_token),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is internal auth?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

@ShubhranshuSanjeev ShubhranshuSanjeev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restrict the internal token access to be only used by experimentation platform and also that this token should not have the full access, just access to CRUD of contexts/overrides will work?

Copy link
Collaborator

@Datron Datron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nitpicks and optimizations, not a PR blocker

None
}
})
.collect::<Vec<_>>();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: specify types here, makes it easy to read on a glance

@@ -371,6 +399,16 @@ pub async fn conclude(
};
operations.push(ContextAction::MOVE((context_id, context_move_req)));
} else {
let user_str = serde_json::to_string(&user).map_err(|err| {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to send the whole user object in the headers or only the email address?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whole user, as what all data would be needed later on the context api or which api being called would not be known

@ayushjain17 ayushjain17 merged commit ffc247e into main Sep 30, 2024
4 checks passed
@ayushjain17 ayushjain17 deleted the tenantConfig branch September 30, 2024 10:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants