feat: Block mp cookies when noFunctional is true by khushi1033 · Pull Request #1167 · mParticle/mparticle-web-sdk

khushi1033 · 2026-02-24T21:59:16Z

Background

Rokt supports disabling cookies via client-side flags (noFunctional, noTargeting). With the introduction of the joint Rokt/mParticle SDK, mP cookies are treated as strictly necessary — meaning they could not previously be disabled for Rokt-only clients. This created friction for clients who want a clear opt-out path for users or interpret mP cookies as non-essential when using the SDK solely for Rokt use cases (e.g., post-checkout ads).

However, simply blocking all mP cookies introduces a risk: without the mprtcl-v4-{workspace_token} cookie, every page load looks like a new user, causing identify to be called continuously and flooding the system with new profile creation.

What Has Changed

Blocked all mP cookies/persistence when noFunctional: true: localStorage, cookies, and session storage writes are no-ops in persistence.js, batchUploader.ts, and mp-instance.ts.
Created a no-op identity cache vault when noFunctional: true to prevent mprtcl-v4-id-cache from being written to localStorage.
Suppressed automatic identify calls when noFunctional: true AND no explicit identifiers (device ID or user identities like email) are provided by the partner — preventing runaway
profile creation.
Added hasExplicitIdentifier utility in identity-utils.ts to check whether a partner has passed a device ID or user identities via config.
Prevented auto-population of identifyRequest from persistence when noFunctional: true during SDK initialization.
Disables cookie sync when noFunctional = true, even if noTargeting = false

Screenshots/Video

N/A

Checklist

I have performed a self-review of my own code.
I have made corresponding changes to the documentation.
I have added tests that prove my fix is effective or that my feature works.
I have tested this locally.

Additional Notes

Tested locally in browser using a mock page to turn on/off noFunctional flag and checking that identify calls, cookie/local storage, and kit initialization behaves as expected

Reference Issue (For employees only. Ignore if you are an outside contributor)

Closes https://go/j/972

alexs-mparticle

@khushi1033 Great PR and I'm happy to see this coming together. I have a few comments but this looks pretty solid.

src/identity-utils.ts

src/batchUploader.ts

src/mp-instance.ts

src/identity-utils.ts

src/persistence.js

alexs-mparticle · 2026-02-25T16:02:54Z

test/src/tests-cookie-syncing.ts

            data['newMPID'].csd.should.have.property(roktModuleId);
        });
-
-        it('should not block Rokt cookie sync when only noFunctional is true', async () => {


Why was this removed?

With noFunctional blocking cookies now, this test fails since theres no mPId being saved. Planning to add a new test once we have confirmation of how we want cookie sync to behave under noFunctional

src/identity-utils.ts

rmi22186 · 2026-02-25T22:13:36Z

src/mp-instance.ts

+    // When noFunctional is true, we must still return a vault-shaped object because
+    // Identity expects mpInstance._Identity.idCache to always exist. A no-op vault
+    // ensures no identity response data is written to localStorage
+    if (mpInstance._CookieConsentManager?.getNoFunctional()) {
+        const vault = new LocalStorageVault(`${mpInstance._Store.storageName}-id-cache`, {
+            logger: mpInstance.Logger,
+        });
+        vault.store = function() {
+            this.contents = arguments[0];
+            mpInstance.Logger.verbose(`Storage disabled: not storing id-cache when noFunctional is true`);
+        };
+        vault.retrieve = function() {
+            this.contents = null;
+            return null;
+        };
+        vault.purge = function() {
+            this.contents = null;
+        };
+        return vault;
+    }


I asked AI to instead of creating a no-op, to make idCache optional. Here are the pros/cons of optional idCache:

1. Explicit “no cache” instead of a fake object optional idCache: The type is BaseVault<...> | null. “We are not caching” is visible in the type and in control flow. No-op: You have an object that looks like a cache but isn’t. “No cache” is hidden behind an implementation that only exists to satisfy “something is always there.” 2. One concept instead of two optional idCache: There’s a single idea: either we have a real cache or we don’t. No-op: You maintain two concepts — “real cache” and “fake cache that implements the interface.” The no-op is there only to avoid null checks, which pushes the “no functional” concern into a dummy implementation. 3. Less code and no dummy behavior optional idCache: No extra type, no store/retrieve/purge stubs, no allocation when noFunctional is true. No-op: You have to implement and maintain those no-op methods and keep them in sync with the real vault behavior (e.g. logging) over time. 4. Honest API optional idCache: The API says “identity cache may be absent.” Callers (or shared utils) handle that once at the boundary. No-op: The API says “you always have a cache,” but one of the implementations is a lie. That can be surprising for anyone reading or debugging.

I'd prefer the optional no cache

Changed to use DisabledVault instead similar to the approach in this PR

Co-authored-by: Robert Ing <rmi22186@gmail.com>

src/vault.ts

src/identity-utils.ts

rmi22186 · 2026-03-02T14:56:40Z

test/jest/identity.spec.ts

+            expect(hasExplicitIdentifier(store as IStore)).toBe(false);
+        });
+
+        it('should return false when userIdentities object is empty', () => {


can you add one more test for if useIdentities object has an invalid user identity, like userIdentities = {email: ''} and also userIdentities = {email: null}?

rmi22186

Can you add tests to the forwarders test file that shows an integration test when we add noFunctional = true, and shows that forwarders are still being initialized, and the forwarder still receives an event even if MP SDK does not initialize?

rmi22186 · 2026-03-02T16:15:44Z

test/jest/roktManager.spec.ts

    });
+
+    describe('when MP SDK is not fully initialized', () => {
+        it('should allow Rokt Kit to initialize and selectPlacements', async () => {


What about this tests is showing that the MP SDK is not fully initialized? It seems to just be setting up the rokt manager manually.

Similar to the forwarders test, it'd be helpful to have a test (probably there), specifically for seeing if rokt is fully initialized even if the MP SDK isn't.

Something like:
call mParticle init with noFunctional = true
assert that the MP SDK is not initialized
assert that no identity calls were made
call mParticle.rokt.selectPlacements and assert that the kit called selectPlacements internally

Yep you're right, I updated the test to better represent the full flow.

alexs-mparticle

LGTM. Once you resolve comments from @rmi22186, I think we can ship.

rmi22186 · 2026-03-02T21:23:48Z

test/src/tests-forwarders.ts

+            delete window.mParticle.config.identifyRequest;
+        });
+
+        it('should still initialize forwarders when noFunctional is true (even when SDK does not complete initialization)', () => {


Can we add a test that says the event is still sent to the forwarder here also?

It should be work both in this case when there is no identity passed, as well as the bottom case where an identity is passed,

Done, added verification that events are still sent even without identity passed in

rmi22186 · 2026-03-02T22:43:20Z

src/apiClient.ts

            );
            mpInstance._Store.eventQueue.push(event);
+            // When noFunctional is true, mpid may never come (no identity), so still send to forwarders so kits receive the event.
+            if (mpInstance._CookieConsentManager?.getNoFunctional() && !isEmpty(event) && (event.EventName as unknown as number) !== Types.MessageType.AppStateTransition) {


It's actually not just events. You may want to ask claude or cursor to do an audit of where we call anything on the forwarder inside of the forwarders.js module, as an example forwarder.setUserAttribute. These will needs tests too.

Is it ever possible for an event to be sent twice to a forwarder in this case?

If a partner passes an identity, and a customer is on a slow connection, it's possible an MPID hasn't come back yet. THe event gets queued and also immediately forwarded to the forwarder.

Then the MPID comes back, the queue gets processed, and in that code block, would it also then get sent to the server? Perhaps doing a check like you did elsewhere for hasExplicitIdentifier may help here?

Got it, yeah I added a check for hasExplicitIdentifier to ensure the events aren't sent twice.

Also added tests for the following behavior under noFunctional = true:

forwarder.setSessionAttribute still works whether an identity is provided or isn't.

forwarder.setUserAttribute and forwarder.removeUserAttribute only work when an identity is provided, and are no-ops when it isn't since getCurrentUser is null

forwarder.onUserIdentified and forwarder.onIdentifyComplete are only called when an identity is provided

rmi22186 · 2026-03-03T16:47:16Z

test/jest/sessionManager.spec.ts

+            });
+
+            expect(identifySpy).toHaveBeenCalledWith({
+                userIdentities: { email: 'user@example.com' },


One of the requirements is that once identify is called, mparticle should be fully initialized. I'd add a test for this. Also, have the SDK queue a few events before calling identify, confirm the queue is a certain length (if that is possible), then call identify, wait for it to return, and confirm logevent was called with the queued events.

Added testing to tests-forwarders.ts to make sure mparticle is being intialized after identify is called and added a test to check logEvent is being called on queued events.

sonarqubecloud · 2026-03-03T19:46:52Z

Quality Gate failed

Failed conditions
19.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

khushi1033 added 2 commits February 24, 2026 16:28

block mp cookies when nofunctional is true

e74dedb

clean up comments

add2e74

khushi1033 marked this pull request as ready for review February 25, 2026 14:53

khushi1033 requested review from alexs-mparticle, jaissica12 and rmi22186 February 25, 2026 14:53

alexs-mparticle requested changes Feb 25, 2026

View reviewed changes

addressed pr comments

6e5f562

rmi22186 requested changes Feb 25, 2026

View reviewed changes

khushi1033 and others added 3 commits February 25, 2026 17:41

Update src/identity-utils.ts

9f9d3c0

Co-authored-by: Robert Ing <rmi22186@gmail.com>

use disabled vault

892cc5a

disable cookie sync when nofunctional is true

c73bb71

alexs-mparticle requested changes Feb 27, 2026

View reviewed changes

src/vault.ts Show resolved Hide resolved

src/identity-utils.ts Outdated Show resolved Hide resolved

src/identity-utils.ts Outdated Show resolved Hide resolved

changes from comments

e67fb76

rmi22186 reviewed Mar 2, 2026

View reviewed changes

added additional tests

adb5938

alexs-mparticle approved these changes Mar 2, 2026

View reviewed changes

rmi22186 reviewed Mar 2, 2026

View reviewed changes

verify events still sent without identity when noFuntional

d8564ce

rmi22186 reviewed Mar 2, 2026

View reviewed changes

khushi1033 added 2 commits March 3, 2026 09:42

testing of all forwarder methods

0086eb2

tests for when no identity provided

17796db

rmi22186 reviewed Mar 3, 2026

View reviewed changes

test mparticle intialized and logevent

431937b

Conversation

khushi1033 commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

What Has Changed

Screenshots/Video

Checklist

Additional Notes

Reference Issue (For employees only. Ignore if you are an outside contributor)

Uh oh!

alexs-mparticle left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rmi22186 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexs-mparticle left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

khushi1033 Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Mar 3, 2026

Quality Gate failed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

khushi1033 commented Feb 24, 2026 •

edited

Loading

khushi1033 Mar 2, 2026 •

edited

Loading