On Fri, Jun 22, 2012 at 3:13 PM, Lakmali Baminiwatta <[email protected]>wrote:
> Hi Isuru, > > > On Fri, Jun 22, 2012 at 2:58 PM, Isuru Suriarachchi <[email protected]>wrote: > >> >> >> On Fri, Jun 22, 2012 at 2:42 PM, Lakmali Baminiwatta <[email protected]>wrote: >> >>> Hi, >>> >>> On Fri, Jun 22, 2012 at 2:18 PM, Isuru Suriarachchi <[email protected]>wrote: >>> >>>> Lakmali, >>>> >>>> Can you please explain why we need this SuperTenantRolePlayer and why >>>> it always returns false for isUltimateDestination()? Looks like, we can't >>>> always return false here and have to figure out whether this is the >>>> ultimate destination of the message. If the message is going into a tenant, >>>> returning false is ok. But for the super tenant case, it should return >>>> true. In any case, please look into this urgently and fix. This has >>>> introduced a fundamental bug in addressing and RM. >>>> >>> >>> We need to set the SuperTenantRolePlayer to invoke secure services by >>> tenants. This was actually had been a module inside products previously >>> (ex: AS org.wso2.stratos.appserver.deployment) and I just made it common by >>> adding it as a stratos component. This was done as a fix for the issue [1]. >>> >>> Previously this was only added to the services. Now after >>> product-service merging this SuperTenantRolePlayer might be an issue to the >>> products. >>> >> >> Yes, correct.. >> >> >>> Will look in this. >>> >> >> You can fix this either by not registering the Role Player for super >> tenant or by writing the logic inside that method to determine whether it >> is called by the super tenant or not. >> > > Thanks for the suggestions. If we don't register the Role Player for super > tenant, stratos secure services will fail in its super tenant flow while > trying to process must understand fields for security headers. Because the > rampart is engaged for services, only in sub tenants flow. > > So I think we have to take the second approach. > I just looked into this and looks like we can't figure out whether the incoming request is going to a service hosted in super tenant or to a service hosted in a sub tenant. That is because isUltimateDestination() doesn't have the message context or any other information. Therefore we'll have to figure out a proper solution for this. Azeez, have you got any idea? Thanks, ~Isuru > > Thanks, > Lakmali > > >> Thanks, >> ~Isuru >> >> >>> >>> [1] >>> https://wso2.org/jira/browse/STRATOS-1953<https://wso2.org/jira/browse/STRATOS-1953> >>> >>> Thanks, >>> Lakmali >>> >>> >>>> >>>> Thanks, >>>> ~Isuru >>>> >>>> On Fri, Jun 22, 2012 at 1:34 PM, Andun Gunawardena <[email protected]>wrote: >>>> >>>>> Hi All, >>>>> >>>>> I have notified that Sandesha2 module cant be engaged in the >>>>> way which was described in >>>>> [1]<http://wso2.org/project/app-server/4.1.2/docs/commodity_quote_guide.html>. >>>>> In the client side it shows the follwoing error, >>>>> >>>>> ERROR [2012-06-21 12:19:47,991] The endpoint reference (EPR) for the >>>>> Operation not found is and the WSA Action = . If this EPR was previously >>>>> reachable, please contact the server administrator. >>>>> >>>>> When I did a SOAP tracing in AS, I found that the Addressing module is >>>>> not engaged properly in the response SOAP message. That causes the >>>>> Sandesha2 handshaking protocol to crash by not having necessary EPRs. The >>>>> following SOAP message is the SOAP message which was returned to the first >>>>> handshaking SOAP message, and it doesn't have addressing headers. >>>>> >>>>> <soapenv:Envelope xmlns:soapenv=" >>>>> http://www.w3.org/2003/05/soap-envelope";> >>>>> <soapenv:Header /> >>>>> <soapenv:Body> >>>>> <ns:greetResponse xmlns:ns="http://www.wso2.org/types";> >>>>> <return>Hello World, AndunSLG !!!</return> >>>>> </ns:greetResponse> >>>>> </soapenv:Body> >>>>> </soapenv:Envelope> >>>>> >>>>> In the org.apache.axiom.soap.impl.llom.SOAPHeaderImpl class's 127 line >>>>> has the following Boolean check which have to return true for >>>>> the correct excution, >>>>> >>>>> return (rolePlayer == null || rolePlayer.isUltimateDestination()); >>>>> >>>>> But in the current carbon trunk, the rolePlayer object is a instance >>>>> of org.wso2.carbon.stratos.deployment.SuperTenantRolePlayer. It has the >>>>> method isUltimateDestination() implemented as follows, >>>>> >>>>> public boolean isUltimateDestination() { >>>>> return false; >>>>> } >>>>> >>>>> So because of that >>>>> Axis2's org.apache.axis2.handlers.addressing.AddressingInHandler class >>>>> disables the AddressignOutHandler. So no addressing happens at the out >>>>> flow. That causes all the trouble in Addressing and Sandesha2. I put >>>>> return >>>>> true experimentally and that makes all the troubles back to normal. So is >>>>> the implementation of public boolean isUltimateDestination() is correct ? >>>>> >>>>> >>>> >>>> >>>> -- >>>> Isuru Suriarachchi >>>> Senior Technical Lead >>>> WSO2 Inc. http://wso2.com >>>> email : [email protected] >>>> blog : http://isurues.wordpress.com/ >>>> >>>> lean . enterprise . middleware >>>> >>>> >>> >>> >>> -- >>> Lakmali Baminiwatta* >>> * >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> * >>> * >>> >>> >> >> >> -- >> Isuru Suriarachchi >> Senior Technical Lead >> WSO2 Inc. http://wso2.com >> email : [email protected] >> blog : http://isurues.wordpress.com/ >> >> lean . enterprise . middleware >> >> > > > -- > Lakmali Baminiwatta* > * > Software Engineer > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > * > * > > -- Isuru Suriarachchi Senior Technical Lead WSO2 Inc. http://wso2.com email : [email protected] blog : http://isurues.wordpress.com/ lean . enterprise . middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
