[
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..
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. Update merge logic
On merge, 2 aliases would be 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..
h3. Implementation
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
- creation of such aliases would still be allowed from public endpoints
For aliases ids that are not secure, such as emails, logins or CRM ids:
- "secure" would be set to false
- creation of these aliases would be restricted to private endpoints
> 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..
> 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. Update merge logic
> On merge, 2 aliases would be 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)
