SAP / spartacus

Spartacus is a lean, Angular-based JavaScript storefront for SAP Commerce Cloud that communicates exclusively through the Commerce REST API.
Apache License 2.0
740 stars 386 forks source link

Anonymous Consent [master] #3800

Closed Xymmer closed 5 years ago

Xymmer commented 5 years ago

Master ticket for implementing Anonymous Consent. Project is https://github.com/SAP/cloud-commerce-spartacus-storefront/projects/35

znikola commented 5 years ago

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:

  1. 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".
  2. 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)].
  3. 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

UI

Pending.

Some WIP wireframes can be seen here.

Changes to the current consents implementation

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.

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:

Screen Shot 2019-08-01 at 14 57 20

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:

More about the cookie consent issue here.

Useful links

Tickets

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