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
ATC extension is able to bloat pum_alm_pages_viewed cookie so large, server-configured cookie size limits are hit, and 400 Bad Request errors block further visits, until respective cookie is deleted.
It's probably not a good idea to start increasing server request header size limits to arbitrary numbers for this.
This directive gives the server administrator greater control over abnormal client request behavior, which may be useful for avoiding some forms of denial-of-service attacks.
So we should not be arbitrarily increasing this to accommodate pum_alm_pages_viewed.
The text was updated successfully, but these errors were encountered:
I wonder if localStorage might be a better solution?
Maybe? Some questions that come to mind:
I think localStorage is not directly accessible to PHP, but do you need that anyway for this mechanism's purpose - is it JS-only?
Is it OK to grow pum_alm_pages_viewed indefinitely in localStorage?
Can pum_alm_pages_viewed be trimmed regardless of storage mechanism (let's say... last 10.. 50.. xyz pages viewed, user configurable) - or does that make its operation inherenly inaccurate?
Can pum_alm_pages_viewed be trimmed regardless of storage mechanism (let's say... last 10.. 50.. xyz pages viewed, user configurable) - or does that make its operation inherenly inaccurate?
@lkraav This condition is not read by the server, its only ever used in JavaScript. Also for cookies, the maximum size is 4096 bytes, whereas for local storage it's 5MB.
For that reason I think we could feasibly go without limits if it moved to localStorage. Will test it out.
Describe the bug
ATC extension is able to bloat
pum_alm_pages_viewed
cookie so large, server-configured cookie size limits are hit, and 400 Bad Request errors block further visits, until respective cookie is deleted.It's probably not a good idea to start increasing server request header size limits to arbitrary numbers for this.
Site information
Popup Maker version: 1.16.8
Advanced Targeting Conditions: 1.4.6
WordPress version: 6.0.2
PHP version: 7.4.30
Expected behavior
We must not crash the visitor with everbloat risks.
If this level of "everything" tracking is really needed, maybe refactor algo towards LocalStorage?
Current behavior
Visitors hit 400 Bad Request errors because request header size eventually hits server limits.
Steps to reproduce
Errors
Server "400 Bad Request" error
Additional context
So we should not be arbitrarily increasing this to accommodate
pum_alm_pages_viewed
.The text was updated successfully, but these errors were encountered: