Open whitter opened 2 weeks ago
Hi @whitter,
Thank you for sharing your findings. You would indeed be correct that the Headless API only takes into account the provided external visitor id when provided, and does not act on e.g. ClaimPrincipals. I think the solution you've created works nicely in your situation, but we will have to take a look internally if there are steps we can & want to take to implement such functionality ourselves!
It is also worth noting that the /umbraco/engage/api/v1/segmentation/content/segments/*
endpoints are intended to be visitor agnostic. For active segments for a specific visitor, the /umbraco/engage/api/v1/segmentation/content/activesegments/*
endpoints are to be used!
Hey @cornehoskam, silly copy and paste on my part I did mean the activesegments
endpoint in relation to the user principal. I've corrected the mistake above.
Hi,
I have been playing around with uMarketingSuite/Engage in a headless setup, using NextJS for the frontend. Just been getting my head around how personalisation would function in a static website.
Using endpoints such as
/umbraco/engage/api/v1/segmentation/content/segments/{path}
during site build time to find all the configured segments to generate pages for each segment works perfectly.But when using
/umbraco/engage/api/v1/segmentation/content/activesegments/{path}
during the the request for a page to work out which segment should be shown to the user does not work as expected when a segments rules evaluate user data/state. Such as are they logged in or have some profile information.This appears to be due to the fact that this endpoint does not set the internal user principle based on the provided bearer token in the request headers.
If I add a custom bit of middleware to the CMS site that checks the request to see if it is an Engage request and then to change the request principle to be what is provided in the authentication header it all works as expect.