-
Notifications
You must be signed in to change notification settings - Fork 4
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
Split get_accessory_data to avoid mixing secrets, headers, etc. #74
base: main
Are you sure you want to change the base?
Conversation
5849e2f
to
a8dd2eb
Compare
@@ -1,6 +1,6 @@ | |||
[package] | |||
name = "plaid_stl" | |||
version = "0.14.2" | |||
version = "0.16.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently would be 15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's see if we merge this one of the DB size limit first.
@@ -260,7 +260,10 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> { | |||
let message = Message { | |||
type_: name.to_string(), | |||
data: String::new().into_bytes(), | |||
accessory_data: query.into_iter().map(|(k, v)| (k, v.into_bytes())).collect(), | |||
accessory_data: HashMap::new(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this break deserialization of previous messages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. In the sense that whatever is given as query params ends up in the query_params
field of the Message
, while the accessory_data
remains empty (for now). Then it's up to the rule to know that data has to be read differently. So yes, in that sense this is a breaking change. And same for secrets
and headers
.
3da2435
to
5109e91
Compare
The current situation is that secrets, headers (for POST requests) and query params (for GET requests) end up in "accessory data".
The code avoids security issues by making sure that secrets are added last, thus overwriting headers/params with the same name. However, this remains error prone and prevents us from having things with the same name.
This PR splits this additional data into
Each has their getter method, generated through macros (since it's the same exact thing for all of them).
Also adding tests that show that
Existing tests have been updated.
Breaking changes
! Existing rules need to be changed !
Usually rules are getting either secrets or headers from accessory data. One has to go through all the rules and replace that call with
get_headers
orget_secrets
, as appropriate.