Copying an API and copying subscriptions in the process is a conscious decision made by the publisher himself. If he wants to edit visibility or subscribability afterwards, its up-to him to do that. He has the option of blocking existing subscriptions so that only new ones will be allowed.
So I don't think the above reported is a bug. Thanks, NuwanD. On Tue, Oct 21, 2014 at 3:11 PM, Abimaran Kugathasan <[email protected]> wrote: > Even for the 1st option, what will happen to the subscribers of original > API, if that original API got changed it's visibility after published? > > So can't we validate the subscription against visibility of the API when > an API got invoked and send a proper response if that API's visibility was > changed after the subscription? So the end user can be aware of what > happened to the subscription. > > In this case, we don't need to change the existing UI flow, we can let the > publisher to decide whether 'require Re-Subscription' needed or not. > > 1. https://wso2.org/jira/browse/APIMANAGER-2747 > 2. https://wso2.org/jira/browse/APIMANAGER-2748 > > WDYT? > > On Mon, Oct 13, 2014 at 9:59 AM, Lakmali Baminiwatta <[email protected]> > wrote: > >> Hi all, >> >> When we copy an API and create a new version, there is an option as >> 'require Re-subscription' when publishing the new version API. If we >> deselect it, all the existing subscriptions on older APIs get auto >> subscribed on new version API as well. So if the visibility restrictions or >> subscription availability settings are modified on the new API and >> published by deselecting 'require Re-subscription', then there can be >> invalid subscriptions getting added on new API. For example consider below >> steps mentioned in jira[1]. >> >> >> 1.Create an API and make its visibility available to all >> tenants/restricted to the tenant >> 2.Log into store from a user within the same tenant and subscribe to the >> API >> 3.Create a new version of the original API and restrict visibility to a >> role which is not assigned to the user at step 2 >> 4.Publish the new version without the 'Require re-subscription' option. >> -The API is auto subscribed to the user at step 2, even though the >> specified role is not assigned to that user >> >> >> So as a solution we have two options. >> >> 1. If the Visibility or subscription availability setting is changed on a >> new API version compared to original version, then we should not list >> 'require Re-subscription' option. This implies that users MUST re-subscribe >> on such APIs. >> >> 2. Validate each subscriber of existing subscriptions against >> visibility/subscription availability settings of new API version while auto >> subscribing. >> >> In my opinion, option 2 costs lot of validations where we need to get >> subscriber information and check roles/tenant domains of each subscription. >> So proceeding with option 1 seems to be better. >> >> Any thoughts ? >> >> [1] https://wso2.org/jira/browse/APIMANAGER-2748 >> >> Thanks, >> Lakmali >> >> -- >> Lakmali Baminiwatta >> Senior Software Engineer >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> > > > -- > Thanks > Abimaran Kugathasan > > Software Engineer | WSO2 Inc > Data & APIs Technologies Team > Mobile : +94 773922820 > > <http://stackoverflow.com/users/515034> > <http://lk.linkedin.com/in/abimaran> > <http://www.lkabimaran.blogspot.com/> <https://github.com/abimaran> > <https://twitter.com/abimaran> > > -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
