Tuan, thank you for a great component. I couldn’t find the right place to post, so posting here.
I am testing ver. 4.0.0 that I have and I’ve found out an interesting behaviour of upgrade option on the verge of being potentially damaging.
The setup: Suppose we have a subscriber on Plan A. There are upgrade options from Plan A to Plans B, C, D.
I don’t want to confuse a customer with all upgrade options but rather offer them upgrade to Plan D. So I send them an offer via email with a link to plan D (I have a menu item for Plan D created).
Problem #1. If my customer follows the link to Plan D, there they will see full price of Plan D, no upgrade option will be applied. Although the customer is logged in, has active Plan A subscription and is eligible for a discounted upgrade to Plan D.
Problem #2. Ok, I thought. I just feed upgrade number to the link to Plan D. So I send my customer a link: https://my-site/plan-d?upgrade_option_id=8. My customers follows the link and, hey presto, the price is now less – as it should be with upgrade rule. BUT. If any other customer, even a new one (not logged in/registered), follows the same link they will get Plan D with upgrade #8 discount, even though they are not subscribed to Plan A and not even registered!
What’s more, then I found that by changing upgrade_option_id in the link you can buy any plan at the price of any upgrade option available. I.e. if you have Plan A to Plan B upgrade for $10 (let’s assume the number of this upgrade in the system is 1), you can buy any other plan for $10 just by adding ‘?upgrade_option_id=1’ to subscription link. If there is a plan for $1000, you can purchase it for just $10 😊
Effectively it means that on any website using Membership Pro it’s possible to add ?upgrade_option_id=X to the subscription link on subscription page and try numbers from 1 to, say, 20-30 (there shouldn’t be a lot of upgrade options). If you’re lucky you will pay much less as if you were upgrading.
Please, can someone test it on their systems? I did it on localhost to test and prepare for a shift from another subscription component. For a test you need to have at least one upgrade rule for any plan.
I see it as a major flaw or even a bug. Before applying the upgrade there must be verification if the user is logged in and if the user eligible for upgrade (e.g. does the user have Plan A active, is there upgrade option to upgrade to the Plan D and is the user trying to upgrade to Plan D?).
Moreover, for better logic, it makes sense to use upgrade price in a scenario when a user who has an active subscription to Plan A, follows a link to Plan D (which is an upgrade from Plan A). If you are ready to offer upgrade, let it be shown in all situations.
Zeropost
