Anonymous consents

Basic idea

The idea is to display a consent dialog to an anonymous user, once they visit Spartacus. The dialog should contain a list of all anonymous consents (anonymous consents are the same as regular consents, but with exposed property set to true; see the last column here) and an option to give/withdraw each consent. The anonymous user should be able to close and re-open the dialog at any time, in case they change their mind.

The anonymous consents are exchanged between Spartacus and the server in a stateless way, using X-Anonymous-Consents HTTP header. With each request to the server, the X-Anonymous-Consents should be sent to the server. When an anonymous user gives/withdraws a consent, the corresponding consent's consentState field is changed to reflect the new state. (if we want to support the case when the user logs out and the previously given anonymous consents are restored, the only way to do that is to append the X-Anonymous-Consents header with every request, not just anonymous ones.).

Limitations and edge cases

There are three edge cases:

Moving from Anonymous User to Logged In Customer - once the user logs in, the consents that were given as an anonymous user are ignored, and the consents of the currently logged in user are restored, see "Moving from Anonymous User to Logged In Customer".
The case when a user is moving from an anonymous user to a registered user, the consents should be transferred (see Moving from Anonymous User to Registered Customer). E.g. if an anonymous user gave a tracking consent, and then the user decided to register, the tracking consent should be automatically given on the back-end once the user registers. However, this is not working as intended when using the OCC APIs. [? Bill: Pawel from Ray says this is an accelerator issue, and that they can't do anything until it's resolved (if they need to do something at all)].
In the old accelerator, when an authenticated user logs out, the previously given consents are restored (when the user was anonymous, i.e. was not logged in). See "Moving from Logged In Customer to Anonymous User When Logging Out". In order to support this, we need to keep the anonymous consents in the state even after the anonymous users decides to regiser/log in.

Flow

User visits Spartacus for the first time - Spartacus pulls the anonymous consents from the API: /users/anonymous/consenttemplates
- NOTE: this API endpoint only returns consents that are exposed for an anonymous user, see the last column in this impex.
Once the anonymous consents are retrieved, put them into the state, and sync them with localStorage.
- Use a different state slice than the regular consents. The reason for this is that when a user logs out, the whole user state slice is cleared. The state slice for anonymous consents should be a new feature state called e.g. anonymous-consents.
The anonymous consents dialog is presented to the user - it contains a list of all the anonymous consents with their corresponding state (given/withdrawn). If the user didn't even interact with a particular consent, the state of it should clearly indicate the fact that a consent is neither given nor withdrawn (there should be some kind of a neutral state, similar to the old accelerator, see the image below)
- When to present the anonymous consents dialog to the user?
- If the user didn't previously close it by clicking on an x button. This toggle information should be stored in the dialogs.anonymous-consents.
- If an anonymous user has already given a consent, but there's a new version of that consent available on the server, the dialog should be displayed again to the user. [? What's the consentState of it? Should the state be the same as before, e.g. if it was given before, should the consentState be GIVEN? Or it should null, because it's the new version?]
- The user should be able to re-open the anonymous consents dialog. [? There should a link somewhere that can open the dialog again. Maybe in the header/footer?]

UI

Pending.

Some WIP wireframes can be seen here.

Changes to the current consents implementation

The consent that is shown to the user while registering is not "wired" with the back-end; meaning that when the user visits the consent management page after registration, the state of the consent will not reflect the user's decision while registering. Once anonymous consents are pulled from the back-end, this consent can be retrieved from localStorage in the register.component.ts and wired, so that when a user registers, the consent's state is persisted and the user can see that the status of it on the consent management page.

Implementation details and notes

To see the flow in action, use this postman collection, starting from the linked API call ("Anonymous consents - Get List").

To have the necessary anonymous consents in your local back-end, you can use this impex.

the anonymous consents received from the API are serialized in JSON format and URL encoded in UTF-8. To decode them, use JavaScript's decodeURIComponent(). When sending the anonymous consents back to the server, use encodeURIComponent(). NOTE that these methods are not available in SSR mode.
When changing a consent's status, the consentState property of the corresponding consent should be changed:
- When giving a consent, the consentState should have GIVEN string value.
- When withdrawing a consent, the consentState should have WITHDRAWN string value.
In order for the server to understand the header that Spartacus is sending, all consents must be sent to the server, regardless of how many consents have changed.
In case an X-Anonymous-Consents header is not sent to the server, and the request is for an anonymous user, the server will respond with all anonymous consents (but their status is going to be set to null)
An Angular's http interceptor (e.g.AnonymousConsentsInterceptor) should handle the exchange of X-Anonymous-Consents header between Spartacus and the server by storing/pulling the consents to/from localStorage. Please, consider the fact that the Window object is not available in SSR mode, thus making the localStorage API also not available in SSR mode.
The language change should not affect the anonymous consents state. The language of the consents should change, but not their consentState properties. An e2e test should cover this case.
The anonymous consents can leverage the processing/loading mechanism in Spartacus which will handle loading, loaded and success flags.
As consents might change on the back-end (e.g. there's an updated version), it might be necessary to check the response header for an updated JSON.

Anonymous consent vs. "cookie" consent

"Cookie" consent is not the topic here, this section is just a clarification.

A quick note about "cookie" being quoted in this section: we're probably not going to use the actual cookies as an authentication method and a way to track user's sessions.

The cookie banner in the old accelerator looks like this:

Looking at the old accelerator implementation, it seems that the "cookie" consent is not implemented using consents per se. "Cookie consent" is just a CMS component that's rendered on a jsp page. The consent text is pulled from a *properties file using a translation key. After giving the consent (or maybe even just closing the cookie banner), a javascript is activated that places a cookie in the browser. There's no actual way of declining the cookie, and the decision is enforced to the user.

We could improve this by leveraging the actual consents:

pull a dedicated consent (could be exposed to anonymous users) with an ID of e.g. STORE_USER_INFORMATION (this requires from clients to put this consent as part of their "sample" data)
the result of the user's consent decision will be stored on the back-end (in case the user is logged in)
we can re-use the consents dialog for showing this "cookie" banner that we will implement as part of the anonymous consents effort
users can easily revoke the STORE_USER_INFORMATION consent from the consent management page

More about the cookie consent issue here.

Useful links

Postman collection
Anonymous consents sample data
wire frames
Visuals
hybris help - anonymous consent management and main user cases
Old accelerator - https://electronics.dev-com-6.accdemo.b2c.ydev.hybris.com:9002/electronics/en/
Back-end issues: https://jira.hybris.com/browse/RAY-214 and https://jira.hybris.com/browse/RAY-222

Tickets

[x] - #4450 Create sample data for anonymous and regular consents
[x] - #3903 Implement facade and store for anonymous consent
[x] - #3896 Implement AnonymousConsentsInterceptor
[x] - #4459 Anonymous consents - handle language change
[x] - #4429 Implement sticky toggle for anonymous consent banner
[x] - #4427 Implement anonymous consents details modal dialog
[x] - #3899 Implement anonymous consents banner
[x] - #3905 Toggle anonymous consent dialog
[x] - #4447 Make anonymous consents general description configurable
[x] - #4831 Style anonymous consent dialog and banner
[x] - #3902 Wire consent from registration page
[x] - #4462 Implement support for a required consent
[x] - #4397 Implement a configurable mechanism to show / hide anonymous consents on consent management page
[x] - #4426 Changes to the consent management page
[x] - #4970 Fix transferring anonymous consents to registered
[x] - #4394 Implement feature level toggle for anonymous consent
[x] - #3900 Write e2e tests for anonymous consents
[x] - #5044 Release
[x] - #4495 Docs
[x] - #4989 Deprecation instructions

znikola commented 5 years ago

Linking spike ticket: #2124

znikola commented 5 years ago

PR: https://github.com/SAP/cloud-commerce-spartacus-storefront/pull/4986/files

maddy619 commented 2 years ago

Really sorry, this is irelevant of this but I was trying using the UserConsentService but i am getting this error core.js:6498 ERROR TypeError: Cannot read properties of undefined (reading 'consents'), and this warning @ngrx/store: The feature name "user" does not exist in the state, therefore createFeatureSelector cannot access it. Be sure it is imported in a loaded module using StoreModule.forRoot('user', ...) or StoreModule.forFeature('user', ...). If the default state is intended to be undefined, as is the case with router state, this development-only warning message can be ignored.

can anyone please help, I have accessed this service in a guard after the login guard

SAP / spartacus

Anonymous Consent [master] #3800