You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: design-documents/cookies.md
+27-25Lines changed: 27 additions & 25 deletions
Original file line number
Diff line number
Diff line change
@@ -5,28 +5,30 @@ Original document: https://docs.magento.com/m2/ce/user_guide/stores/cookie-refer
5
5
The goal of this document is to align cookies existing in Magento to features relying on them, so a customer may choose to disable a feature and not populate a specific cookie.
|`guest-view`| No | Yes | Session |`Magento_Sales`| Guest orders view. Used in "Orders and Returns" widget. |
11
+
|`login_redirect`| No | No | Session |`Magento_Customer`, `Magento_Checkout`| Used in minicart for logged in customers if "Shopping Cart Sidebar" > "Display Shopping Cart Sidebar" is set to "Yes" |
12
+
|`mage-messages`| No | No | Duration: 1 year. Cleared on frontend when the message is displayed to the user. |`Magento_Theme`| No option to disable |
13
+
|`mage-translation-storage` (local storage) | No | No | Per local storage rules |`Magento_Translation`| Used when "Translation Strategy" configured as "Dictionary (Translation on Storefront side)". |
14
+
|`mage-translation-file-version` (local storage) | No | No | Per local storage rules |`Magento_Translation`. | Tracks version of translations in local storage. Used when "Translation Strategy" configured as "Dictionary (Translation on Storefront side)". |
15
+
|`product_data_storage` (local storage) | No | No | Per local storage rules |`Magento_Catalog`||
16
+
|`recently_compared_product` (local storage) | No | No | Per local storage rules |`Magento_Catalog`||
17
+
|`recently_compared_product_previous` (local storage) | No | No | Per local storage rules |`Magento_Catalog`||
18
+
|`recently_viewed_product` (local storage) | No | No | Per local storage rules |`Magento_Catalog`||
19
+
|`recently_viewed_product_previous` (local storage) | No | No | Per local storage rules |`Magento_Catalog`||
|`X-Magento-Vary` (note: original document has typo) | Yes | Yes | Based on PHP setting `session.cookie_lifetime`|`Magento_PageCache`||
22
+
|`amz_auth_err`| No | No | 1 year | Amazon Pay CBE | Used if "Enable Login with Amazon" is enabled. |
23
+
|`amz_auth_logout`| No | No | 86400s (24h) | Amazon Pay CBE | Used if "Enable Login with Amazon" is enabled. |
24
+
|`form_key`| No | No | PHP: based on PHP setting `session.cookie_lifetime`. JS: session | Page Cache ||
25
+
|`mage-cache-sessid`| No | No | Session |`Magento_Customer`, `Magento_Persistent`||
26
+
|`mage-cache-storage` (local storage) | No | No | Per local storage rules |`Magento_Customer`, `Magento_Persistent`, `Magento_NegotiableQuote`||
27
+
|`mage-cache-storage-section-invalidation` (local storage) | No | No | Per local storage rules |`Magento_Customer`||
28
+
|`section_data_ids`| No | No | Session |`Magento_Customer`||
29
+
|`persistent_shopping_cart`| Yes | Yes | Based on Admin configuration in `Persistent Shopping Cart > General Options > Persistence Lifetime (seconds)`|`Magento_Persistent`||
30
+
|`private_content_version`| Yes (based on the request)/No | No | PHP: 1 year/315360000s (10 years); JS: 1 day; JS local storage: per local storage rules (forever) |`Magento_PageCache`, `Magento_Customer`| It is set in multiple places: in PHP, in JS as a cookie, and in JS to local storate |
31
+
|`store`| No | Yes | 1 year |`Magento_Store`||
32
+
|`mage-banners-cache-storage` (local storage) | No | No | Per local storage rules |`Magento_Banner` (Magento Commerce). Description: Local storage for Banner functionality. ||
33
+
34
+
HTTP Only = "Yes (based on the request)" means that the cookie is secure if set during HTTPS request, and unsecure if set during HTTP request.
[Dependabot](https://dependabot.com/) provides a functionality to track dependencies from `composer.json` and create PRs to the tracked repositories.
4
+
But it does not provide a notification mechanism. As [Slack](https://slack.com/) is the most popular corporate messenger and Magento uses it, and has a lot of customizations like bots and applications, it make sense to integrate a notification mechanism about newly created PRs.
5
+
Fortunately, Github already has a [mechanism](https://slack.github.com/) for Slack notifications.
6
+
7
+
In general this schema works like this:
8
+
9
+
10
+
11
+
Dependabot creates a PR with updated dependencies (one PR for one dependency), Github sends a notification to a Slack channel. As Dependabot and Slack are integrated with Github and don't depend on each other, they can be replaced/extended by other tools like [Greenkeeper](https://greenkeeper.io/) and
- Dependabot tracks `composer.json` dependencies for a specified repository
21
+
- For a new versions of dependencies it creates a PR
22
+
- Github built-in mechanism tracks newly created PRs and send a notification to Slack app
23
+
- Github Slack app publishes a message in a channel according to the subscription rules (see Slack Integration section)
24
+
- Custom labels (the default label is `dependencies`) or review assignees
25
+
26
+
## Dependabot Integration
27
+
28
+
Dependabot requires Github authorization and permissions to the needed repositories. Each tracked repository has own configuration. The configuration settings include:
- Filters, like security updates, top-level dependencies
33
+
- Different updating strategies for `composer.json`
34
+
35
+
## Github Slack Integration
36
+
37
+
Github Slack integration also requires authorization and permissions to tracked repositories. Also, Github app should be installed for Slack workspace. More installation details can be found in the [documentation](https://github.com/integrations/slack#installing-the-github-integration-for-slack).
38
+
39
+
Github app provides the following commands to track interested repositories:
40
+
41
+
- issues - Opened or closed issues
42
+
- pulls - New or merged pull requests
43
+
- statuses - Statuses on pull requests
44
+
- commits - New commits on the default branch (usually master)
45
+
- deployments - Updated status on deployments
46
+
- public - A repository switching from private to public
47
+
- releases - Published releases
48
+
- reviews - Pull request reviews
49
+
- comments - New comments on issues and pull requests
50
+
- branches - Created or deleted branches
51
+
- commits:all - All commits pushed to any branch
52
+
53
+
To track PRs with updated dependencies the following command might be used:
54
+
55
+
```bash
56
+
/github subscribe magento/magento pulls
57
+
```
58
+
59
+
Github app will notify about all newly created PRs in subscribed repository. Unfortunately, there is [no a possibility](https://github.com/integrations/slack/issues/384) to track PRs only with specific labels. A separate repository might be used as a temporal solution.
60
+
61
+
## Summary
62
+
63
+
Such schema covers tracking all dependencies from `composer.json`, automatically creates a PR with updated dependency and sends notification to a Slack channel. Also, this solution does not require custom tool or application and hardware resources. The solution does not cover indirect dependencies like MySql, ElasticSearch, etc. which are not specified in `composer.json`.
64
+
65
+
As tracking and notification mechanisms are independent, the more sources can be added in the future (like npm dependencies) and notifications can be send to different sources (like Jira).
We want support distributed deployment of Magento: admin UI, cron, storefront UI, web API, and CLI.
6
+
7
+
Benefits
8
+
* Splitting modules decreases number of dependencies
9
+
* When deploying area specific instances, unnecessary dependencies not loaded and it should improve performance
10
+
* We don't have private interfaces (admin UI, cron) exposed, should improve security
11
+
* It's a step towards splitting monolith into services
12
+
13
+
This proposal solves problem of adding necessary configuration to allow distributed deployment.
14
+
15
+
## Design
16
+
17
+
To distinguish between different instances, we have these options
18
+
19
+
1. Don't add any special information on instances, developer always knows which instance is which.
20
+
2. Introduce marker component packages to mark instances (`magento/admin-ui`, `magento/storefront-ui`, `magento/cron`, etc).
21
+
3. Use projects, if we publish different projects, we can just use them _recommended_.
22
+
23
+
Approaches to specify where extension parts need to be installed
24
+
1. Reuse existing type field in composer configuration. Will need to add more types (`magento2-admin-ui-module`, `magento2-storefront-ui-module`, `magento2-cron-module`, etc).
25
+
26
+
Cons
27
+
* Will not work for specifying on which services extension parts need to be installed
28
+
* Might need require adding configuration on instances to track which extensions installed on the system
29
+
30
+
2. Extend composer configuration _recommended_
31
+
32
+
Modules would define on which instances they need to be installed.
33
+
34
+
CatalogExtensionAdminUi/composer.json
35
+
```
36
+
{
37
+
"name": "vendor/catalog-extension-admin-ui",
38
+
...
39
+
"extra": {
40
+
"instances": [
41
+
"admin-ui"
42
+
]
43
+
}
44
+
}
45
+
```
46
+
47
+
To track which extensions installed on distributedly deployed Magento, developer can add metapackage names in composer.json files on instances.
48
+
49
+
admin-ui-instance/composer.json
50
+
```
51
+
{
52
+
"name": "magento/admin-ui-project",
53
+
"type": "project",
54
+
"require": {
55
+
"vendor/catalog-extension-admin-ui": "*",
56
+
...
57
+
},
58
+
...
59
+
"extra": {
60
+
"extensions": [
61
+
"vendor/catalog-extension"
62
+
]
63
+
}
64
+
}
65
+
```
66
+
67
+
Pros
68
+
* The same approach can be used later to define on which services which extension parts need to be installed.
69
+
70
+
3. If packages named by convention (`vendor/catalog-extension-admin-ui`, `vendor/catalog-extension-storefront-ui`, `vendor/catalog-extension-cron`, etc), developer can figure out where extension parts should be installed by package names.
71
+
72
+
Cons
73
+
* Will not work for specifying on which services extension parts need to be installed
74
+
* Potentially not reliable
75
+
* Might need require adding configuration on instances to track which extensions installed on the system
0 commit comments