Nt 1768

[David Nalchevanidze (nalchevanidze)]

No description provided.

[wiz-inc-38d59fb8d7]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
SAST Findings	3
Total	3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[Charles Hudson (phobetron)]

The changes in this file may not be necessary after the latest changes, especially since the latest changes cover all requests (more or less)

[David Nalchevanidze (nalchevanidze)]

The changes in this file may not be necessary after the latest changes, especially since the latest changes cover all requests (more or less)

in which file?

[Charles Hudson (phobetron)]

You don't identify using the anonymous ID. The Experience system should already have that; it's intended to be an ID that comes from the Experience system itself and is stored/reused to ensure the profile remains consistent. userId is a non-anonymous ID that is something that comes from the customer's system. So in this case, like I had stated before, you would use something that may come from a form or a query parameter, at least in a simple E2E example where we don't have state or user data saved in long-term storage.

[David Nalchevanidze (nalchevanidze)]

but cookie is keeping information about if its logged in or not? server stores cookie-> client uses it. ... on next visit server checks if it already user which has profile id and identifies it without generaring new id for it ... this is workflow i understand and think is worth of demonstrating

[Charles Hudson (phobetron)]

The profileId or any of its other names like anonymousId or stableId are only indirectly related to the userId as I had explained. The profileId et al are handled internally except where it is passed from BE to FE via cookie. The userId can literally be anything. All we need to know from the returned profile data at least for our purposes is that the profile has some kind of data returned in traits. Identified users may or may not have data inside traits but unidentified users should never have data inside traits. But in our mocks, the identified user profile does have data in traits, so that makes it easier.

[David Nalchevanidze (nalchevanidze)]

ok. but still based what you said i don't got whats wrong in codebase? it reflects what you described.

[Charles Hudson (phobetron)]

See the code comment I just left.

[Charles Hudson (phobetron)]

This is what I was talking about, the userId is not the anonymousId and to use it as such would be confusing to anyone using this reference implementation as a reference.

[David Nalchevanidze (nalchevanidze)]

ah. ok.

[David Nalchevanidze (nalchevanidze)]

but how i should call identify in that case? use id is required field?

[Charles Hudson (phobetron)]

Like I've mentioned before, you could add query param support to your route, expecting an optional userId param. That param's value could pretty much be anything, since the mock server isn't aware of the data on that level. Just shovel it to the mock server (via the SDK of course) and it should give you an identified user.

[David Nalchevanidze (nalchevanidze)]

tbh, i don't got what you wrote ... and quite confused. it would be way easier if we paired ... as its not so intuitive to decode it as a async text messages .... otherwise just add your changes on my pr and merge it.

[David Nalchevanidze (nalchevanidze)]

i played around and i think i got what is whole point we wanted to test. hopefully this is what you meant.

[David Nalchevanidze (nalchevanidze)]

btw i was reading documentation and actually userId should not be required if anonymousId is set. see this link: https://segment.com/docs/connections/spec/identify/

[David Nalchevanidze (nalchevanidze)]

this way we could still test what i was trying to test. the case when u identify based anonymousId. and not require userId as parameters.

[Charles Hudson (phobetron)]

I think you still misunderstand userId. Even if we do update userId to be optional, we would still never set the userId to the profile ID. You would instead set anonymousId to the profile ID. But that happens internally using getAnonymousId so you don't need to deal with it manually per event.

We depart from Segment a bit here, so we don't need to validate either/or on userId vs anonymousId. The SDK handles anonymousId and profileId separately from events in our system, and userId is simply extra data. More info about that in my new comment with the suggested change.

[Charles Hudson (phobetron)]

I will go ahead and update the userId stuff in the schema, it's something I can do fairly quickly so you'll be able to update the PR in the morning.