[
https://issues.apache.org/jira/browse/UNOMI-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Gauthier updated UNOMI-818:
----------------------------------
Description:
h3. Context:
With Unomi 2, aliases manage to simplify the merge logic and the data structure
by removing the need to keep merged profiles. However, they cannot be used as
they're described on the documentation website because of a security / design
limitation: aliases ids need to be impossible to "guess" because if you guess
the alias id, then you can access the related profile data.
The goal of this ticket is to improve the current alias logic so that aliases
values could actually be emails, logins, crm ids, etc.. so that developers
using Unomi could easily retrieve in one API call any profile with a CRM id,
email, etc..
h3. Implementation
h4. New "secure" field in aliases
A new field should be added to the aliases object / index: "secure" (naming to
be confirmed)
For aliases ids that are secure, like java uuids used for profile ids: "secure"
would be set to true
For aliases ids that are not secure, such as emails, logins or CRM ids:
"secure" would be set to false
h3. Limitation / to be discussed:
The system would assume that ids from different systems (email, login, crm id,
..) cannot be associated to different profiles:
If the login of laurel is "abcd"
If the CRM id of hardy is "abcd"
Then unomi would consider these 2 profiles as the same
One way to circumvent that limitation would be to add a new field "profile
property" in the alias index.
Aliases would look like:
- Fields: alias id | profile id | profile property | secure
- Document 1, storing 2 profile ids following a merge:
215b2708-7630-446b-8864-3d1c226106c3 | 36aa9313-7e17-4c43-ad24-9565f6ea272d |
id | true
- Document 2, storing a login alias, same profile as document 1: johnSmith |
36aa9313-7e17-4c43-ad24-9565f6ea272d | login | false
h4. Merge logic
Merge logic needs to be updated so that now, 2 aliases are created:
- One to store the profile id of the merged profile, with secure set to true
(already existing)
- One to store the value of the mergeIdentifier property (email value or login
value)
h4. Update context.json / eventCollector implementation
Public endpoints (context.json and eventcollector) implementation should be
updated to only look up for aliases ids that are secure (or do not change the
lookup logic but block/skip the process if the secure flag is false).
h3. Tests scenarios
Given a rule with mergeIdentifier based on login event and profile property
"loginIdentifier" is running:
- Create a first visit, get a profile id, called 1111
- Update the profile to nbOfKids = 2
- Send a login event associated to profileID, with johnSmith as loginIdentifier
- Assert that one alias has been created: johnSmith, 1111, secure: false
- Call the endpoint /cxs/profiles/johnSmith, assert that you get a profile with
property nbOfKids = 2
- Clear cookie / create a new visit
- Set your profile id cookie to "johnSmith"
- Read the profile properties values (using requiredProfileProperties [*]
- Ensure that nbOfKids is empty
- Clear cookie / create a new visit , get a profile id, called 1112
- Send a login event with a loginIdentifier = johnSmith
- Assert that one alias has been created: 1112, 1111, secure: true
was:
h3. Context:
With Unomi 2, aliases manage to simplify the merge logic and the data structure
by removing the need to keep merged profiles. However, they cannot be used as
they're described on the documentation website because of a security / design
limitation: aliases ids need to be impossible to "guess" because if you guess
the alias id, then you can access the related profile data.
The goal of this ticket is to improve the current alias logic so that aliases
values could actually be emails, logins, crm ids, etc.. so that developers
using Unomi could easily retrieve in one API call any profile with a CRM id,
email, etc..
h3. Implementation
h4. New "secure" field in aliases
A new field should be added to the aliases object / index: "secure" (naming to
be confirmed)
For aliases ids that are secure, like java uuids used for profile ids: "secure"
would be set to true
For aliases ids that are not secure, such as emails, logins or CRM ids:
"secure" would be set to false
h4. Merge logic
Merge logic needs to be updated so that now, 2 aliases are created:
- One to store the profile id of the merged profile, with secure set to true
(already existing)
- One to store the value of the mergeIdentifier property (email value or login
value)
h4. Update context.json / eventCollector implementation
Public endpoints (context.json and eventcollector) implementation should be
updated to only look up for aliases ids that are secure (or do not change the
lookup logic but block/skip the process if the secure flag is false).
h3. Tests scenarios
Given a rule with mergeIdentifier based on login event and profile property
"loginIdentifier" is running:
- Create a first visit, get a profile id, called 1111
- Update the profile to nbOfKids = 2
- Send a login event associated to profileID, with johnSmith as loginIdentifier
- Assert that one alias has been created: johnSmith, 1111, secure: false
- Call the endpoint /cxs/profiles/johnSmith, assert that you get a profile with
property nbOfKids = 2
- Clear cookie / create a new visit
- Set your profile id cookie to "johnSmith"
- Read the profile properties values (using requiredProfileProperties [*]
- Ensure that nbOfKids is empty
- Clear cookie / create a new visit , get a profile id, called 1112
- Send a login event with a loginIdentifier = johnSmith
- Assert that one alias has been created: 1112, 1111, secure: true
> Private aliases
> ---------------
>
> Key: UNOMI-818
> URL: https://issues.apache.org/jira/browse/UNOMI-818
> Project: Apache Unomi
> Issue Type: Improvement
> Reporter: Romain Gauthier
> Priority: Major
>
> h3. Context:
> With Unomi 2, aliases manage to simplify the merge logic and the data
> structure by removing the need to keep merged profiles. However, they cannot
> be used as they're described on the documentation website because of a
> security / design limitation: aliases ids need to be impossible to "guess"
> because if you guess the alias id, then you can access the related profile
> data.
> The goal of this ticket is to improve the current alias logic so that aliases
> values could actually be emails, logins, crm ids, etc.. so that developers
> using Unomi could easily retrieve in one API call any profile with a CRM id,
> email, etc..
> h3. Implementation
> h4. New "secure" field in aliases
> A new field should be added to the aliases object / index: "secure" (naming
> to be confirmed)
> For aliases ids that are secure, like java uuids used for profile ids:
> "secure" would be set to true
> For aliases ids that are not secure, such as emails, logins or CRM ids:
> "secure" would be set to false
> h3. Limitation / to be discussed:
> The system would assume that ids from different systems (email, login, crm
> id, ..) cannot be associated to different profiles:
> If the login of laurel is "abcd"
> If the CRM id of hardy is "abcd"
> Then unomi would consider these 2 profiles as the same
> One way to circumvent that limitation would be to add a new field "profile
> property" in the alias index.
> Aliases would look like:
> - Fields: alias id | profile id | profile property | secure
> - Document 1, storing 2 profile ids following a merge:
> 215b2708-7630-446b-8864-3d1c226106c3 | 36aa9313-7e17-4c43-ad24-9565f6ea272d |
> id | true
> - Document 2, storing a login alias, same profile as document 1: johnSmith |
> 36aa9313-7e17-4c43-ad24-9565f6ea272d | login | false
> h4. Merge logic
> Merge logic needs to be updated so that now, 2 aliases are created:
> - One to store the profile id of the merged profile, with secure set to true
> (already existing)
> - One to store the value of the mergeIdentifier property (email value or
> login value)
> h4. Update context.json / eventCollector implementation
> Public endpoints (context.json and eventcollector) implementation should be
> updated to only look up for aliases ids that are secure (or do not change the
> lookup logic but block/skip the process if the secure flag is false).
> h3. Tests scenarios
> Given a rule with mergeIdentifier based on login event and profile property
> "loginIdentifier" is running:
> - Create a first visit, get a profile id, called 1111
> - Update the profile to nbOfKids = 2
> - Send a login event associated to profileID, with johnSmith as
> loginIdentifier
> - Assert that one alias has been created: johnSmith, 1111, secure: false
> - Call the endpoint /cxs/profiles/johnSmith, assert that you get a profile
> with property nbOfKids = 2
> - Clear cookie / create a new visit
> - Set your profile id cookie to "johnSmith"
> - Read the profile properties values (using requiredProfileProperties [*]
> - Ensure that nbOfKids is empty
> - Clear cookie / create a new visit , get a profile id, called 1112
> - Send a login event with a loginIdentifier = johnSmith
> - Assert that one alias has been created: 1112, 1111, secure: true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
