Summary: There was an XCode build warning because the feature list in the ```_FeatureManager``` was not exhaustive. This diff fixes it.
Reviewed By: xta0
Differential Revision: D53289237
fbshipit-source-id: ccf6da5646b8580a95640dc180072bee2fec6abd
Summary:
There exists a potential issue that duplicate install can be sent because `applicationDidBecomeActive` may be triggered multiple times within a very short time (e.g. App Launch and ATT prompt can trigger this function) and thus cause `publichInstall` is triggered multiple times.
In order to fix this issue, this diff reuses the existing key `lastAttributionPingString` and `lastInstallResponseKey`. The flow will be
1. PublishInstall is triggered
2. Check if `lastAttributionPingString` exists and will send install event and set the key if the key doesn't exist. We do nothing if the key exists.
3. If the install event is sent successfully, we will set the key `lastInstallResponseKey`. If not, we'll remove the key `lastAttributionPingString`.
4. When app terminates, we'll check if `lastInstallResponseKey` exists to check if the install event is sent successfully. If the key exists, we'll do nothing. If the key doesn't exist, it means the install event is not sent successfully in the app launch and we'll remove the key `lastAttributionPingString`.
Reviewed By: jjiang10
Differential Revision: D53170017
fbshipit-source-id: 340e21188d884088215a65d06fffc402065a5102
Summary:
There are certain events that are "sensitive" that violate our terms that are transmitted from 3P clients to Meta. We want to redact these event names from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "redacted" events from the server-side and build the ```RedactedEventsManager``` to process and redact these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1OhJ-LSX0fl8WJJlbs17ka3wleUQmUDchmdbmfLUXD0w/). This diff lays the foundation for this feature by creating the ```RedactedEventsManager``` class and adding the ```FBSDKFeatureFilterRedactedEvents``` feature.
The next diff will actually implement and enable the ```RedactedEventsManager```.
Reviewed By: sway-git
Differential Revision: D51177934
fbshipit-source-id: 161ee1fa7a2c5e3e28e695ba60314a05e9abafdd
Summary:
There are certain events that are "unused" and "unwanted" that are transmitted from 3P clients to Meta. We want to block these events from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "blocklisted" events from the server-side and build the ```BlocklistEventsManager``` to process and block these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1kYBDdyPcCr99-B_mtubcwhVlStBW8N_E-9HDBfknka4/). This diff lays the foundation for this feature by creating the ```BlocklistEventsManager``` class and adding the ```FBSDKFeatureBlocklistEvents``` feature.
The next diff will actually implement and enable the ```BlocklistEventsManager```.
Reviewed By: sway-git, Nathaaaalie
Differential Revision: D51099373
fbshipit-source-id: 16c57d80ba34ea2d5fcb90b4547c04685c0016fb
Summary:
- Fix the broken tests on master.
- The DateComponents takes daylight saving time into account, so when you ask to subtract 35 days, it doesn't subtract exactly 35×24×60×60 seconds. Instead, it goes back 35 calendar days, which due to daylight saving time changes, can result in a slightly different number of total seconds.
Differential Revision: D51377252
fbshipit-source-id: ec579ee3890988ac3dc564c095f5ae4f71134519
Summary: Since we already have a bunch of test cases covering this case, this diff simply added a few cases for checking server-side values.
Differential Revision: D51152076
fbshipit-source-id: be70fcab3f2bb5c11deb0146d743dcfa262533af
Summary: Introduce a new internal client side only flag during the transition. The original `isAutoLogAppEventsEnabled` will be delegated to `isAutoLogAppEventsEnabledOnClientSide`. In the next diff, we will be adding new getter and setter for the `isAutoLogAppEventsEnabled` flag.
Reviewed By: dreamolight
Differential Revision: D51330511
fbshipit-source-id: cd63649372861fcdf9d06e0ecd60acae3753490f
Summary: WE should update the var in memory in setters. This line was somehow overlooked.
Reviewed By: dreamolight
Differential Revision: D51333425
fbshipit-source-id: cdf8bd5f0d97fe5a2b900c2d1ce0e198c65636c9
Summary:
Introduce two new server-side flags:
- sdk_auto_logging_default_value
- sdk_auto_logging_override_value
SDK parses and stores these flags in the configuration object.
Reviewed By: dreamolight
Differential Revision: D51100780
fbshipit-source-id: 7e2448070b3ab66f86f708ba159c5c7c77aca607
Summary: Fix backward compatibility for building the URL API for Xcode 14. In OC, we use __IPHONE_OS_VERSION_MAX_ALLOWED to check the iOS 17 SDK. In Swift, we use `#if swift(>=5.9)` to check the iOS 17 SDK (swift compiler is 5.9 in XCode 15)
Reviewed By: sway-git, xta0
Differential Revision: D49626160
fbshipit-source-id: c702fb4208634720e78ed549ae6cd647f0f6e464
Summary: To avoid using deprecated API, updated to latest one
Reviewed By: KylinChang
Differential Revision: D49296481
fbshipit-source-id: 8051fe1f5cf6f3972b3127db6ec3d2132a28d052
Summary:
In theory, we should remove checkAndRevokeTimer since we don’t need to extend skan report window
However, to play it safe, we did:
1. For SKAdNetworkReporter only include v3, we bought back the original logic
2. For SKAdNetworkReporterV2 include v4, we removed extending report window
Reviewed By: KylinChang
Differential Revision: D49296300
fbshipit-source-id: 5df17751a585d4cf3c1f4d5ec694b4a3e86dad90
Summary:
in order to release v4 on time and make sure there is no issue, we seprate SKAN report logic into two different classes and wrap up with a GK
FBSDKSKAdNetworkReporter
- previous SKAN report logic, no v4, only update the API to prevent CV0 reset issue
FBSDKSKAdNetworkReporterv2
- v4 logic including coarse value, 2nd/3rd postback
Will add feature GK in next diff
Reviewed By: KylinChang
Differential Revision: D48933610
fbshipit-source-id: 9420a0b8dabd1747258f3b87733e5b3f5f9fe985
Summary: as title, the param is optional
Reviewed By: wx0165927473
Differential Revision: D48711246
fbshipit-source-id: 2218c69156c18144811b5682bf8d6636e5c6174a
Summary: as title, the param is optional
Reviewed By: KylinChang
Differential Revision: D48152979
fbshipit-source-id: eba091b769a9249c8c4b95f88c08f1af0b31ceb8
Summary: Since v4 supports decrementing CV, we need to make sure we only report install for the first time app launch
Reviewed By: KylinChang
Differential Revision: D48086213
fbshipit-source-id: 3db468baa1590227ba5ed5fc1a51a0dfb5628ba5
Summary: we should only check cutoff and do it for the 1st postback once we move to v4.
Reviewed By: KylinChang
Differential Revision: D47818971
fbshipit-source-id: 44a53ff000035125a2d0de2edcd121d9caf2ea6f
Summary: as title, actual updating CV logic in next diffs
Differential Revision: D47318509
fbshipit-source-id: 9a487c92e07104378b9c29f58a0b77b47b3ec36b
Summary:
Since v4 has lock window mechnism, we don’t need previous self defined timer bucket.
This will make code cleaner, more straightforward and easy to matintain,
Differential Revision: D47317756
fbshipit-source-id: 767eb553acf77c1eee593825636226ff6defe16b
Summary:
**In this diff:**
- Added a new query field `FBSDK_SERVER_CONFIGURATION_PROTECTED_MODE_RULES_FIELD` to load the protected mode rules
- Parse and update the `maca_rules` in `MACARulesMatchingManager`
Reviewed By: KylinChang
Differential Revision: D46807450
fbshipit-source-id: 3c4486aab5693bd7ed3872a0e93d0593443149c9
Summary: Dynamically loading standard parameters list from server. If fail, ball back to the default list
Reviewed By: KylinChang
Differential Revision: D46922765
fbshipit-source-id: c66d1466beb9e6eb1fb4122d664c4c68d82f01f1
Summary:
**Context**
As previous diffs D46705940, we enable `ProtectedMode` to filter non-standard parameter of App Events in client side. But without those params, the MACA matching cannot be done in server, so we need to move the MACA rule matching to client side as well.
**In this diff**
- Add new feature `FBSDKFeatureMACARuleMatching`
- Add new class `MACARuleMatchingManager` and add to the AppEvents' configuration
Reviewed By: KylinChang
Differential Revision: D46779149
fbshipit-source-id: d12ac3b6be2cd173fdd5023d096c1ad1478cd2f8
Summary:
**In this diff**
- Implement the filter method of ProtectedModeManager.
Now the standardParameter list is hardcoded in FBSDK, will change to dynamically load in the future.
Reviewed By: KylinChang
Differential Revision: D46708165
fbshipit-source-id: 6984dec83ae578e87e8df2871c28ab93a2a989ba
Summary:
New diff copy from D46668428
ProtectedMode is a new feature added in FBSDK, in order to filter the non-standard parameters in AppEvents that will be sent to the FB server.
**In this diff**
- Create ProtectedModeManager class stub
- Add protectedMode to the AppEvent configuration
Reviewed By: Nathaaaalie
Differential Revision: D46705940
fbshipit-source-id: e3f164c7d3c9996232b3e8d12c51128494f8cef5
