-
Notifications
You must be signed in to change notification settings - Fork 72
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
Mailchimp Transactional Consent Connector [#2150] #2194
Mailchimp Transactional Consent Connector [#2150] #2194
Conversation
…r transactional api requests. Update saas_connector.run_consent_request to select the appropriate opt_in or opt out request depending on whether the consent preference is opt in or opt out. There is ongoing work to update that consent preferences will have an exectuable flag on them, and only one will be executable. For now to test, set executable to false for two preferences.
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.
No tests yet, still mulling over some details, but this demonstrates making a consent request to the mailchimp transactional API
src/fides/api/ops/service/authentication/authentication_strategy_api_key.py
Show resolved
Hide resolved
… connector. It's different enough to warrant it's own connector. There are different ways on authenticating the request, different domains, different credentials for this connector.
…equests. Remove stubbed test_consent_request now that the saas connector is wired to make real requests.
…single opt in or single opt out request instead of a list of opt-in or opt-out. A lot of this is subject to change, so let's just the simplest case working for Mailchimp Transactional and then survey the landscape more broadly.
…request is opt in/opt out, etc.
consent_requests: | ||
opt_in: | ||
method: POST | ||
path: /allowlists/add | ||
body: | | ||
{ | ||
"email": "<email>" | ||
} | ||
|
||
opt_out: | ||
method: POST | ||
path: /allowlists/delete | ||
body: | | ||
{ | ||
"email": "<email>" | ||
} |
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.
Format taken from here: #2144 (comment), except I'm making an opt_in/opt_out distinction. This is just a tentative format to have something to demonstrate, I need to do a more broad survey in #2144.
Right now (design decision by Neville) the Privacy Center will restrict so only one consent preference can be considered executable at any given time, so by the time this gets to consent request execution, there will be at most one consent preference, with opt-in or opt-out that we will fire accordingly.
There is currently no logic linking which requests are made for which types of data uses / purposes of processing, but this is part of a broader discussion about where this should happen between multiple teams.
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 like the opt_in/opt_out distinction, it makes the purpose of these requests very clear
dataset: | ||
- fides_key: <instance_fides_key> | ||
name: Mailchimp Transactional Dataset | ||
description: A sample dataset representing the Mailchimp Transactional connector for Fides | ||
collections: [] |
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.
Placeholder dataset for now, as we don't yet have a need for collections to be defined, although this is subject to change.
connector_params: | ||
- name: domain | ||
default_value: mandrillapp.com/api/1.0 | ||
- name: api_key | ||
|
||
client_config: | ||
protocol: https | ||
host: <domain> | ||
authentication: | ||
strategy: api_key | ||
configuration: | ||
body: | | ||
{ | ||
"key": "<api_key>" | ||
} |
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.
Making Mailchimp Transactional
a separate connector as it is a separate Mailchimp addon. Mailchimp purchased Mandrill, and the connector params and client config and test calls are different than the base mailchimp connector.
if self.body: | ||
body_with_api_key: Optional[str] = assign_placeholders( | ||
self.body, secrets or {} | ||
) | ||
api_key_request_body: Dict = json.loads(body_with_api_key or "{}") | ||
|
||
original_request_body: Dict = json.loads(request.body or "{}") | ||
original_request_body.update(api_key_request_body) | ||
|
||
request.prepare_body( | ||
data=json.dumps(original_request_body), files=None, json=True | ||
) |
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 added this logic here to take the original request body and add an API key to it if specified in the saas config.
I suspect I'd run into issues if the original request body wasn't json, but I think we're building json bodies generally in saas connectors?
Mailchimp Transactional connector adds API keys to the request body. Alternatively, I could put the <api_key> in the body directly in the opt in and opt out requests (this was in the original draft), so this isn't needed, but it seemed like I should separate out what was the authentication piece.
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.
This makes sense, we originally didn't implement the body because we had concerns about how an authentication body would merge with a request body but it's good to see this working as expected here.
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.
agreed, i like this implementation!
argh |
tests/ops/integration_tests/saas/test_mailchimp_transactional_task.py
Outdated
Show resolved
Hide resolved
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.
@pattisdr really nice work! it all looks solid to me, don't think i have any comments on the application code itself. i'm sure we'll need to adjust as we go a bit, but this is a great start!
just a few relatively minor nits within the tests.
Thanks so much @adamsachs and @galvana for your comments here |
…ion test that opt-out consent request has removed the user from the allowlist
…connector # Conflicts: # tests/ops/conftest.py
Add logging for executable consent options.
Failing ctl-external tests unrelated. Turned on the saas tests, verified mailchimp transactional tests working here. |
Closes #2150
👉 Note this is against the
consent-propagation
branch not main!Code Changes
consent_requests
top-level header to saas configs - currently a singleopt_in
request and/oropt_out
request can be defined. Subject to change as we generalize to other connectors.saas
connector that has the ability to make consent requests by adding or removing users from theallowlist
ApiKeyAuthenticationStrategy
to place anapi_key
in the request body in addition to the already supported query params or headerssaas_connector.run_consent_request
to be able to pull either theopt-in
oropt-out
request off of the saas config and fire. We are separately adding restrictions that only one consent preference will be passed to the Privacy Request as "executable" to start.Steps to Confirm
config.json
, set bothadvertising
andimprove
executable fields tofalse
, leaving onlyadvertising.first_party
as something that is executable. Allison is further refining executable logic here but this will work for nownox -s test_env
Mailchimp Transactional
connector. You'll need an API key.completed
statusPre-Merge Checklist
CHANGELOG.md
Description Of Changes
Add the ability for the SaaS Connector Framework to make
consent
requests, and demonstrate this end to end in the form of aMailchimp Transactional
connector.The saas config format is very early and subject to change as we need to generalize to connect to more services.