4 Commits

Include renames

Author	SHA1	Message	Date
kristianwindandClaude Opus 5.5	d5d85612bd	1.7.1: security fixes for the checkout and the client IP ... - The discount follows the billing email, the address the order is placed under. The tracked session email used to win, so a guest could post a discounted address to the tracking endpoint and check out under their own, keeping the discount. - Shipping packages carry the matched assignment, so WooCommerce's per-package rate cache no longer reuses rates filtered for a matched address (free shipping, reserved methods) after the email changes. - The anonymous tracking endpoint no longer answers matched: true|false, which let anyone enumerate discounted addresses and domains. - CF-Connecting-IP is believed only from a Cloudflare edge range or a private/loopback proxy. From anyone else it let a direct client pick a new address per request: no REST rate limit, forged audit-log IPs. Smoke tests: 89 assertions (was 73), each fix with its own. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-14 15:11:28 +01:00
kristianwindandClaude Code	0793a1ee82	1.7.0: shipping rule "Only" reserves a method, "Show" no longer does ... Since 1.6.0 "Show" both whitelisted a method for its group and hid it from everybody else. A group shown ordinary methods next to a free one therefore took the ordinary ones away from every stranger, who was left with only the free method. "Only" now carries the reservation; "Show" is just the group's whitelist. Existing show rules are converted to only once on update so the checkout does not change until the shop chooses. Co-Authored-By: Claude Code <[email protected]>	2026-10-02 12:28:45 +02:00
kristianwindandClaude Opus 5	6ef4ee8fe5	1.6.0: a shipping method a group is shown belongs to that group ... Kristian checked out with an address in no group and was offered both free delivery methods set up for the Netic group. Measured on the shop before touching anything: one group, four rules, two of them "show" on the free delivery methods he saw. It was not a regression. A test asserted the behaviour as intended — "an unmatched customer sees every method" — so a "show" rule was a whitelist FOR THE GROUP and nothing more. The plugin did half of what its own description promises: it filtered what the group sees and never reserved anything from anyone else. On a shop that takes money the effect is that free delivery arranged for one company is available to every customer. A method named in any group's show rules is now reserved for the groups that name it. Answering "does it work for other discounts too", which found the hole the first fix left: it did not. A group with NO rules of its own returned every rate untouched, and so did a group carrying only "hide" rules, because neither engages the whitelist — so their members saw another group's reserved methods. Both now have other groups' reserved methods removed. The "never leave the customer without shipping" guard is kept and asserted: a shop that reserved everything it offers must still let an ordinary customer check out, because that failure is worse than the leak. Four assertions, each proven red. Two of them caught my own mistakes rather than the product's: the hide-only fixture originally left nothing for the customer, so the guard fired and returned every rate — which reads exactly like the leak it was written to detect. A third rate makes the behaviour observable. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-22 09:46:48 +02:00
kristianwind	e4a40e53a0	Initial commit: WooCommerce Email Discount Manager plugin	2026-08-23 15:38:14 +02:00