The API key that is underprivileged for MSS and Premium
is still considered as valid because the API can still authenticate the key
and the key can be used reporting subscriber stats etc.
I've check places where we use the property and in all cases we use
to distinguish if the plugin uses a subscription plan (free or paid) or no plan.
[MAILPOET-5191]
In case the user uses an API key that has restricted access to MSS
due email volume limit on a fresh site. The site has no cached data about
the limits. We need a variant of the message also for the case.
[MAILPOET-5191]
The values we have in key state might be missing or outdated.
We need to check also if the key check on MSS returned error
about access being restricted due email volume limit.
[MAILPOET-5191]
The limit is stored in and read from MSS key state and now we preserve
state data even when the key becomes underprivileged.
We don't need to refresh anything and also the checking underprivileged key
would return 403 and no data about limits.
[MAILPOET-5191]
Currently the starter plan has no access to premium so the plugin is
not able to fetch email volume limit using premium key endpoint.
Also the data are related to sending so it makes more sense to read those
from MSS key state.
[MAILPOET-5191]
When the shop blocked access for an API key due subscriber limit it used
to set the error as "Insufficient privileges," and that was in the plugin
interpreted same as "Subscribers limit reached".
The SHOP-1228 changes the error message will be set to "Subscribers limit reached".
This commit updates the error mapper to be able to process the new error message.
It also keeps the old approach for previously blocked keys.
[MAILPOET-5191]
The state data contain info about plan limits etc. we don't want
to lose the info when key becomes underprivileged so that we can
show the limits in notifications.
[MAILPOET-5191]
Bridge is a low level service that processes requests and responses to/from Bridge API.
This change is needed so that we can remove dependency on MailPoet\Util\License\Features\Subscribers
service from the Bridge. The dependecy is a higher level service and may easily cause a circular dependency issue.
The SettingsChangeHandler is service for handling side effects
when saving settings. This feels as a better place to put the functionality.
[MAILPOET-5191]
Bridge is a low level service that processes requests and responses to/from Bridge API.
This change is needed so that we can remove dependency on MailPoet\Util\License\Features\Subscribers
service from the Bridge. The dependecy is a higher level service and may easily cause a circular dependency issue.
[MAILPOET-5191]
This is the olny staically called method from the service. In this commit I refactored it to non-static so that it works properly with injected services.
[MAILPOET-5191]
The probability of the routine to run is 5% so it should run approximately 5 times
per 100 writes. So the limit 1000 should be pretty safe to prevent the table from bloating.
[MAILPOET-5071]
This commit changes the way that we are passing data from Twig to JS
variables. Before we were using the raw value of the variable which
could be insecure depending on the source of the variable. Malicious
code could be injected in the variable that would result in JS code
being executed in the browser.
Now we are escaping the value of the variable and then parsing it with
JSON.parse(). This should ensure that whatever is the content of the
Twig variable, it is never possible to inject code that is executed by
the browser.
[MAILPOET-5238]
Before this commit, whenever we needed to output HTML from a function
call in a Twig template, we would use the raw filter that allows any
kind of HTML to be outputted.
This commit adds a new filter called wpKses that internally calls
wp_kses(). We can use this filter instead of raw, this way we can define
the list of allowed HTML and the output becomes more secure.
This commit also replaces all the instances where we were using raw.
[MAILPOET-5238]
In this particular template, using raw was not necessary as the HTML
markup encapsulated the full translatable string. So I removed the call
to raw, and added the HTML markup directly to the template.
[MAILPOET-5238]
I found this file as part of the ticket to investigate Twig templates in
the context of the security scan ([MAILPOET-5238]) as it use the `raw`
filter. It seems this file is not used anymore, so instead of fixing the
use of `raw`, I'm removing it.
As far as I can check, we stopped using this view back in 2016, when
this commit f8efb3934b replaced the homepage
with the newsletter page.
