Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Hasanthi Purnima Dissanayake]

Hi Kishanthan,
Please find the requested information for [1] as a jira attchement. Please
consider that I observed this issue only when both proxy context path and
web context root is enabled as I mentioned in the JIRA.

[1] https://wso2.org/jira/browse/CARBON-15475

Thanks

Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com 
M :0718407133| http://wso2.com 

On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah  wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now passing?.
> We will start the next RC build once this is confirmed ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very old PR
>> which we have missed to review and merge. This mainly contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We will
> merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config, example
> requests, HTTP access logs on both LB and IS side with this issue). Will
> send a separate mail on that, but I believe its not a blocker for the IS
> release right?
> [2] and [3], we haven't seen this error previously and according the
> trace, it looks like the "distributedCache" instance is becoming null in
> CacheImpl class. If the exact steps can be found or given on how to
> reproduce this, then we can work on finding the root cause for this.
>
>
>> Thanks,
>> Johann.
>>
>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We are in the process writing the test case for the issue. Should be
>>> able to send it before end of day.
>>>
>>> [1] has been reported in another thread. This issue in particular looks
>>> critical to me, because AFAIK there are many users using proxyContextPath.
>>> Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
>>> [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
>>> coming from kernel and would like to get your thoughts on this if this is
>>> critical and needs to be fixed.
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15475
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> And also it will be great if we can change the default value of
>>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>>> has this enabled needs to test all their functionality well. Therefore what
>>> I suggest is to make it 'false' by default and whatever product that needs
>>> it can enable it at product level. WDYT ? Can we do this ?
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
 Can we also have test case for this fix please?

 On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
 wrote:

> Hi,
>
> This issue is fixed in [1].
>
>
> Thanks
> isura
>
>
> [1] https://wso2.org/jira/browse/CARBON-15517
>
>
> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
> wrote:
>
>> Hi Isura,
>>
>> Can you look into this issue urgently. I remember you fixing an issue
>> related to this.
>>
>> Thanks.
>>
>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>> wrote:
>>
>>> Hi All,
>>>
>>> I debug code of our and found issue. It seems implementation of some
>>> API changed in user-core. Let me explain the flow.
>>>
>>> Our queue/topic creation has two call.
>>>
>>> 1. We create internal role when adding queue and assign
>>> "changePermission", "publish", "consume"  permissions to it. Which means
>>> that, user who created particular queue can update permission, publish 
>>> or
>>> consume.
>>>
>>> - Below code line used to get internal role name:
>>>
>>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>>> queueName.replace(".","-").replace("/", "-"))
>>>
>>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>>> value = {char[21]@10290}
>>> hash = 0
>>> hash32 = 0
>>>
>>> - assign permission as below:
>>>
>>> userStoreManager.addRole(roleName, user, null);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> PERMISSION_CHANGE_PERMISSION);
>>> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Aruna Karunarathna]

On Mon, Oct 19, 2015 at 9:32 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Kishanthan,
> Please find the requested information for [1] as a jira attchement. Please
> consider that I observed this issue only when both proxy context path and
> web context root is enabled as I mentioned in the JIRA.
>

Hi Johann, Hasanthi,

AFAIU the configuration you are using is wrong when using WebContext and
the ProxyContextpath both.

You need to add the *proxy cookie rewrite* URL paths in order to work
correctly. Try adding those parameters.

Regards,
Aruna


>
> [1] https://wso2.org/jira/browse/CARBON-15475
>
> Thanks
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com 
> M :0718407133| http://wso2.com 
>
> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We have added the test case as well to the same PR.
>>>
>>
>> Thanks Johann.
>>
>> @MB Team, could you guys verify that all your scenarios are now
>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>
>>>
>>> Also can we get CARBON-15505 merged? The PR for master is a very old PR
>>> which we have missed to review and merge. This mainly contains some
>>> reordering of fields in the UI to make it more consistent and reorder
>>> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
>>> tests for this.
>>>
>>
>> I think its better not to add any more changes at this stage. We will
>> merge this for next patch release.
>>
>>>
>>> Any update on the 3 issues raised above ?
>>>
>>
>> For [1], we need more information to reproduce (LB & IS config, example
>> requests, HTTP access logs on both LB and IS side with this issue). Will
>> send a separate mail on that, but I believe its not a blocker for the IS
>> release right?
>> [2] and [3], we haven't seen this error previously and according the
>> trace, it looks like the "distributedCache" instance is becoming null in
>> CacheImpl class. If the exact steps can be found or given on how to
>> reproduce this, then we can work on finding the root cause for this.
>>
>>
>>> Thanks,
>>> Johann.
>>>
>>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We are in the process writing the test case for the issue. Should be
 able to send it before end of day.

 [1] has been reported in another thread. This issue in particular looks
 critical to me, because AFAIK there are many users using proxyContextPath.
 Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
 [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
 coming from kernel and would like to get your thoughts on this if this is
 critical and needs to be fixed.

 [1] https://wso2.org/jira/browse/CARBON-15475
 [2] https://wso2.org/jira/browse/IDENTITY-3815
 [3] https://wso2.org/jira/browse/IDENTITY-3817

 And also it will be great if we can change the default value of
 XSSPreventionConfig.Enabled to 'false' because this was added in order to
 prevent XSS centrally, however the approach is not 100% bug free. Whoever
 has this enabled needs to test all their functionality well. Therefore what
 I suggest is to make it 'false' by default and whatever product that needs
 it can enable it at product level. WDYT ? Can we do this ?

 Regards,
 Johann.


 On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

> Can we also have test case for this fix please?
>
> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
> wrote:
>
>> Hi,
>>
>> This issue is fixed in [1].
>>
>>
>> Thanks
>> isura
>>
>>
>> [1] https://wso2.org/jira/browse/CARBON-15517
>>
>>
>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby > > wrote:
>>
>>> Hi Isura,
>>>
>>> Can you look into this issue urgently. I remember you fixing an
>>> issue related to this.
>>>
>>> Thanks.
>>>
>>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>>> wrote:
>>>
 Hi All,

 I debug code of our and found issue. It seems implementation of
 some API changed in user-core. Let me explain the flow.

 Our queue/topic creation has two call.

 1. We create internal role when adding queue and assign
 "changePermission", "publish", "consume"  permissions to it. Which 
 means
 that, user who created particular queue can update permission, publish 
 or
 consume.

 - Below code line used to get internal role 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Pandula,

AFAIK I have seen users using both of these configurations separately, but
not often together. So in that sense I don't think it should be considered
a blocker. This is just my opinion.

Thanks.

On Fri, Oct 16, 2015 at 8:34 PM, Pandula Kariyawasam 
wrote:

> Hi Johann,
>
> Still we are working on to identify the correct nginx config for this
> scenario.
>
> From the QA perspective, we need to get this issue fixed, because if there
> is a customer who will use this scenario, we will end up with a support
> patch.
>
> So, either need to get this fixed on 4.4.2 or have to wait for a fix on
> 4.4.3.
>
> WDYT?
>
> Thanks,
> Pandula
>
> On Fri, Oct 16, 2015 at 6:26 PM, Johann Nallathamby 
> wrote:
>
>> Hi Pandula,
>>
>> Thanks. But actually the JIRA in concern is
>> https://wso2.org/jira/browse/CARBON-15475 . Can you please provide your
>> feedback on this.
>>
>> Thanks.
>>
>> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
>> wrote:
>>
>>> Hi Johann/Kishanthan,
>>>
>>> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
>>> 2015, which was based on kernel 4.4.1.
>>> We didn't experience these issue up to now, on the pack received on 13th
>>> Oct 2015, which is based on kernel 4.4.2.
>>> So I think we can reduce the priority of these issues, and keep eye on
>>> them in latest packs with kernel 4.4.2.
>>>
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> Thanks,
>>> Pandula
>>>
>>>
>>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan,

 On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now
> passing?.  We will start the next RC build once this is confirmed ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very old
>> PR which we have missed to review and merge. This mainly contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't need 
>> any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We will
> merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config,
> example requests, HTTP access logs on both LB and IS side with this 
> issue).
> Will send a separate mail on that, but I believe its not a blocker for the
> IS release right?
>

 I will request Hasanthi to upload the artifacts you requested.

 I may be not the right person to say if this is blocker or not.
 @QA Team, please give your opinion if we can consider this as not a
 blocker and go ahead with the release.

 Regards.


> [2] and [3], we haven't seen this error previously and according the
> trace, it looks like the "distributedCache" instance is becoming null in
> CacheImpl class. If the exact steps can be found or given on how to
> reproduce this, then we can work on finding the root cause for this.
>
>
>> Thanks,
>> Johann.
>>
>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We are in the process writing the test case for the issue. Should be
>>> able to send it before end of day.
>>>
>>> [1] has been reported in another thread. This issue in particular
>>> looks critical to me, because AFAIK there are many users using
>>> proxyContextPath. Not sure about WebContextRoot though. Apart from that
>>> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its 
>>> harmless,
>>> but looks like it is coming from kernel and would like to get your 
>>> thoughts
>>> on this if this is critical and needs to be fixed.
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15475
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> And also it will be great if we can change the default value of
>>> XSSPreventionConfig.Enabled to 'false' because this was added in order 
>>> to
>>> prevent XSS centrally, however the approach is not 100% bug free. 
>>> Whoever
>>> has this enabled needs to test all their functionality well. Therefore 
>>> what
>>> I suggest is to make it 'false' by default and whatever product that 
>>> needs

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Pandula Kariyawasam]

Hi Johann/Kishanthan,

Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
2015, which was based on kernel 4.4.1.
We didn't experience these issue up to now, on the pack received on 13th
Oct 2015, which is based on kernel 4.4.2.
So I think we can reduce the priority of these issues, and keep eye on them
in latest packs with kernel 4.4.2.

[2] https://wso2.org/jira/browse/IDENTITY-3815
[3] https://wso2.org/jira/browse/IDENTITY-3817

Thanks,
Pandula


On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby  wrote:

> Hi Kishanthan,
>
> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We have added the test case as well to the same PR.
>>>
>>
>> Thanks Johann.
>>
>> @MB Team, could you guys verify that all your scenarios are now
>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>
>>>
>>> Also can we get CARBON-15505 merged? The PR for master is a very old PR
>>> which we have missed to review and merge. This mainly contains some
>>> reordering of fields in the UI to make it more consistent and reorder
>>> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
>>> tests for this.
>>>
>>
>> I think its better not to add any more changes at this stage. We will
>> merge this for next patch release.
>>
>>>
>>> Any update on the 3 issues raised above ?
>>>
>>
>> For [1], we need more information to reproduce (LB & IS config, example
>> requests, HTTP access logs on both LB and IS side with this issue). Will
>> send a separate mail on that, but I believe its not a blocker for the IS
>> release right?
>>
>
> I will request Hasanthi to upload the artifacts you requested.
>
> I may be not the right person to say if this is blocker or not.
> @QA Team, please give your opinion if we can consider this as not a
> blocker and go ahead with the release.
>
> Regards.
>
>
>> [2] and [3], we haven't seen this error previously and according the
>> trace, it looks like the "distributedCache" instance is becoming null in
>> CacheImpl class. If the exact steps can be found or given on how to
>> reproduce this, then we can work on finding the root cause for this.
>>
>>
>>> Thanks,
>>> Johann.
>>>
>>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We are in the process writing the test case for the issue. Should be
 able to send it before end of day.

 [1] has been reported in another thread. This issue in particular looks
 critical to me, because AFAIK there are many users using proxyContextPath.
 Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
 [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
 coming from kernel and would like to get your thoughts on this if this is
 critical and needs to be fixed.

 [1] https://wso2.org/jira/browse/CARBON-15475
 [2] https://wso2.org/jira/browse/IDENTITY-3815
 [3] https://wso2.org/jira/browse/IDENTITY-3817

 And also it will be great if we can change the default value of
 XSSPreventionConfig.Enabled to 'false' because this was added in order to
 prevent XSS centrally, however the approach is not 100% bug free. Whoever
 has this enabled needs to test all their functionality well. Therefore what
 I suggest is to make it 'false' by default and whatever product that needs
 it can enable it at product level. WDYT ? Can we do this ?

 Regards,
 Johann.


 On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

> Can we also have test case for this fix please?
>
> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
> wrote:
>
>> Hi,
>>
>> This issue is fixed in [1].
>>
>>
>> Thanks
>> isura
>>
>>
>> [1] https://wso2.org/jira/browse/CARBON-15517
>>
>>
>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby > > wrote:
>>
>>> Hi Isura,
>>>
>>> Can you look into this issue urgently. I remember you fixing an
>>> issue related to this.
>>>
>>> Thanks.
>>>
>>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>>> wrote:
>>>
 Hi All,

 I debug code of our and found issue. It seems implementation of
 some API changed in user-core. Let me explain the flow.

 Our queue/topic creation has two call.

 1. We create internal role when adding queue and assign
 "changePermission", "publish", "consume"  permissions to it. Which 
 means
 that, user who created particular queue can update permission, publish 
 or
 consume.

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Anjana Fernando]

Guys, can we please continue with the next RC quickly, since the DAS
release is waiting for this, and have some hard deadlines. We are planning
on putting an RC next Wednesday, so appreciate if the Kernel 4.4.2 be
available by then.

Cheers,
Anjana.

On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah  wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now passing?.
> We will start the next RC build once this is confirmed ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very old PR
>> which we have missed to review and merge. This mainly contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We will
> merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config, example
> requests, HTTP access logs on both LB and IS side with this issue). Will
> send a separate mail on that, but I believe its not a blocker for the IS
> release right?
> [2] and [3], we haven't seen this error previously and according the
> trace, it looks like the "distributedCache" instance is becoming null in
> CacheImpl class. If the exact steps can be found or given on how to
> reproduce this, then we can work on finding the root cause for this.
>
>
>> Thanks,
>> Johann.
>>
>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We are in the process writing the test case for the issue. Should be
>>> able to send it before end of day.
>>>
>>> [1] has been reported in another thread. This issue in particular looks
>>> critical to me, because AFAIK there are many users using proxyContextPath.
>>> Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
>>> [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
>>> coming from kernel and would like to get your thoughts on this if this is
>>> critical and needs to be fixed.
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15475
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> And also it will be great if we can change the default value of
>>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>>> has this enabled needs to test all their functionality well. Therefore what
>>> I suggest is to make it 'false' by default and whatever product that needs
>>> it can enable it at product level. WDYT ? Can we do this ?
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
 Can we also have test case for this fix please?

 On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
 wrote:

> Hi,
>
> This issue is fixed in [1].
>
>
> Thanks
> isura
>
>
> [1] https://wso2.org/jira/browse/CARBON-15517
>
>
> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
> wrote:
>
>> Hi Isura,
>>
>> Can you look into this issue urgently. I remember you fixing an issue
>> related to this.
>>
>> Thanks.
>>
>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>> wrote:
>>
>>> Hi All,
>>>
>>> I debug code of our and found issue. It seems implementation of some
>>> API changed in user-core. Let me explain the flow.
>>>
>>> Our queue/topic creation has two call.
>>>
>>> 1. We create internal role when adding queue and assign
>>> "changePermission", "publish", "consume"  permissions to it. Which means
>>> that, user who created particular queue can update permission, publish 
>>> or
>>> consume.
>>>
>>> - Below code line used to get internal role name:
>>>
>>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>>> queueName.replace(".","-").replace("/", "-"))
>>>
>>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>>> value = {char[21]@10290}
>>> hash = 0
>>> hash32 = 0
>>>
>>> - assign permission as below:
>>>
>>> userStoreManager.addRole(roleName, user, null);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> PERMISSION_CHANGE_PERMISSION);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> TreeNode.Permission.CONSUME.toString().toLowerCase());
>>> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Sasikala Kottegoda]

Hi all,

We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and no
issues were identified.

Thank you

On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
wrote:

> Hi Johann/Kishanthan,
>
> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
> 2015, which was based on kernel 4.4.1.
> We didn't experience these issue up to now, on the pack received on 13th
> Oct 2015, which is based on kernel 4.4.2.
> So I think we can reduce the priority of these issues, and keep eye on
> them in latest packs with kernel 4.4.2.
>
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> Thanks,
> Pandula
>
>
> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan,
>>
>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We have added the test case as well to the same PR.

>>>
>>> Thanks Johann.
>>>
>>> @MB Team, could you guys verify that all your scenarios are now
>>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>>

 Also can we get CARBON-15505 merged? The PR for master is a very old PR
 which we have missed to review and merge. This mainly contains some
 reordering of fields in the UI to make it more consistent and reorder
 properties in user-mgt.xml to be consistent with UI. Hope we don't need any
 tests for this.

>>>
>>> I think its better not to add any more changes at this stage. We will
>>> merge this for next patch release.
>>>

 Any update on the 3 issues raised above ?

>>>
>>> For [1], we need more information to reproduce (LB & IS config, example
>>> requests, HTTP access logs on both LB and IS side with this issue). Will
>>> send a separate mail on that, but I believe its not a blocker for the IS
>>> release right?
>>>
>>
>> I will request Hasanthi to upload the artifacts you requested.
>>
>> I may be not the right person to say if this is blocker or not.
>> @QA Team, please give your opinion if we can consider this as not a
>> blocker and go ahead with the release.
>>
>> Regards.
>>
>>
>>> [2] and [3], we haven't seen this error previously and according the
>>> trace, it looks like the "distributedCache" instance is becoming null in
>>> CacheImpl class. If the exact steps can be found or given on how to
>>> reproduce this, then we can work on finding the root cause for this.
>>>
>>>
 Thanks,
 Johann.

 On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
 wrote:

> Hi Kishanthan/Kernel Team,
>
> We are in the process writing the test case for the issue. Should be
> able to send it before end of day.
>
> [1] has been reported in another thread. This issue in particular
> looks critical to me, because AFAIK there are many users using
> proxyContextPath. Not sure about WebContextRoot though. Apart from that
> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless,
> but looks like it is coming from kernel and would like to get your 
> thoughts
> on this if this is critical and needs to be fixed.
>
> [1] https://wso2.org/jira/browse/CARBON-15475
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> And also it will be great if we can change the default value of
> XSSPreventionConfig.Enabled to 'false' because this was added in order to
> prevent XSS centrally, however the approach is not 100% bug free. Whoever
> has this enabled needs to test all their functionality well. Therefore 
> what
> I suggest is to make it 'false' by default and whatever product that needs
> it can enable it at product level. WDYT ? Can we do this ?
>
> Regards,
> Johann.
>
>
> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Can we also have test case for this fix please?
>>
>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>> wrote:
>>
>>> Hi,
>>>
>>> This issue is fixed in [1].
>>>
>>>
>>> Thanks
>>> isura
>>>
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15517
>>>
>>>
>>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby <
>>> joh...@wso2.com> wrote:
>>>
 Hi Isura,

 Can you look into this issue urgently. I remember you fixing an
 issue related to this.

 Thanks.

 On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
 wrote:

> Hi All,
>
> I debug code of our and found issue. It seems implementation of
> some API changed in user-core. 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Kishanthan,

On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah  wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now passing?.
> We will start the next RC build once this is confirmed ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very old PR
>> which we have missed to review and merge. This mainly contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We will
> merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config, example
> requests, HTTP access logs on both LB and IS side with this issue). Will
> send a separate mail on that, but I believe its not a blocker for the IS
> release right?
>

I will request Hasanthi to upload the artifacts you requested.

I may be not the right person to say if this is blocker or not.
@QA Team, please give your opinion if we can consider this as not a blocker
and go ahead with the release.

Regards.


> [2] and [3], we haven't seen this error previously and according the
> trace, it looks like the "distributedCache" instance is becoming null in
> CacheImpl class. If the exact steps can be found or given on how to
> reproduce this, then we can work on finding the root cause for this.
>
>
>> Thanks,
>> Johann.
>>
>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We are in the process writing the test case for the issue. Should be
>>> able to send it before end of day.
>>>
>>> [1] has been reported in another thread. This issue in particular looks
>>> critical to me, because AFAIK there are many users using proxyContextPath.
>>> Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
>>> [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
>>> coming from kernel and would like to get your thoughts on this if this is
>>> critical and needs to be fixed.
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15475
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> And also it will be great if we can change the default value of
>>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>>> has this enabled needs to test all their functionality well. Therefore what
>>> I suggest is to make it 'false' by default and whatever product that needs
>>> it can enable it at product level. WDYT ? Can we do this ?
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
 Can we also have test case for this fix please?

 On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
 wrote:

> Hi,
>
> This issue is fixed in [1].
>
>
> Thanks
> isura
>
>
> [1] https://wso2.org/jira/browse/CARBON-15517
>
>
> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
> wrote:
>
>> Hi Isura,
>>
>> Can you look into this issue urgently. I remember you fixing an issue
>> related to this.
>>
>> Thanks.
>>
>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>> wrote:
>>
>>> Hi All,
>>>
>>> I debug code of our and found issue. It seems implementation of some
>>> API changed in user-core. Let me explain the flow.
>>>
>>> Our queue/topic creation has two call.
>>>
>>> 1. We create internal role when adding queue and assign
>>> "changePermission", "publish", "consume"  permissions to it. Which means
>>> that, user who created particular queue can update permission, publish 
>>> or
>>> consume.
>>>
>>> - Below code line used to get internal role name:
>>>
>>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>>> queueName.replace(".","-").replace("/", "-"))
>>>
>>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>>> value = {char[21]@10290}
>>> hash = 0
>>> hash32 = 0
>>>
>>> - assign permission as below:
>>>
>>> userStoreManager.addRole(roleName, user, null);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> PERMISSION_CHANGE_PERMISSION);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> TreeNode.Permission.CONSUME.toString().toLowerCase());
>>> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Kishanthan Thangarajah]

On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
wrote:

> Hi Kishanthan/Kernel Team,
>
> We have added the test case as well to the same PR.
>

Thanks Johann.

@MB Team, could you guys verify that all your scenarios are now passing?.
We will start the next RC build once this is confirmed ASAP.

>
> Also can we get CARBON-15505 merged? The PR for master is a very old PR
> which we have missed to review and merge. This mainly contains some
> reordering of fields in the UI to make it more consistent and reorder
> properties in user-mgt.xml to be consistent with UI. Hope we don't need any
> tests for this.
>

I think its better not to add any more changes at this stage. We will merge
this for next patch release.

>
> Any update on the 3 issues raised above ?
>

For [1], we need more information to reproduce (LB & IS config, example
requests, HTTP access logs on both LB and IS side with this issue). Will
send a separate mail on that, but I believe its not a blocker for the IS
release right?
[2] and [3], we haven't seen this error previously and according the trace,
it looks like the "distributedCache" instance is becoming null in CacheImpl
class. If the exact steps can be found or given on how to reproduce this,
then we can work on finding the root cause for this.


> Thanks,
> Johann.
>
> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We are in the process writing the test case for the issue. Should be able
>> to send it before end of day.
>>
>> [1] has been reported in another thread. This issue in particular looks
>> critical to me, because AFAIK there are many users using proxyContextPath.
>> Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
>> [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
>> coming from kernel and would like to get your thoughts on this if this is
>> critical and needs to be fixed.
>>
>> [1] https://wso2.org/jira/browse/CARBON-15475
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> And also it will be great if we can change the default value of
>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>> has this enabled needs to test all their functionality well. Therefore what
>> I suggest is to make it 'false' by default and whatever product that needs
>> it can enable it at product level. WDYT ? Can we do this ?
>>
>> Regards,
>> Johann.
>>
>>
>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Can we also have test case for this fix please?
>>>
>>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi,

 This issue is fixed in [1].


 Thanks
 isura


 [1] https://wso2.org/jira/browse/CARBON-15517


 On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
 wrote:

> Hi Isura,
>
> Can you look into this issue urgently. I remember you fixing an issue
> related to this.
>
> Thanks.
>
> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
> wrote:
>
>> Hi All,
>>
>> I debug code of our and found issue. It seems implementation of some
>> API changed in user-core. Let me explain the flow.
>>
>> Our queue/topic creation has two call.
>>
>> 1. We create internal role when adding queue and assign
>> "changePermission", "publish", "consume"  permissions to it. Which means
>> that, user who created particular queue can update permission, publish or
>> consume.
>>
>> - Below code line used to get internal role name:
>>
>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>> queueName.replace(".","-").replace("/", "-"))
>>
>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>> value = {char[21]@10290}
>> hash = 0
>> hash32 = 0
>>
>> - assign permission as below:
>>
>> userStoreManager.addRole(roleName, user, null);
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> PERMISSION_CHANGE_PERMISSION);
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> TreeNode.Permission.CONSUME.toString().toLowerCase());
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> TreeNode.Permission.PUBLISH.toString().toLowerCase());
>>
>> 2. User can select some other role listed in in queue add page. He
>> can select these role when adding queue or later by updating queue. So in
>> update permission we checked whether any of user's role has above assign
>> change permission.
>>
>> - get role list of user:
>>
>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)
>>

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

Or can we remove this required features section? since this will limit us
to do releases on limited version range if we are using specific kernel
version?

Thanks,

On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana  wrote:

> [+Kishanthan]
>
> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
> wrote:
>
>> Hi Kishanthan,
>>
>> In "org.wso2.carbon.application.deployer" component's
>> "required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
>> as "org.wso2.carbon.dataservices.server.feature.group" required version
>> range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
>> fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?
>>
>> Thanks,
>>
>> On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda 
>> wrote:
>>
>>> Hi all,
>>>
>>> We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and
>>> no issues were identified.
>>>
>>> Thank you
>>>
>>> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
>>> wrote:
>>>
 Hi Johann/Kishanthan,

 Both issue [2][3] were observed rarely on IS510 pack received on 8th
 Oct 2015, which was based on kernel 4.4.1.
 We didn't experience these issue up to now, on the pack received on
 13th Oct 2015, which is based on kernel 4.4.2.
 So I think we can reduce the priority of these issues, and keep eye on
 them in latest packs with kernel 4.4.2.

 [2] https://wso2.org/jira/browse/IDENTITY-3815
 [3] https://wso2.org/jira/browse/IDENTITY-3817

 Thanks,
 Pandula


 On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
 wrote:

> Hi Kishanthan,
>
> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>>
>>
>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby > > wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We have added the test case as well to the same PR.
>>>
>>
>> Thanks Johann.
>>
>> @MB Team, could you guys verify that all your scenarios are now
>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>
>>>
>>> Also can we get CARBON-15505 merged? The PR for master is a very old
>>> PR which we have missed to review and merge. This mainly contains some
>>> reordering of fields in the UI to make it more consistent and reorder
>>> properties in user-mgt.xml to be consistent with UI. Hope we don't need 
>>> any
>>> tests for this.
>>>
>>
>> I think its better not to add any more changes at this stage. We will
>> merge this for next patch release.
>>
>>>
>>> Any update on the 3 issues raised above ?
>>>
>>
>> For [1], we need more information to reproduce (LB & IS config,
>> example requests, HTTP access logs on both LB and IS side with this 
>> issue).
>> Will send a separate mail on that, but I believe its not a blocker for 
>> the
>> IS release right?
>>
>
> I will request Hasanthi to upload the artifacts you requested.
>
> I may be not the right person to say if this is blocker or not.
> @QA Team, please give your opinion if we can consider this as not a
> blocker and go ahead with the release.
>
> Regards.
>
>
>> [2] and [3], we haven't seen this error previously and according the
>> trace, it looks like the "distributedCache" instance is becoming null in
>> CacheImpl class. If the exact steps can be found or given on how to
>> reproduce this, then we can work on finding the root cause for this.
>>
>>
>>> Thanks,
>>> Johann.
>>>
>>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby >> > wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We are in the process writing the test case for the issue. Should
 be able to send it before end of day.

 [1] has been reported in another thread. This issue in particular
 looks critical to me, because AFAIK there are many users using
 proxyContextPath. Not sure about WebContextRoot though. Apart from that
 WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its 
 harmless,
 but looks like it is coming from kernel and would like to get your 
 thoughts
 on this if this is critical and needs to be fixed.

 [1] https://wso2.org/jira/browse/CARBON-15475
 [2] https://wso2.org/jira/browse/IDENTITY-3815
 [3] https://wso2.org/jira/browse/IDENTITY-3817

 And also it will be great if we can change the default value of
 XSSPreventionConfig.Enabled to 'false' because this was added in order 
 to
 prevent XSS centrally, however the approach is not 100% bug free. 
 Whoever
 has this enabled needs to 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Pandula,

Thanks. But actually the JIRA in concern is
https://wso2.org/jira/browse/CARBON-15475 . Can you please provide your
feedback on this.

Thanks.

On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
wrote:

> Hi Johann/Kishanthan,
>
> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
> 2015, which was based on kernel 4.4.1.
> We didn't experience these issue up to now, on the pack received on 13th
> Oct 2015, which is based on kernel 4.4.2.
> So I think we can reduce the priority of these issues, and keep eye on
> them in latest packs with kernel 4.4.2.
>
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> Thanks,
> Pandula
>
>
> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan,
>>
>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We have added the test case as well to the same PR.

>>>
>>> Thanks Johann.
>>>
>>> @MB Team, could you guys verify that all your scenarios are now
>>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>>

 Also can we get CARBON-15505 merged? The PR for master is a very old PR
 which we have missed to review and merge. This mainly contains some
 reordering of fields in the UI to make it more consistent and reorder
 properties in user-mgt.xml to be consistent with UI. Hope we don't need any
 tests for this.

>>>
>>> I think its better not to add any more changes at this stage. We will
>>> merge this for next patch release.
>>>

 Any update on the 3 issues raised above ?

>>>
>>> For [1], we need more information to reproduce (LB & IS config, example
>>> requests, HTTP access logs on both LB and IS side with this issue). Will
>>> send a separate mail on that, but I believe its not a blocker for the IS
>>> release right?
>>>
>>
>> I will request Hasanthi to upload the artifacts you requested.
>>
>> I may be not the right person to say if this is blocker or not.
>> @QA Team, please give your opinion if we can consider this as not a
>> blocker and go ahead with the release.
>>
>> Regards.
>>
>>
>>> [2] and [3], we haven't seen this error previously and according the
>>> trace, it looks like the "distributedCache" instance is becoming null in
>>> CacheImpl class. If the exact steps can be found or given on how to
>>> reproduce this, then we can work on finding the root cause for this.
>>>
>>>
 Thanks,
 Johann.

 On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
 wrote:

> Hi Kishanthan/Kernel Team,
>
> We are in the process writing the test case for the issue. Should be
> able to send it before end of day.
>
> [1] has been reported in another thread. This issue in particular
> looks critical to me, because AFAIK there are many users using
> proxyContextPath. Not sure about WebContextRoot though. Apart from that
> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless,
> but looks like it is coming from kernel and would like to get your 
> thoughts
> on this if this is critical and needs to be fixed.
>
> [1] https://wso2.org/jira/browse/CARBON-15475
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> And also it will be great if we can change the default value of
> XSSPreventionConfig.Enabled to 'false' because this was added in order to
> prevent XSS centrally, however the approach is not 100% bug free. Whoever
> has this enabled needs to test all their functionality well. Therefore 
> what
> I suggest is to make it 'false' by default and whatever product that needs
> it can enable it at product level. WDYT ? Can we do this ?
>
> Regards,
> Johann.
>
>
> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Can we also have test case for this fix please?
>>
>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>> wrote:
>>
>>> Hi,
>>>
>>> This issue is fixed in [1].
>>>
>>>
>>> Thanks
>>> isura
>>>
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15517
>>>
>>>
>>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby <
>>> joh...@wso2.com> wrote:
>>>
 Hi Isura,

 Can you look into this issue urgently. I remember you fixing an
 issue related to this.

 Thanks.

 On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
 wrote:

> Hi All,
>
> I debug code of our and found issue. It seems implementation of

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Manuri Amaya Perera]

Hi all,

We are calling this vote off due to [1] and will start a new vote for Kernel
 4.4.2 RC3 release.

[1] https://wso2.org/jira/browse/CARBON-15517

Thank you

On Fri, Oct 16, 2015 at 5:31 PM, Rajith Vitharana  wrote:

> Hi Kishanthan,
>
> Tested this by editing the jar file manually with(version range in
> "required-features.xml" file) "[4.3.0,5.0.0)" and it works fine.
>
> Thanks,
>
> On Fri, Oct 16, 2015 at 5:29 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> I think making this as [4.3.0, 5.0.0) is the correct solution from kernel
>> side. This file ideally should not be part of kernel, but its there due to
>> "DefaultAppDeployer" is the one which deploys data-services and this class
>> is in currently in kernel code base.
>>
>> @Rajith, could you quickly test this locally and see? We will change the
>> version range on this file as above, and in long time, we will see whether
>> we could remove this file from kernel code base.
>>
>> On Fri, Oct 16, 2015 at 4:38 PM, Rajith Vitharana 
>> wrote:
>>
>>> Or can we remove this required features section? since this will limit
>>> us to do releases on limited version range if we are using specific kernel
>>> version?
>>>
>>> Thanks,
>>>
>>> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
>>> wrote:
>>>
 [+Kishanthan]

 On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
 wrote:

> Hi Kishanthan,
>
> In "org.wso2.carbon.application.deployer" component's
> "required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
> as "org.wso2.carbon.dataservices.server.feature.group" required version
> range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
> fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?
>
> Thanks,
>
> On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda  > wrote:
>
>> Hi all,
>>
>> We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes
>> and no issues were identified.
>>
>> Thank you
>>
>> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam <
>> pand...@wso2.com> wrote:
>>
>>> Hi Johann/Kishanthan,
>>>
>>> Both issue [2][3] were observed rarely on IS510 pack received on 8th
>>> Oct 2015, which was based on kernel 4.4.1.
>>> We didn't experience these issue up to now, on the pack received on
>>> 13th Oct 2015, which is based on kernel 4.4.2.
>>> So I think we can reduce the priority of these issues, and keep eye
>>> on them in latest packs with kernel 4.4.2.
>>>
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> Thanks,
>>> Pandula
>>>
>>>
>>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby >> > wrote:
>>>
 Hi Kishanthan,

 On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now
> passing?.  We will start the next RC build once this is confirmed 
> ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very
>> old PR which we have missed to review and merge. This mainly 
>> contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't 
>> need any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We
> will merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config,
> example requests, HTTP access logs on both LB and IS side with this 
> issue).
> Will send a separate mail on that, but I believe its not a blocker 
> for the
> IS release right?
>

 I will request Hasanthi to upload the artifacts you requested.

 I may be not the right person to say if this is blocker or not.
 @QA Team, please give your opinion if we can consider this as not a
 blocker and go ahead with the release.

 Regards.


> [2] and [3], we haven't seen this error previously and according
> the trace, it looks like the "distributedCache" instance is becoming 
> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

Hi Kishanthan,

Tested this by editing the jar file manually with(version range in
"required-features.xml" file) "[4.3.0,5.0.0)" and it works fine.

Thanks,

On Fri, Oct 16, 2015 at 5:29 PM, Kishanthan Thangarajah  wrote:

> I think making this as [4.3.0, 5.0.0) is the correct solution from kernel
> side. This file ideally should not be part of kernel, but its there due to
> "DefaultAppDeployer" is the one which deploys data-services and this class
> is in currently in kernel code base.
>
> @Rajith, could you quickly test this locally and see? We will change the
> version range on this file as above, and in long time, we will see whether
> we could remove this file from kernel code base.
>
> On Fri, Oct 16, 2015 at 4:38 PM, Rajith Vitharana 
> wrote:
>
>> Or can we remove this required features section? since this will limit us
>> to do releases on limited version range if we are using specific kernel
>> version?
>>
>> Thanks,
>>
>> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
>> wrote:
>>
>>> [+Kishanthan]
>>>
>>> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
>>> wrote:
>>>
 Hi Kishanthan,

 In "org.wso2.carbon.application.deployer" component's
 "required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
 as "org.wso2.carbon.dataservices.server.feature.group" required version
 range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
 fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?

 Thanks,

 On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda 
 wrote:

> Hi all,
>
> We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and
> no issues were identified.
>
> Thank you
>
> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam  > wrote:
>
>> Hi Johann/Kishanthan,
>>
>> Both issue [2][3] were observed rarely on IS510 pack received on 8th
>> Oct 2015, which was based on kernel 4.4.1.
>> We didn't experience these issue up to now, on the pack received on
>> 13th Oct 2015, which is based on kernel 4.4.2.
>> So I think we can reduce the priority of these issues, and keep eye
>> on them in latest packs with kernel 4.4.2.
>>
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> Thanks,
>> Pandula
>>
>>
>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan,
>>>
>>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>


 On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby <
 joh...@wso2.com> wrote:

> Hi Kishanthan/Kernel Team,
>
> We have added the test case as well to the same PR.
>

 Thanks Johann.

 @MB Team, could you guys verify that all your scenarios are now
 passing?.  We will start the next RC build once this is confirmed ASAP.

>
> Also can we get CARBON-15505 merged? The PR for master is a very
> old PR which we have missed to review and merge. This mainly contains 
> some
> reordering of fields in the UI to make it more consistent and reorder
> properties in user-mgt.xml to be consistent with UI. Hope we don't 
> need any
> tests for this.
>

 I think its better not to add any more changes at this stage. We
 will merge this for next patch release.

>
> Any update on the 3 issues raised above ?
>

 For [1], we need more information to reproduce (LB & IS config,
 example requests, HTTP access logs on both LB and IS side with this 
 issue).
 Will send a separate mail on that, but I believe its not a blocker for 
 the
 IS release right?

>>>
>>> I will request Hasanthi to upload the artifacts you requested.
>>>
>>> I may be not the right person to say if this is blocker or not.
>>> @QA Team, please give your opinion if we can consider this as not a
>>> blocker and go ahead with the release.
>>>
>>> Regards.
>>>
>>>
 [2] and [3], we haven't seen this error previously and according
 the trace, it looks like the "distributedCache" instance is becoming 
 null
 in CacheImpl class. If the exact steps can be found or given on how to
 reproduce this, then we can work on finding the root cause for this.


> Thanks,
> Johann.
>
> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Kishanthan Thangarajah]

I think making this as [4.3.0, 5.0.0) is the correct solution from kernel
side. This file ideally should not be part of kernel, but its there due to
"DefaultAppDeployer" is the one which deploys data-services and this class
is in currently in kernel code base.

@Rajith, could you quickly test this locally and see? We will change the
version range on this file as above, and in long time, we will see whether
we could remove this file from kernel code base.

On Fri, Oct 16, 2015 at 4:38 PM, Rajith Vitharana  wrote:

> Or can we remove this required features section? since this will limit us
> to do releases on limited version range if we are using specific kernel
> version?
>
> Thanks,
>
> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
> wrote:
>
>> [+Kishanthan]
>>
>> On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana 
>> wrote:
>>
>>> Hi Kishanthan,
>>>
>>> In "org.wso2.carbon.application.deployer" component's
>>> "required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
>>> as "org.wso2.carbon.dataservices.server.feature.group" required version
>>> range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
>>> fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?
>>>
>>> Thanks,
>>>
>>> On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda 
>>> wrote:
>>>
 Hi all,

 We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and
 no issues were identified.

 Thank you

 On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
 wrote:

> Hi Johann/Kishanthan,
>
> Both issue [2][3] were observed rarely on IS510 pack received on 8th
> Oct 2015, which was based on kernel 4.4.1.
> We didn't experience these issue up to now, on the pack received on
> 13th Oct 2015, which is based on kernel 4.4.2.
> So I think we can reduce the priority of these issues, and keep eye on
> them in latest packs with kernel 4.4.2.
>
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> Thanks,
> Pandula
>
>
> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan,
>>
>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby <
>>> joh...@wso2.com> wrote:
>>>
 Hi Kishanthan/Kernel Team,

 We have added the test case as well to the same PR.

>>>
>>> Thanks Johann.
>>>
>>> @MB Team, could you guys verify that all your scenarios are now
>>> passing?.  We will start the next RC build once this is confirmed ASAP.
>>>

 Also can we get CARBON-15505 merged? The PR for master is a very
 old PR which we have missed to review and merge. This mainly contains 
 some
 reordering of fields in the UI to make it more consistent and reorder
 properties in user-mgt.xml to be consistent with UI. Hope we don't 
 need any
 tests for this.

>>>
>>> I think its better not to add any more changes at this stage. We
>>> will merge this for next patch release.
>>>

 Any update on the 3 issues raised above ?

>>>
>>> For [1], we need more information to reproduce (LB & IS config,
>>> example requests, HTTP access logs on both LB and IS side with this 
>>> issue).
>>> Will send a separate mail on that, but I believe its not a blocker for 
>>> the
>>> IS release right?
>>>
>>
>> I will request Hasanthi to upload the artifacts you requested.
>>
>> I may be not the right person to say if this is blocker or not.
>> @QA Team, please give your opinion if we can consider this as not a
>> blocker and go ahead with the release.
>>
>> Regards.
>>
>>
>>> [2] and [3], we haven't seen this error previously and according the
>>> trace, it looks like the "distributedCache" instance is becoming null in
>>> CacheImpl class. If the exact steps can be found or given on how to
>>> reproduce this, then we can work on finding the root cause for this.
>>>
>>>
 Thanks,
 Johann.

 On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby <
 joh...@wso2.com> wrote:

> Hi Kishanthan/Kernel Team,
>
> We are in the process writing the test case for the issue. Should
> be able to send it before end of day.
>
> [1] has been reported in another thread. This issue in particular
> looks critical to me, because AFAIK there are many users using
> proxyContextPath. Not sure about WebContextRoot though. Apart from 
> that
> WSO2 QA has reported [2,3] 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

Hi Kishanthan,

In "org.wso2.carbon.application.deployer" component's
"required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
as "org.wso2.carbon.dataservices.server.feature.group" required version
range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?

Thanks,

On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda 
wrote:

> Hi all,
>
> We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and no
> issues were identified.
>
> Thank you
>
> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
> wrote:
>
>> Hi Johann/Kishanthan,
>>
>> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
>> 2015, which was based on kernel 4.4.1.
>> We didn't experience these issue up to now, on the pack received on 13th
>> Oct 2015, which is based on kernel 4.4.2.
>> So I think we can reduce the priority of these issues, and keep eye on
>> them in latest packs with kernel 4.4.2.
>>
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> Thanks,
>> Pandula
>>
>>
>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan,
>>>
>>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>


 On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
 wrote:

> Hi Kishanthan/Kernel Team,
>
> We have added the test case as well to the same PR.
>

 Thanks Johann.

 @MB Team, could you guys verify that all your scenarios are now
 passing?.  We will start the next RC build once this is confirmed ASAP.

>
> Also can we get CARBON-15505 merged? The PR for master is a very old
> PR which we have missed to review and merge. This mainly contains some
> reordering of fields in the UI to make it more consistent and reorder
> properties in user-mgt.xml to be consistent with UI. Hope we don't need 
> any
> tests for this.
>

 I think its better not to add any more changes at this stage. We will
 merge this for next patch release.

>
> Any update on the 3 issues raised above ?
>

 For [1], we need more information to reproduce (LB & IS config, example
 requests, HTTP access logs on both LB and IS side with this issue). Will
 send a separate mail on that, but I believe its not a blocker for the IS
 release right?

>>>
>>> I will request Hasanthi to upload the artifacts you requested.
>>>
>>> I may be not the right person to say if this is blocker or not.
>>> @QA Team, please give your opinion if we can consider this as not a
>>> blocker and go ahead with the release.
>>>
>>> Regards.
>>>
>>>
 [2] and [3], we haven't seen this error previously and according the
 trace, it looks like the "distributedCache" instance is becoming null in
 CacheImpl class. If the exact steps can be found or given on how to
 reproduce this, then we can work on finding the root cause for this.


> Thanks,
> Johann.
>
> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We are in the process writing the test case for the issue. Should be
>> able to send it before end of day.
>>
>> [1] has been reported in another thread. This issue in particular
>> looks critical to me, because AFAIK there are many users using
>> proxyContextPath. Not sure about WebContextRoot though. Apart from that
>> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its 
>> harmless,
>> but looks like it is coming from kernel and would like to get your 
>> thoughts
>> on this if this is critical and needs to be fixed.
>>
>> [1] https://wso2.org/jira/browse/CARBON-15475
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> And also it will be great if we can change the default value of
>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>> has this enabled needs to test all their functionality well. Therefore 
>> what
>> I suggest is to make it 'false' by default and whatever product that 
>> needs
>> it can enable it at product level. WDYT ? Can we do this ?
>>
>> Regards,
>> Johann.
>>
>>
>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Can we also have test case for this fix please?
>>>
>>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi,

 This issue is fixed in [1].


 Thanks
 isura

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

[+Kishanthan]

On Fri, Oct 16, 2015 at 4:35 PM, Rajith Vitharana  wrote:

> Hi Kishanthan,
>
> In "org.wso2.carbon.application.deployer" component's
> "required-features.xml" it was mentioned "[4.4.0, 4.5.0)"
> as "org.wso2.carbon.dataservices.server.feature.group" required version
> range, since we(carbon-data) are still on 4.3.3-SNAPSHOT, capp deployment
> fails in DSS latest, Can we change this version range to "[4.3.0,4.5.0)"?
>
> Thanks,
>
> On Fri, Oct 16, 2015 at 4:29 PM, Sasikala Kottegoda 
> wrote:
>
>> Hi all,
>>
>> We tested MB 3.0.0 with kernel 4.4.2-RC2 with the additional fixes and no
>> issues were identified.
>>
>> Thank you
>>
>> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
>> wrote:
>>
>>> Hi Johann/Kishanthan,
>>>
>>> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
>>> 2015, which was based on kernel 4.4.1.
>>> We didn't experience these issue up to now, on the pack received on 13th
>>> Oct 2015, which is based on kernel 4.4.2.
>>> So I think we can reduce the priority of these issues, and keep eye on
>>> them in latest packs with kernel 4.4.2.
>>>
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> Thanks,
>>> Pandula
>>>
>>>
>>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Kishanthan,

 On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

>
>
> On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We have added the test case as well to the same PR.
>>
>
> Thanks Johann.
>
> @MB Team, could you guys verify that all your scenarios are now
> passing?.  We will start the next RC build once this is confirmed ASAP.
>
>>
>> Also can we get CARBON-15505 merged? The PR for master is a very old
>> PR which we have missed to review and merge. This mainly contains some
>> reordering of fields in the UI to make it more consistent and reorder
>> properties in user-mgt.xml to be consistent with UI. Hope we don't need 
>> any
>> tests for this.
>>
>
> I think its better not to add any more changes at this stage. We will
> merge this for next patch release.
>
>>
>> Any update on the 3 issues raised above ?
>>
>
> For [1], we need more information to reproduce (LB & IS config,
> example requests, HTTP access logs on both LB and IS side with this 
> issue).
> Will send a separate mail on that, but I believe its not a blocker for the
> IS release right?
>

 I will request Hasanthi to upload the artifacts you requested.

 I may be not the right person to say if this is blocker or not.
 @QA Team, please give your opinion if we can consider this as not a
 blocker and go ahead with the release.

 Regards.


> [2] and [3], we haven't seen this error previously and according the
> trace, it looks like the "distributedCache" instance is becoming null in
> CacheImpl class. If the exact steps can be found or given on how to
> reproduce this, then we can work on finding the root cause for this.
>
>
>> Thanks,
>> Johann.
>>
>> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan/Kernel Team,
>>>
>>> We are in the process writing the test case for the issue. Should be
>>> able to send it before end of day.
>>>
>>> [1] has been reported in another thread. This issue in particular
>>> looks critical to me, because AFAIK there are many users using
>>> proxyContextPath. Not sure about WebContextRoot though. Apart from that
>>> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its 
>>> harmless,
>>> but looks like it is coming from kernel and would like to get your 
>>> thoughts
>>> on this if this is critical and needs to be fixed.
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15475
>>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>>
>>> And also it will be great if we can change the default value of
>>> XSSPreventionConfig.Enabled to 'false' because this was added in order 
>>> to
>>> prevent XSS centrally, however the approach is not 100% bug free. 
>>> Whoever
>>> has this enabled needs to test all their functionality well. Therefore 
>>> what
>>> I suggest is to make it 'false' by default and whatever product that 
>>> needs
>>> it can enable it at product level. WDYT ? Can we do this ?
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Pandula Kariyawasam]

Hi Johann,

Still we are working on to identify the correct nginx config for this
scenario.

>From the QA perspective, we need to get this issue fixed, because if there
is a customer who will use this scenario, we will end up with a support
patch.

So, either need to get this fixed on 4.4.2 or have to wait for a fix on
4.4.3.

WDYT?

Thanks,
Pandula

On Fri, Oct 16, 2015 at 6:26 PM, Johann Nallathamby  wrote:

> Hi Pandula,
>
> Thanks. But actually the JIRA in concern is
> https://wso2.org/jira/browse/CARBON-15475 . Can you please provide your
> feedback on this.
>
> Thanks.
>
> On Fri, Oct 16, 2015 at 4:03 PM, Pandula Kariyawasam 
> wrote:
>
>> Hi Johann/Kishanthan,
>>
>> Both issue [2][3] were observed rarely on IS510 pack received on 8th Oct
>> 2015, which was based on kernel 4.4.1.
>> We didn't experience these issue up to now, on the pack received on 13th
>> Oct 2015, which is based on kernel 4.4.2.
>> So I think we can reduce the priority of these issues, and keep eye on
>> them in latest packs with kernel 4.4.2.
>>
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> Thanks,
>> Pandula
>>
>>
>> On Fri, Oct 16, 2015 at 3:09 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Kishanthan,
>>>
>>> On Fri, Oct 16, 2015 at 2:38 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>


 On Fri, Oct 16, 2015 at 11:27 AM, Johann Nallathamby 
 wrote:

> Hi Kishanthan/Kernel Team,
>
> We have added the test case as well to the same PR.
>

 Thanks Johann.

 @MB Team, could you guys verify that all your scenarios are now
 passing?.  We will start the next RC build once this is confirmed ASAP.

>
> Also can we get CARBON-15505 merged? The PR for master is a very old
> PR which we have missed to review and merge. This mainly contains some
> reordering of fields in the UI to make it more consistent and reorder
> properties in user-mgt.xml to be consistent with UI. Hope we don't need 
> any
> tests for this.
>

 I think its better not to add any more changes at this stage. We will
 merge this for next patch release.

>
> Any update on the 3 issues raised above ?
>

 For [1], we need more information to reproduce (LB & IS config, example
 requests, HTTP access logs on both LB and IS side with this issue). Will
 send a separate mail on that, but I believe its not a blocker for the IS
 release right?

>>>
>>> I will request Hasanthi to upload the artifacts you requested.
>>>
>>> I may be not the right person to say if this is blocker or not.
>>> @QA Team, please give your opinion if we can consider this as not a
>>> blocker and go ahead with the release.
>>>
>>> Regards.
>>>
>>>
 [2] and [3], we haven't seen this error previously and according the
 trace, it looks like the "distributedCache" instance is becoming null in
 CacheImpl class. If the exact steps can be found or given on how to
 reproduce this, then we can work on finding the root cause for this.


> Thanks,
> Johann.
>
> On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby 
> wrote:
>
>> Hi Kishanthan/Kernel Team,
>>
>> We are in the process writing the test case for the issue. Should be
>> able to send it before end of day.
>>
>> [1] has been reported in another thread. This issue in particular
>> looks critical to me, because AFAIK there are many users using
>> proxyContextPath. Not sure about WebContextRoot though. Apart from that
>> WSO2 QA has reported [2,3] in IS 5.1.0 SNAPSHOT pack. May be its 
>> harmless,
>> but looks like it is coming from kernel and would like to get your 
>> thoughts
>> on this if this is critical and needs to be fixed.
>>
>> [1] https://wso2.org/jira/browse/CARBON-15475
>> [2] https://wso2.org/jira/browse/IDENTITY-3815
>> [3] https://wso2.org/jira/browse/IDENTITY-3817
>>
>> And also it will be great if we can change the default value of
>> XSSPreventionConfig.Enabled to 'false' because this was added in order to
>> prevent XSS centrally, however the approach is not 100% bug free. Whoever
>> has this enabled needs to test all their functionality well. Therefore 
>> what
>> I suggest is to make it 'false' by default and whatever product that 
>> needs
>> it can enable it at product level. WDYT ? Can we do this ?
>>
>> Regards,
>> Johann.
>>
>>
>> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Can we also have test case for this fix please?
>>>
>>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi,

 This issue is fixed in [1].

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Kishanthan/Kernel Team,

We are in the process writing the test case for the issue. Should be able
to send it before end of day.

[1] has been reported in another thread. This issue in particular looks
critical to me, because AFAIK there are many users using proxyContextPath.
Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
[2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
coming from kernel and would like to get your thoughts on this if this is
critical and needs to be fixed.

[1] https://wso2.org/jira/browse/CARBON-15475
[2] https://wso2.org/jira/browse/IDENTITY-3815
[3] https://wso2.org/jira/browse/IDENTITY-3817

And also it will be great if we can change the default value of
XSSPreventionConfig.Enabled to 'false' because this was added in order to
prevent XSS centrally, however the approach is not 100% bug free. Whoever
has this enabled needs to test all their functionality well. Therefore what
I suggest is to make it 'false' by default and whatever product that needs
it can enable it at product level. WDYT ? Can we do this ?

Regards,
Johann.


On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah  wrote:

> Can we also have test case for this fix please?
>
> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne  wrote:
>
>> Hi,
>>
>> This issue is fixed in [1].
>>
>>
>> Thanks
>> isura
>>
>>
>> [1] https://wso2.org/jira/browse/CARBON-15517
>>
>>
>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Can you look into this issue urgently. I remember you fixing an issue
>>> related to this.
>>>
>>> Thanks.
>>>
>>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
>>> wrote:
>>>
 Hi All,

 I debug code of our and found issue. It seems implementation of some
 API changed in user-core. Let me explain the flow.

 Our queue/topic creation has two call.

 1. We create internal role when adding queue and assign
 "changePermission", "publish", "consume"  permissions to it. Which means
 that, user who created particular queue can update permission, publish or
 consume.

 - Below code line used to get internal role name:

 UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
 queueName.replace(".","-").replace("/", "-"))

 result = {java.lang.String@10289}"*Internal/Q_userQueue*"
 value = {char[21]@10290}
 hash = 0
 hash32 = 0

 - assign permission as below:

 userStoreManager.addRole(roleName, user, null);
 userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
 PERMISSION_CHANGE_PERMISSION);
 userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
 TreeNode.Permission.CONSUME.toString().toLowerCase());
 userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
 TreeNode.Permission.PUBLISH.toString().toLowerCase());

 2. User can select some other role listed in in queue add page. He can
 select these role when adding queue or later by updating queue. So in
 update permission we checked whether any of user's role has above assign
 change permission.

 - get role list of user:

 userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)

 result = {java.lang.String[3]@9689}
 [0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
 [1] = {java.lang.String@9691}"Internal/everyone"
 [2] = {java.lang.String@9692}"role1"

 - check whether any of role has change permission

 for (String userRole : userRoles) {
 if
 (userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
 PERMISSION_CHANGE_PERMISSION)) {
 isUserHasChangePermission = true;
 }
 }

 Issue is above check false for all roles. But we assigned change
 permission to *Internal/Q_userQueue*  role when creating queue.

 3. Next I evaluate below code line to check whether which role has
 change permission to queueID. Result is as below:

 userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
 PERMISSION_CHANGE_PERMISSION)

 result = {java.lang.String[1]@9694}
 [0] = {java.lang.String@9686}"*INTERNAL/Q_userQueue*"

 Result has different role name. We created role name called
 *Internal/Q_userQueue* and assign permissions but it has created with
 different name *INTERNAL/Q_userQueue* and assign permission.

 Please have look into this because it is blocking issue to our
 implementation.

 Cheers!


 On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah <
 kishant...@wso2.com> wrote:

> Was this issue found in 4.4.2 RC1 too?
>
> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Kishanthan/Kernel Team,

We have added the test case as well to the same PR.

Also can we get CARBON-15505 merged? The PR for master is a very old PR
which we have missed to review and merge. This mainly contains some
reordering of fields in the UI to make it more consistent and reorder
properties in user-mgt.xml to be consistent with UI. Hope we don't need any
tests for this.

Any update on the 3 issues raised above ?

Thanks,
Johann.

On Thu, Oct 15, 2015 at 3:30 PM, Johann Nallathamby  wrote:

> Hi Kishanthan/Kernel Team,
>
> We are in the process writing the test case for the issue. Should be able
> to send it before end of day.
>
> [1] has been reported in another thread. This issue in particular looks
> critical to me, because AFAIK there are many users using proxyContextPath.
> Not sure about WebContextRoot though. Apart from that WSO2 QA has reported
> [2,3] in IS 5.1.0 SNAPSHOT pack. May be its harmless, but looks like it is
> coming from kernel and would like to get your thoughts on this if this is
> critical and needs to be fixed.
>
> [1] https://wso2.org/jira/browse/CARBON-15475
> [2] https://wso2.org/jira/browse/IDENTITY-3815
> [3] https://wso2.org/jira/browse/IDENTITY-3817
>
> And also it will be great if we can change the default value of
> XSSPreventionConfig.Enabled to 'false' because this was added in order to
> prevent XSS centrally, however the approach is not 100% bug free. Whoever
> has this enabled needs to test all their functionality well. Therefore what
> I suggest is to make it 'false' by default and whatever product that needs
> it can enable it at product level. WDYT ? Can we do this ?
>
> Regards,
> Johann.
>
>
> On Wed, Oct 14, 2015 at 6:30 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Can we also have test case for this fix please?
>>
>> On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne 
>> wrote:
>>
>>> Hi,
>>>
>>> This issue is fixed in [1].
>>>
>>>
>>> Thanks
>>> isura
>>>
>>>
>>> [1] https://wso2.org/jira/browse/CARBON-15517
>>>
>>>
>>> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Isura,

 Can you look into this issue urgently. I remember you fixing an issue
 related to this.

 Thanks.

 On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath 
 wrote:

> Hi All,
>
> I debug code of our and found issue. It seems implementation of some
> API changed in user-core. Let me explain the flow.
>
> Our queue/topic creation has two call.
>
> 1. We create internal role when adding queue and assign
> "changePermission", "publish", "consume"  permissions to it. Which means
> that, user who created particular queue can update permission, publish or
> consume.
>
> - Below code line used to get internal role name:
>
> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
> queueName.replace(".","-").replace("/", "-"))
>
> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
> value = {char[21]@10290}
> hash = 0
> hash32 = 0
>
> - assign permission as below:
>
> userStoreManager.addRole(roleName, user, null);
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> PERMISSION_CHANGE_PERMISSION);
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> TreeNode.Permission.CONSUME.toString().toLowerCase());
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> TreeNode.Permission.PUBLISH.toString().toLowerCase());
>
> 2. User can select some other role listed in in queue add page. He can
> select these role when adding queue or later by updating queue. So in
> update permission we checked whether any of user's role has above assign
> change permission.
>
> - get role list of user:
>
> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)
>
> result = {java.lang.String[3]@9689}
> [0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
> [1] = {java.lang.String@9691}"Internal/everyone"
> [2] = {java.lang.String@9692}"role1"
>
> - check whether any of role has change permission
>
> for (String userRole : userRoles) {
> if
> (userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
> PERMISSION_CHANGE_PERMISSION)) {
> isUserHasChangePermission = true;
> }
> }
>
> Issue is above check false for all roles. But we assigned change
> permission to *Internal/Q_userQueue*  role when creating queue.
>
> 3. Next I evaluate below code line to check whether which role has
> change permission to queueID. Result is as below:
>
> userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
> 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Isura Karunaratne]

Hi,

This issue is fixed in [1].


Thanks
isura


[1] https://wso2.org/jira/browse/CARBON-15517


On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
wrote:

> Hi Isura,
>
> Can you look into this issue urgently. I remember you fixing an issue
> related to this.
>
> Thanks.
>
> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath  wrote:
>
>> Hi All,
>>
>> I debug code of our and found issue. It seems implementation of some API
>> changed in user-core. Let me explain the flow.
>>
>> Our queue/topic creation has two call.
>>
>> 1. We create internal role when adding queue and assign
>> "changePermission", "publish", "consume"  permissions to it. Which means
>> that, user who created particular queue can update permission, publish or
>> consume.
>>
>> - Below code line used to get internal role name:
>>
>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>> queueName.replace(".","-").replace("/", "-"))
>>
>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>> value = {char[21]@10290}
>> hash = 0
>> hash32 = 0
>>
>> - assign permission as below:
>>
>> userStoreManager.addRole(roleName, user, null);
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> PERMISSION_CHANGE_PERMISSION);
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> TreeNode.Permission.CONSUME.toString().toLowerCase());
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>> TreeNode.Permission.PUBLISH.toString().toLowerCase());
>>
>> 2. User can select some other role listed in in queue add page. He can
>> select these role when adding queue or later by updating queue. So in
>> update permission we checked whether any of user's role has above assign
>> change permission.
>>
>> - get role list of user:
>>
>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)
>>
>> result = {java.lang.String[3]@9689}
>> [0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
>> [1] = {java.lang.String@9691}"Internal/everyone"
>> [2] = {java.lang.String@9692}"role1"
>>
>> - check whether any of role has change permission
>>
>> for (String userRole : userRoles) {
>> if
>> (userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
>> PERMISSION_CHANGE_PERMISSION)) {
>> isUserHasChangePermission = true;
>> }
>> }
>>
>> Issue is above check false for all roles. But we assigned change
>> permission to *Internal/Q_userQueue*  role when creating queue.
>>
>> 3. Next I evaluate below code line to check whether which role has change
>> permission to queueID. Result is as below:
>>
>> userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
>> PERMISSION_CHANGE_PERMISSION)
>>
>> result = {java.lang.String[1]@9694}
>> [0] = {java.lang.String@9686}"*INTERNAL/Q_userQueue*"
>>
>> Result has different role name. We created role name called
>> *Internal/Q_userQueue* and assign permissions but it has created with
>> different name *INTERNAL/Q_userQueue* and assign permission.
>>
>> Please have look into this because it is blocking issue to our
>> implementation.
>>
>> Cheers!
>>
>>
>> On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Was this issue found in 4.4.2 RC1 too?
>>>
>>> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
>>> wrote:
>>>
 Hi Manuri,

 We tested MB 3.0.0 with this release and our scenario of queue creation
 fails after giving a permission denied error. The scenario is as follows:

 1. Create a user "user1" with a role assigned with permission to create
 queues.
 2. Login from "user1" and try to create a queue, we get a permission
 denied error.

 When creating a queue the following happens from our code.

 1. We create an internal role for the queue and assign it to the
 current user with permissions assigned.

 userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
   
 PERMISSION_CHANGE_PERMISSION);

 2. Next, we create the queue and update permissions for the queue. In this 
 step, we check if the current user has permissions to change the queue.

 String[] userRoles = 
 userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
 for (String userRole : userRoles) {
 if (userRealm.getAuthorizationManager().isRoleAuthorized(
 userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
 isUserHasChangePermission = true;
 }
 }

 At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
 userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
 implying that any of roles assigned to the user do not have permissions to 
 change the queue, thus not allowing the user to create the 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Kishanthan Thangarajah]

Can we also have test case for this fix please?

On Wed, Oct 14, 2015 at 6:13 PM, Isura Karunaratne  wrote:

> Hi,
>
> This issue is fixed in [1].
>
>
> Thanks
> isura
>
>
> [1] https://wso2.org/jira/browse/CARBON-15517
>
>
> On Wed, Oct 14, 2015 at 11:25 AM, Johann Nallathamby 
> wrote:
>
>> Hi Isura,
>>
>> Can you look into this issue urgently. I remember you fixing an issue
>> related to this.
>>
>> Thanks.
>>
>> On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath  wrote:
>>
>>> Hi All,
>>>
>>> I debug code of our and found issue. It seems implementation of some API
>>> changed in user-core. Let me explain the flow.
>>>
>>> Our queue/topic creation has two call.
>>>
>>> 1. We create internal role when adding queue and assign
>>> "changePermission", "publish", "consume"  permissions to it. Which means
>>> that, user who created particular queue can update permission, publish or
>>> consume.
>>>
>>> - Below code line used to get internal role name:
>>>
>>> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
>>> queueName.replace(".","-").replace("/", "-"))
>>>
>>> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
>>> value = {char[21]@10290}
>>> hash = 0
>>> hash32 = 0
>>>
>>> - assign permission as below:
>>>
>>> userStoreManager.addRole(roleName, user, null);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> PERMISSION_CHANGE_PERMISSION);
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> TreeNode.Permission.CONSUME.toString().toLowerCase());
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>> TreeNode.Permission.PUBLISH.toString().toLowerCase());
>>>
>>> 2. User can select some other role listed in in queue add page. He can
>>> select these role when adding queue or later by updating queue. So in
>>> update permission we checked whether any of user's role has above assign
>>> change permission.
>>>
>>> - get role list of user:
>>>
>>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)
>>>
>>> result = {java.lang.String[3]@9689}
>>> [0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
>>> [1] = {java.lang.String@9691}"Internal/everyone"
>>> [2] = {java.lang.String@9692}"role1"
>>>
>>> - check whether any of role has change permission
>>>
>>> for (String userRole : userRoles) {
>>> if
>>> (userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
>>> PERMISSION_CHANGE_PERMISSION)) {
>>> isUserHasChangePermission = true;
>>> }
>>> }
>>>
>>> Issue is above check false for all roles. But we assigned change
>>> permission to *Internal/Q_userQueue*  role when creating queue.
>>>
>>> 3. Next I evaluate below code line to check whether which role has
>>> change permission to queueID. Result is as below:
>>>
>>> userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
>>> PERMISSION_CHANGE_PERMISSION)
>>>
>>> result = {java.lang.String[1]@9694}
>>> [0] = {java.lang.String@9686}"*INTERNAL/Q_userQueue*"
>>>
>>> Result has different role name. We created role name called
>>> *Internal/Q_userQueue* and assign permissions but it has created with
>>> different name *INTERNAL/Q_userQueue* and assign permission.
>>>
>>> Please have look into this because it is blocking issue to our
>>> implementation.
>>>
>>> Cheers!
>>>
>>>
>>> On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
 Was this issue found in 4.4.2 RC1 too?

 On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
 wrote:

> Hi Manuri,
>
> We tested MB 3.0.0 with this release and our scenario of queue
> creation fails after giving a permission denied error. The scenario is as
> follows:
>
> 1. Create a user "user1" with a role assigned with permission to
> create queues.
> 2. Login from "user1" and try to create a queue, we get a permission
> denied error.
>
> When creating a queue the following happens from our code.
>
> 1. We create an internal role for the queue and assign it to the
> current user with permissions assigned.
>
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>   
> PERMISSION_CHANGE_PERMISSION);
>
> 2. Next, we create the queue and update permissions for the queue. In 
> this step, we check if the current user has permissions to change the 
> queue.
>
> String[] userRoles = 
> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
> for (String userRole : userRoles) {
> if (userRealm.getAuthorizationManager().isRoleAuthorized(
> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
> isUserHasChangePermission = true;
> }
> }
>
> At 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

Hi,

There is also a minor issue in user core as well, which is related to mysql
server version. Created a public jira for that in [1]

[1] - https://wso2.org/jira/browse/CARBON-15514

Thanks,

On Wed, Oct 14, 2015 at 10:32 AM, Sasikala Kottegoda 
wrote:

> Hi Kishanthan,
>
> Yes, it is present in 4.4.2 RC1 as well. But not in 4.4.1.
>
> Thank you.
>
> On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Was this issue found in 4.4.2 RC1 too?
>>
>> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
>> wrote:
>>
>>> Hi Manuri,
>>>
>>> We tested MB 3.0.0 with this release and our scenario of queue creation
>>> fails after giving a permission denied error. The scenario is as follows:
>>>
>>> 1. Create a user "user1" with a role assigned with permission to create
>>> queues.
>>> 2. Login from "user1" and try to create a queue, we get a permission
>>> denied error.
>>>
>>> When creating a queue the following happens from our code.
>>>
>>> 1. We create an internal role for the queue and assign it to the current
>>> user with permissions assigned.
>>>
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>>   
>>> PERMISSION_CHANGE_PERMISSION);
>>>
>>> 2. Next, we create the queue and update permissions for the queue. In this 
>>> step, we check if the current user has permissions to change the queue.
>>>
>>> String[] userRoles = 
>>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>>> for (String userRole : userRoles) {
>>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>>> isUserHasChangePermission = true;
>>> }
>>> }
>>>
>>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>>> implying that any of roles assigned to the user do not have permissions to 
>>> change the queue, thus not allowing the user to create the queue.
>>>
>>>
>>> Thank you
>>>
>>>
>>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>>> wrote:
>>>
 Hi Devs,

 WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.

 This release fixes the following issues:
 https://wso2.org/jira/issues/?filter=12396

 Please download and test your products with kernel 4.4.2 RC2 and vote.
 Vote will be open for 72 hours or longer as needed.

 *​Source and binary distribution files:*
 https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2

 *Maven staging repository:*
 http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/

 *The tag to be voted upon:*
 https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2


 [ ] Broken - do not release (explain why)
 [ ] Stable - go ahead and release


 Thank you
 Carbon Team

 --

 *Manuri Amaya Perera*

 *Software Engineer*

 *WSO2 Inc.*

 *Blog: http://manuriamayaperera.blogspot.com
 *

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Sasikala Kottegoda
>>> *Software Engineer*
>>> WSO2 Inc., http://wso2.com/
>>> lean. enterprise. middleware
>>> Mobile: +94 774835928/712792401
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Kishanthan Thangarajah*
>> Associate Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> *
>> Twitter - *http://twitter.com/kishanthan *
>>
>
>
>
> --
> Sasikala Kottegoda
> *Software Engineer*
> WSO2 Inc., http://wso2.com/
> lean. enterprise. middleware
> Mobile: +94 774835928/712792401
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Johann Nallathamby]

Hi Isura,

Can you look into this issue urgently. I remember you fixing an issue
related to this.

Thanks.

On Wed, Oct 14, 2015 at 7:16 AM, Indika Sampath  wrote:

> Hi All,
>
> I debug code of our and found issue. It seems implementation of some API
> changed in user-core. Let me explain the flow.
>
> Our queue/topic creation has two call.
>
> 1. We create internal role when adding queue and assign
> "changePermission", "publish", "consume"  permissions to it. Which means
> that, user who created particular queue can update permission, publish or
> consume.
>
> - Below code line used to get internal role name:
>
> UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
> queueName.replace(".","-").replace("/", "-"))
>
> result = {java.lang.String@10289}"*Internal/Q_userQueue*"
> value = {char[21]@10290}
> hash = 0
> hash32 = 0
>
> - assign permission as below:
>
> userStoreManager.addRole(roleName, user, null);
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> PERMISSION_CHANGE_PERMISSION);
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> TreeNode.Permission.CONSUME.toString().toLowerCase());
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
> TreeNode.Permission.PUBLISH.toString().toLowerCase());
>
> 2. User can select some other role listed in in queue add page. He can
> select these role when adding queue or later by updating queue. So in
> update permission we checked whether any of user's role has above assign
> change permission.
>
> - get role list of user:
>
> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)
>
> result = {java.lang.String[3]@9689}
> [0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
> [1] = {java.lang.String@9691}"Internal/everyone"
> [2] = {java.lang.String@9692}"role1"
>
> - check whether any of role has change permission
>
> for (String userRole : userRoles) {
> if
> (userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
> PERMISSION_CHANGE_PERMISSION)) {
> isUserHasChangePermission = true;
> }
> }
>
> Issue is above check false for all roles. But we assigned change
> permission to *Internal/Q_userQueue*  role when creating queue.
>
> 3. Next I evaluate below code line to check whether which role has change
> permission to queueID. Result is as below:
>
> userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
> PERMISSION_CHANGE_PERMISSION)
>
> result = {java.lang.String[1]@9694}
> [0] = {java.lang.String@9686}"*INTERNAL/Q_userQueue*"
>
> Result has different role name. We created role name called
> *Internal/Q_userQueue* and assign permissions but it has created with
> different name *INTERNAL/Q_userQueue* and assign permission.
>
> Please have look into this because it is blocking issue to our
> implementation.
>
> Cheers!
>
>
> On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Was this issue found in 4.4.2 RC1 too?
>>
>> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
>> wrote:
>>
>>> Hi Manuri,
>>>
>>> We tested MB 3.0.0 with this release and our scenario of queue creation
>>> fails after giving a permission denied error. The scenario is as follows:
>>>
>>> 1. Create a user "user1" with a role assigned with permission to create
>>> queues.
>>> 2. Login from "user1" and try to create a queue, we get a permission
>>> denied error.
>>>
>>> When creating a queue the following happens from our code.
>>>
>>> 1. We create an internal role for the queue and assign it to the current
>>> user with permissions assigned.
>>>
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>>   
>>> PERMISSION_CHANGE_PERMISSION);
>>>
>>> 2. Next, we create the queue and update permissions for the queue. In this 
>>> step, we check if the current user has permissions to change the queue.
>>>
>>> String[] userRoles = 
>>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>>> for (String userRole : userRoles) {
>>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>>> isUserHasChangePermission = true;
>>> }
>>> }
>>>
>>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>>> implying that any of roles assigned to the user do not have permissions to 
>>> change the queue, thus not allowing the user to create the queue.
>>>
>>>
>>> Thank you
>>>
>>>
>>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>>> wrote:
>>>
 Hi Devs,

 WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.

 This release fixes the following issues:
 https://wso2.org/jira/issues/?filter=12396

 Please 

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Sasikala Kottegoda]

Hi Kishanthan,

Yes, it is present in 4.4.2 RC1 as well. But not in 4.4.1.

Thank you.

On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah  wrote:

> Was this issue found in 4.4.2 RC1 too?
>
> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
> wrote:
>
>> Hi Manuri,
>>
>> We tested MB 3.0.0 with this release and our scenario of queue creation
>> fails after giving a permission denied error. The scenario is as follows:
>>
>> 1. Create a user "user1" with a role assigned with permission to create
>> queues.
>> 2. Login from "user1" and try to create a queue, we get a permission
>> denied error.
>>
>> When creating a queue the following happens from our code.
>>
>> 1. We create an internal role for the queue and assign it to the current
>> user with permissions assigned.
>>
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>   
>> PERMISSION_CHANGE_PERMISSION);
>>
>> 2. Next, we create the queue and update permissions for the queue. In this 
>> step, we check if the current user has permissions to change the queue.
>>
>> String[] userRoles = 
>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>> for (String userRole : userRoles) {
>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>> isUserHasChangePermission = true;
>> }
>> }
>>
>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>> implying that any of roles assigned to the user do not have permissions to 
>> change the queue, thus not allowing the user to create the queue.
>>
>>
>> Thank you
>>
>>
>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>> wrote:
>>
>>> Hi Devs,
>>>
>>> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>>>
>>> This release fixes the following issues:
>>> https://wso2.org/jira/issues/?filter=12396
>>>
>>> Please download and test your products with kernel 4.4.2 RC2 and vote.
>>> Vote will be open for 72 hours or longer as needed.
>>>
>>> *​Source and binary distribution files:*
>>> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>>>
>>> *Maven staging repository:*
>>> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>>>
>>> *The tag to be voted upon:*
>>> https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2
>>>
>>>
>>> [ ] Broken - do not release (explain why)
>>> [ ] Stable - go ahead and release
>>>
>>>
>>> Thank you
>>> Carbon Team
>>>
>>> --
>>>
>>> *Manuri Amaya Perera*
>>>
>>> *Software Engineer*
>>>
>>> *WSO2 Inc.*
>>>
>>> *Blog: http://manuriamayaperera.blogspot.com
>>> *
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Sasikala Kottegoda
>> *Software Engineer*
>> WSO2 Inc., http://wso2.com/
>> lean. enterprise. middleware
>> Mobile: +94 774835928/712792401
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Kishanthan Thangarajah*
> Associate Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com *
> Twitter - *http://twitter.com/kishanthan *
>



-- 
Sasikala Kottegoda
*Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928/712792401
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Rajith Vitharana]

Hi,

We have tested Basic scenarios + installing DSS features in ESB 4.9.0 and
those are successful (there were some integration test failiers due to
configuration changes which needs some fixes in test cases in DSS)

+1 to release

Thanks,

On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
wrote:

> Hi Manuri,
>
> We tested MB 3.0.0 with this release and our scenario of queue creation
> fails after giving a permission denied error. The scenario is as follows:
>
> 1. Create a user "user1" with a role assigned with permission to create
> queues.
> 2. Login from "user1" and try to create a queue, we get a permission
> denied error.
>
> When creating a queue the following happens from our code.
>
> 1. We create an internal role for the queue and assign it to the current
> user with permissions assigned.
>
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>   
> PERMISSION_CHANGE_PERMISSION);
>
> 2. Next, we create the queue and update permissions for the queue. In this 
> step, we check if the current user has permissions to change the queue.
>
> String[] userRoles = 
> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
> for (String userRole : userRoles) {
> if (userRealm.getAuthorizationManager().isRoleAuthorized(
> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
> isUserHasChangePermission = true;
> }
> }
>
> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false implying 
> that any of roles assigned to the user do not have permissions to change the 
> queue, thus not allowing the user to create the queue.
>
>
> Thank you
>
>
> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
> wrote:
>
>> Hi Devs,
>>
>> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>>
>> This release fixes the following issues:
>> https://wso2.org/jira/issues/?filter=12396
>>
>> Please download and test your products with kernel 4.4.2 RC2 and vote.
>> Vote will be open for 72 hours or longer as needed.
>>
>> *​Source and binary distribution files:*
>> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>>
>> *Maven staging repository:*
>> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>>
>> *The tag to be voted upon:*
>> https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2
>>
>>
>> [ ] Broken - do not release (explain why)
>> [ ] Stable - go ahead and release
>>
>>
>> Thank you
>> Carbon Team
>>
>> --
>>
>> *Manuri Amaya Perera*
>>
>> *Software Engineer*
>>
>> *WSO2 Inc.*
>>
>> *Blog: http://manuriamayaperera.blogspot.com
>> *
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sasikala Kottegoda
> *Software Engineer*
> WSO2 Inc., http://wso2.com/
> lean. enterprise. middleware
> Mobile: +94 774835928/712792401
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Sasikala Kottegoda]

Hi Manuri,

We tested MB 3.0.0 with this release and our scenario of queue creation
fails after giving a permission denied error. The scenario is as follows:

1. Create a user "user1" with a role assigned with permission to create
queues.
2. Login from "user1" and try to create a queue, we get a permission denied
error.

When creating a queue the following happens from our code.

1. We create an internal role for the queue and assign it to the current
user with permissions assigned.

userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
  PERMISSION_CHANGE_PERMISSION);

2. Next, we create the queue and update permissions for the queue. In
this step, we check if the current user has permissions to change the
queue.

String[] userRoles =
userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
for (String userRole : userRoles) {
if (userRealm.getAuthorizationManager().isRoleAuthorized(
userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
isUserHasChangePermission = true;
}
}

At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false
implying that any of roles assigned to the user do not have
permissions to change the queue, thus not allowing the user to create
the queue.


Thank you


On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
wrote:

> Hi Devs,
>
> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>
> This release fixes the following issues:
> https://wso2.org/jira/issues/?filter=12396
>
> Please download and test your products with kernel 4.4.2 RC2 and vote.
> Vote will be open for 72 hours or longer as needed.
>
> *​Source and binary distribution files:*
> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>
> *Maven staging repository:*
> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>
> *The tag to be voted upon:*
> https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2
>
>
> [ ] Broken - do not release (explain why)
> [ ] Stable - go ahead and release
>
>
> Thank you
> Carbon Team
>
> --
>
> *Manuri Amaya Perera*
>
> *Software Engineer*
>
> *WSO2 Inc.*
>
> *Blog: http://manuriamayaperera.blogspot.com
> *
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Sasikala Kottegoda
*Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928/712792401
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Ramith Jayasinghe]

could we hold the release until permission related issue is fixed?

On Tue, Oct 13, 2015 at 5:10 PM, Ramith Jayasinghe  wrote:

> could we hold the release until permission related issue?
>
> On Tue, Oct 13, 2015 at 5:06 PM, Rajith Vitharana 
> wrote:
>
>> Hi,
>>
>> We have tested Basic scenarios + installing DSS features in ESB 4.9.0 and
>> those are successful (there were some integration test failiers due to
>> configuration changes which needs some fixes in test cases in DSS)
>>
>> +1 to release
>>
>> Thanks,
>>
>> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
>> wrote:
>>
>>> Hi Manuri,
>>>
>>> We tested MB 3.0.0 with this release and our scenario of queue creation
>>> fails after giving a permission denied error. The scenario is as follows:
>>>
>>> 1. Create a user "user1" with a role assigned with permission to create
>>> queues.
>>> 2. Login from "user1" and try to create a queue, we get a permission
>>> denied error.
>>>
>>> When creating a queue the following happens from our code.
>>>
>>> 1. We create an internal role for the queue and assign it to the current
>>> user with permissions assigned.
>>>
>>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>>   
>>> PERMISSION_CHANGE_PERMISSION);
>>>
>>> 2. Next, we create the queue and update permissions for the queue. In this 
>>> step, we check if the current user has permissions to change the queue.
>>>
>>> String[] userRoles = 
>>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>>> for (String userRole : userRoles) {
>>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>>> isUserHasChangePermission = true;
>>> }
>>> }
>>>
>>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>>> implying that any of roles assigned to the user do not have permissions to 
>>> change the queue, thus not allowing the user to create the queue.
>>>
>>>
>>> Thank you
>>>
>>>
>>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>>> wrote:
>>>
 Hi Devs,

 WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.

 This release fixes the following issues:
 https://wso2.org/jira/issues/?filter=12396

 Please download and test your products with kernel 4.4.2 RC2 and vote.
 Vote will be open for 72 hours or longer as needed.

 *​Source and binary distribution files:*
 https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2

 *Maven staging repository:*
 http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/

 *The tag to be voted upon:*
 https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2


 [ ] Broken - do not release (explain why)
 [ ] Stable - go ahead and release


 Thank you
 Carbon Team

 --

 *Manuri Amaya Perera*

 *Software Engineer*

 *WSO2 Inc.*

 *Blog: http://manuriamayaperera.blogspot.com
 *

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Sasikala Kottegoda
>>> *Software Engineer*
>>> WSO2 Inc., http://wso2.com/
>>> lean. enterprise. middleware
>>> Mobile: +94 774835928/712792401
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Rajith Vitharana
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94715883223
>> Blog : http://lankavitharana.blogspot.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> E: ram...@wso2.com
> P: +94 777542851
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Kishanthan Thangarajah]

Was this issue found in 4.4.2 RC1 too?

On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
wrote:

> Hi Manuri,
>
> We tested MB 3.0.0 with this release and our scenario of queue creation
> fails after giving a permission denied error. The scenario is as follows:
>
> 1. Create a user "user1" with a role assigned with permission to create
> queues.
> 2. Login from "user1" and try to create a queue, we get a permission
> denied error.
>
> When creating a queue the following happens from our code.
>
> 1. We create an internal role for the queue and assign it to the current
> user with permissions assigned.
>
> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>   
> PERMISSION_CHANGE_PERMISSION);
>
> 2. Next, we create the queue and update permissions for the queue. In this 
> step, we check if the current user has permissions to change the queue.
>
> String[] userRoles = 
> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
> for (String userRole : userRoles) {
> if (userRealm.getAuthorizationManager().isRoleAuthorized(
> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
> isUserHasChangePermission = true;
> }
> }
>
> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false implying 
> that any of roles assigned to the user do not have permissions to change the 
> queue, thus not allowing the user to create the queue.
>
>
> Thank you
>
>
> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
> wrote:
>
>> Hi Devs,
>>
>> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>>
>> This release fixes the following issues:
>> https://wso2.org/jira/issues/?filter=12396
>>
>> Please download and test your products with kernel 4.4.2 RC2 and vote.
>> Vote will be open for 72 hours or longer as needed.
>>
>> *​Source and binary distribution files:*
>> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>>
>> *Maven staging repository:*
>> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>>
>> *The tag to be voted upon:*
>> https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2
>>
>>
>> [ ] Broken - do not release (explain why)
>> [ ] Stable - go ahead and release
>>
>>
>> Thank you
>> Carbon Team
>>
>> --
>>
>> *Manuri Amaya Perera*
>>
>> *Software Engineer*
>>
>> *WSO2 Inc.*
>>
>> *Blog: http://manuriamayaperera.blogspot.com
>> *
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sasikala Kottegoda
> *Software Engineer*
> WSO2 Inc., http://wso2.com/
> lean. enterprise. middleware
> Mobile: +94 774835928/712792401
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com *
Twitter - *http://twitter.com/kishanthan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Ramith Jayasinghe]

could we hold the release until permission related issue?

On Tue, Oct 13, 2015 at 5:06 PM, Rajith Vitharana  wrote:

> Hi,
>
> We have tested Basic scenarios + installing DSS features in ESB 4.9.0 and
> those are successful (there were some integration test failiers due to
> configuration changes which needs some fixes in test cases in DSS)
>
> +1 to release
>
> Thanks,
>
> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
> wrote:
>
>> Hi Manuri,
>>
>> We tested MB 3.0.0 with this release and our scenario of queue creation
>> fails after giving a permission denied error. The scenario is as follows:
>>
>> 1. Create a user "user1" with a role assigned with permission to create
>> queues.
>> 2. Login from "user1" and try to create a queue, we get a permission
>> denied error.
>>
>> When creating a queue the following happens from our code.
>>
>> 1. We create an internal role for the queue and assign it to the current
>> user with permissions assigned.
>>
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>   
>> PERMISSION_CHANGE_PERMISSION);
>>
>> 2. Next, we create the queue and update permissions for the queue. In this 
>> step, we check if the current user has permissions to change the queue.
>>
>> String[] userRoles = 
>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>> for (String userRole : userRoles) {
>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>> isUserHasChangePermission = true;
>> }
>> }
>>
>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>> implying that any of roles assigned to the user do not have permissions to 
>> change the queue, thus not allowing the user to create the queue.
>>
>>
>> Thank you
>>
>>
>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>> wrote:
>>
>>> Hi Devs,
>>>
>>> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>>>
>>> This release fixes the following issues:
>>> https://wso2.org/jira/issues/?filter=12396
>>>
>>> Please download and test your products with kernel 4.4.2 RC2 and vote.
>>> Vote will be open for 72 hours or longer as needed.
>>>
>>> *​Source and binary distribution files:*
>>> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>>>
>>> *Maven staging repository:*
>>> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>>>
>>> *The tag to be voted upon:*
>>> https://github.com/wso2/carbon-kernel/tree/v4.4.2-rc2
>>>
>>>
>>> [ ] Broken - do not release (explain why)
>>> [ ] Stable - go ahead and release
>>>
>>>
>>> Thank you
>>> Carbon Team
>>>
>>> --
>>>
>>> *Manuri Amaya Perera*
>>>
>>> *Software Engineer*
>>>
>>> *WSO2 Inc.*
>>>
>>> *Blog: http://manuriamayaperera.blogspot.com
>>> *
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Sasikala Kottegoda
>> *Software Engineer*
>> WSO2 Inc., http://wso2.com/
>> lean. enterprise. middleware
>> Mobile: +94 774835928/712792401
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [VOTE] Release WSO2 Carbon Kernel 4.4.2 RC2

[Indika Sampath]

Hi All,

I debug code of our and found issue. It seems implementation of some API
changed in user-core. Let me explain the flow.

Our queue/topic creation has two call.

1. We create internal role when adding queue and assign "changePermission",
"publish", "consume"  permissions to it. Which means that, user who created
particular queue can update permission, publish or consume.

- Below code line used to get internal role name:

UserCoreUtil.addInternalDomainName(QUEUE_ROLE_PREFIX +
queueName.replace(".","-").replace("/", "-"))

result = {java.lang.String@10289}"*Internal/Q_userQueue*"
value = {char[21]@10290}
hash = 0
hash32 = 0

- assign permission as below:

userStoreManager.addRole(roleName, user, null);
userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
PERMISSION_CHANGE_PERMISSION);
userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
TreeNode.Permission.CONSUME.toString().toLowerCase());
userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
TreeNode.Permission.PUBLISH.toString().toLowerCase());

2. User can select some other role listed in in queue add page. He can
select these role when adding queue or later by updating queue. So in
update permission we checked whether any of user's role has above assign
change permission.

- get role list of user:

userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser)

result = {java.lang.String[3]@9689}
[0] = {java.lang.String@9690}"*Internal/Q_userQueue*"
[1] = {java.lang.String@9691}"Internal/everyone"
[2] = {java.lang.String@9692}"role1"

- check whether any of role has change permission

for (String userRole : userRoles) {
if
(userRealm.getAuthorizationManager().isRoleAuthorized(userRole, queueID,
PERMISSION_CHANGE_PERMISSION)) {
isUserHasChangePermission = true;
}
}

Issue is above check false for all roles. But we assigned change permission
to *Internal/Q_userQueue*  role when creating queue.

3. Next I evaluate below code line to check whether which role has change
permission to queueID. Result is as below:

userRealm.getAuthorizationManager().getAllowedRolesForResource(queueID,
PERMISSION_CHANGE_PERMISSION)

result = {java.lang.String[1]@9694}
[0] = {java.lang.String@9686}"*INTERNAL/Q_userQueue*"

Result has different role name. We created role name called
*Internal/Q_userQueue* and assign permissions but it has created with
different name *INTERNAL/Q_userQueue* and assign permission.

Please have look into this because it is blocking issue to our
implementation.

Cheers!


On Tue, Oct 13, 2015 at 5:22 PM, Kishanthan Thangarajah  wrote:

> Was this issue found in 4.4.2 RC1 too?
>
> On Tue, Oct 13, 2015 at 4:58 PM, Sasikala Kottegoda 
> wrote:
>
>> Hi Manuri,
>>
>> We tested MB 3.0.0 with this release and our scenario of queue creation
>> fails after giving a permission denied error. The scenario is as follows:
>>
>> 1. Create a user "user1" with a role assigned with permission to create
>> queues.
>> 2. Login from "user1" and try to create a queue, we get a permission
>> denied error.
>>
>> When creating a queue the following happens from our code.
>>
>> 1. We create an internal role for the queue and assign it to the current
>> user with permissions assigned.
>>
>> userRealm.getAuthorizationManager().authorizeRole(roleName, queueId,
>>   
>> PERMISSION_CHANGE_PERMISSION);
>>
>> 2. Next, we create the queue and update permissions for the queue. In this 
>> step, we check if the current user has permissions to change the queue.
>>
>> String[] userRoles = 
>> userRealm.getUserStoreManager().getRoleListOfUser(loggedInUser);
>> for (String userRole : userRoles) {
>> if (userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION)) {
>> isUserHasChangePermission = true;
>> }
>> }
>>
>> At this stage, *'*(userRealm.getAuthorizationManager().isRoleAuthorized(
>> userRole, queueID, PERMISSION_CHANGE_PERMISSION))' false 
>> implying that any of roles assigned to the user do not have permissions to 
>> change the queue, thus not allowing the user to create the queue.
>>
>>
>> Thank you
>>
>>
>> On Mon, Oct 12, 2015 at 9:24 PM, Manuri Amaya Perera 
>> wrote:
>>
>>> Hi Devs,
>>>
>>> WSO2 Carbon Kernel 4.4.2 RC2 Release Vote.
>>>
>>> This release fixes the following issues:
>>> https://wso2.org/jira/issues/?filter=12396
>>>
>>> Please download and test your products with kernel 4.4.2 RC2 and vote.
>>> Vote will be open for 72 hours or longer as needed.
>>>
>>> *​Source and binary distribution files:*
>>> https://svn.wso2.org/repos/wso2/people/aruna/v4.4.2-rc2
>>>
>>> *Maven staging repository:*
>>> http://maven.wso2.org/nexus/content/repositories/orgwso2carbon-019/
>>>
>>> *The tag to be voted upon:*
>>>