-
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
[Backend] Track Privacy Experience that surfaced Notices/ Pull data from request headers #3311
Conversation
Passing run #2046 ↗︎
Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #3311 +/- ##
==========================================
+ Coverage 87.06% 87.09% +0.02%
==========================================
Files 309 309
Lines 18847 18898 +51
Branches 2467 2472 +5
==========================================
+ Hits 16410 16459 +49
- Misses 1996 1997 +1
- Partials 441 442 +1
☔ View full report in Codecov by Sentry. |
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.
okay I think I'm following, so the flow from the fides-js
side would be:
- query for
/privacy-experience
which will give us an obj with the experience config and all notices. it will also containprivacy_experience_history_id
and within the experience config,experience_config_history_id
- When the user saves, we should send a payload that includes
{
method: 'button' | 'individual notice' | 'gpc' // any string, but maybe these cover them for now?
privacy_experience_history_id: 'string from /privacy-experience'
privacy_experience_config_history_id: "string from /privacy-experience's nested experience_config obj"
}
and IP address the backend will derive itself?
yes @allisonking I think I can get the IP from the FastAPI I also am assuming I'm getting the fides user device id under browser_identity as well as a list of preferences with each notice history, does that line up?
|
got it, thanks for the payload, that's helpful! I think I'm a little behind on this, but just to state my understanding:
does that sound right? |
@allisonking yes! both payloads for both the privacy center and the components for saving preferences are intended to be identical, although the privacy center additionally may have a code in it, if it's the verified identity workflow |
… experience config history and experience history records that displayed the notices to which the user consented. - Move request_origin, url_recorded, and user_agent from being in the request body. Instead pull these from the request headers or the privacy experience where applicable. - Also pull the ip address and mask before saving.
…80 of the 128 bits to 0 for ipv6. Encrypt this field. Also add "method" to privacy preferences"
…, as well as the truncated ip address and the method.
…. Just pass in the privacy experience history id, and we can extract the config history from there if applicable.
- Remove unused Request dependency - Remove unnecessary caching of notices when updating experience. - Stringify experience-related FK's on PrivacyPreferenceHistory to avoid circular dependencies now that we have a method in PrivacyExperience that needs to surface CurrentPrivacyPreferences - Add an enum for method - button, individual notices
bb66dcd
to
291da6d
Compare
❗ Contains migration
❗ Dependent on #3292
Closes #3133
Closes #3196
Description Of Changes
Start tracking additional fields when saving consent preferences to demonstrate compliance and move some of the existing fields from the request body to extract from request headers.
Code Changes
Start tracking new fields:
PrivacyPreferenceHistory.anonymized_ip_address
which is really a truncated version of the ip address and stored encryptedPrivacyPreferenceHistory.method
- The method of consent preference in a modal (buttons, individual notices)PrivacyPreferenceHistory.privacy_experience_config_history_id
- the particular version of the Config that surfaced the notice (contains the copy)PrivacyPreferenceHistory.privacy_experience_history_id
- the particular Experience - contains the region, type, and delivery mechanismStart pulling some fields off of request headers or experience themselves:
request_origin
(privacy center/overlay now comes off of the experience)user_agent
now comes off of request headersurl_recorded
is now retrieved from theReferer
headerprivacy_experience_config_history_id
is pulled off of the experience if applicableBug fix:
Steps to Confirm
In the postman collection
POST {{host}}/privacy-notice
PATCH {{host}}/privacy-preferences
method
,experience_config_history_id
andprivacy_experience_history
can be passed in nowGET {{host}}/historical-privacy-preferences
Pre-Merge Checklist
CHANGELOG.md