On Wed, Jun 25, 2014 at 9:40 AM, Selvaratnam Uthaiyashankar < [email protected]> wrote:
> > > > On Tue, Jun 24, 2014 at 4:21 PM, Sameera Jayasoma <[email protected]> > wrote: > >> We have another alternative to fix this problem. If you implement a >> handler at the transport phase then you have to perform checks for each and >> every request which would not be an elegant solution. >> >> How about checking this during the tenant loading time. We simply do not >> load the tenant if its deactivated. The same logic you've planned to >> implement in the handler, you can put it in the tenant loading code. >> > > > What will happen if the tenant is deactivated after getting loaded? > We need to unload the tenant programmatically and send a cluster message to other nodes to perform the same action. Thanks, Sameera. > > > > >> >> Thanks, >> Sameera. >> >> >> >> >> On Tue, Jun 24, 2014 at 2:34 PM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi All, >>> Here is a brief update on implementation of blocking deactivated tenant >>> requests. >>> >>> *Problem:* >>> Even if we deactivated tenant, still they can access services(APIs, >>> proxy etc) deployed in server. This will effect to multitenanted products. >>> >>> *Suggested solution:* >>> Implement dispatcher and engage it in transport phase. So this >>> dispatcher will check tenants state for each call. Then allow to pass >>> requests coming from active tenants. If request come to service deployed in >>> deactivated tenants space then server will return 403 error with message >>> saying "You are trying to invoke deactivated tenant service" >>> >>> For this i implemented dispatcher in org.wso2.carbon.tenant.dispatcher >>> component(stratos component). It will bundled with stratos common feature. >>> So this dispatcher will be there in most of products as stratos common is >>> a basic feature (available in all products). Here we will be maintaining >>> map to keep tenant id and active/deactivated status(otherwise there would >>> be performance drawback). This map will be cleared in 15 minutes time >>> interval. Also we need to engage this dispatcher by adding configuration to >>> transport phase configurations of axis2.xml file. And we can add this >>> configuration to axis2.xml and keep it commented as we do not need to >>> engage it for default scenario. Any suggestions? >>> >>> Thanks, >>> sanjeewa. >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://sameera.adahas.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
