You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by "Romain Gauthier (Jira)" <ji...@apache.org> on 2023/12/21 06:28:00 UTC
[jira] [Updated] (UNOMI-818) Private aliases
[ 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
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
was:
h3. Context:
With Unomi 2, aliases did 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 if you
h3.
> 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
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)