Re: [Dev] What is the correct behavior when user store selected from Inbound Provisioning Configuration

[Johann Nallathamby]

IMO, returning the username with userstore domain in the response may be
seen as an unwanted sensitive information leak in this setup. Ideally in
these kind of scenarios expectation is service provider doesn't need to
know the user store domain name where his users are created. Therefore they
can provision without the user store domain in the username. And response
also will return the username only.

If they send a invalid or unauthorized domain I think we have to return
back and unauthorized error saying "Not authorized to provision to the
domain".

But then again I am not sure if the service provider can carry out all SCIM
operations without knowing the domain name.

Regards,
Johann.

On Tue, Sep 19, 2017 at 12:40 AM, Darshana Gunawardana 
wrote:

> There is no hard rule to specify which one should be the correct approach
> in this case. Since there is always room to override this setting using
> specific SP's configuration, I think current approach is ok.
>
> Thanks,
>
> On Tue, Sep 19, 2017 at 12:30 AM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Tue, Sep 19, 2017 at 12:13 AM, Darshana Gunawardana > > wrote:
>>
>>> Since we returning the correct username in the response, its should be
>>> ok. This is a configuration issue if the client is expecting otherway.
>>>
>> I think it is better if there is a way to inform client application about
>> configuration issue. There is a possibility that SCIM consumers may not
>> look into admin console configurations at all. Also there is a high
>> possibility to client application to depend on only http response code.
>>
>>>
>>> Thanks,
>>>
>>> On Tue, Sep 19, 2017 at 12:10 AM, Gayan Gunawardana 
>>> wrote:
>>>


 On Mon, Sep 18, 2017 at 11:42 PM, Darshana Gunawardana <
 darsh...@wso2.com> wrote:

> Ok, now you asked the real question :)
>
> Yes I agree with the expected results you mentioned for all three
> cases. I have checked this behaviour on a latest pack[1][2] and it only
> provision user to specified userstore in the SP configuration in the case 
> 3
> which is a reasonable behariour. (I'm using locally built 5.4.0-SNAPSHOT
> version, which is slightly newer than 5.4.0-alpha2)
>
> What is the pack that you have tried?
>
 I have used 5.4.0-alpha2 and your observation is correct i haven't get
 expected result due to some wrong configurations.
 We have to think about case 03 carefully because client application may
 understand as provisioning is successful but it may not be the intended
 user store.

>
> [1]
> Sample Request:
> POST /wso2/scim/Users HTTP/1.1
> Host: localhost:9443
> Content-Type: application/json
> Authorization: Basic YWRtaW46YWRtaW4=
> Cache-Control: no-cache
> Postman-Token: a07e5cab-f4e9-52dd-d245-1b65552c5539
>
> {
>   "schemas": [
>
>   ],
>   "userName": "LDAP/darra...@wso2.com",
>   "password": "darray"
> }
>
> [2]
> Sample Response:
> {
> "meta": {
> "created": "2017-09-18T23:28:23",
> "location": "https://localhost:9443/wso2/s
> cim/Users/3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd",
> "lastModified": "2017-09-18T23:28:23"
> },
> "schemas": [
> "urn:scim:schemas:core:1.0"
> ],
> "id": "3d5b1153-79ef-4ea9-9b47-31c92a2bd3dd",
> "userName": "H2/darra...@wso2.com"
> }
>
> Thanks,
>
>
> On Mon, Sep 18, 2017 at 11:00 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Mon, Sep 18, 2017 at 10:27 PM, Darshana Gunawardana <
>> darsh...@wso2.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 18, 2017 at 7:58 PM, Gayan Gunawardana 
>>> wrote:
>>>

 ​
 When user store selected from Inbound Provisioning Configuration
 should we allow to provision other user stores as well ?

>>>
>>> No.
>>>
>>>
 For an example if we selected "TEST" as user store from Inbound
 Provisioning Configuration, can we provision to PRIMARY user store as 
 well ?

>>>
>>> No.
>>>
>> Thanks Darshana but currently it works other way.
>>
>>>
>>> Given that you are already an expert on the provisioning area, I
>>> suppose you already knew the answers for above questions but you have a
>>> followup question in mind. May I know what that is? :)
>>>
>> I do not have specific follow up question :) just wanted to avoid
>> confusion of sending user store domain in request and selecting user 
>> store
>> domain from service provider.
>> case 01: Do not select user store domain from service provider and
>> sending user store domain in the request.
>> expectation: User store domain can be extracted from request and

Re: [Dev] SCIM 2.0 as default in IS 5.4.0

[Johann Nallathamby]

See if this idea would work?

We currently set a threadlocal variable inside the SCIM endpoint component,
to identify the SCIM service provider inside some of our implementations.
Can we improve this variable value to also identify the SCIM version? This
way the relevant listeners will check for the correct version and only
execute.

For management console operations we won't have a threadlocal set. In that
case one of the listeners (ideally SCIM2) will execute and do the necessary
changes to the user store, so that thereafter even if we do calls using
SCIM 1.1. it should work without a problem.

This way we are not coupling the listeners, each version works
independently, and management console will depend on latest version. Even
if tomorrow SCIM 3.0 comes out we don't need to change existing code :)

Anyone see any issue with this approach? Am I missing anything?

Regards,
Johann.

On Mon, Sep 18, 2017 at 11:04 AM, Pulasthi Mahawithana 
wrote:

> Hi Gayan,
>
> On Mon, Sep 18, 2017 at 10:43 AM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Mon, Sep 18, 2017 at 10:19 AM, Prabath Siriwardena 
>> wrote:
>>
>>>
>>>
>>> On Sun, Sep 17, 2017 at 9:42 PM, Gayan Gunawardana 
>>> wrote:
>>>


 On Mon, Sep 18, 2017 at 8:29 AM, Darshana Gunawardana <
 darsh...@wso2.com> wrote:

> Hi Prabath,
>
> We do have two endpoints for SCIM 1.1 & SCIM 2. But there are some
> listeners we need to enable in order to populated relevant metadata such 
> as
> ID, Created\Modified dates against the correct URI specified by the each
> specification.
>
> Given that, different clients may use different protocol of they
> already support, we should have ability to have both protocols working
> simultaneously.
>
 According to this even single client can use SCIM 1.1 and 2.0
 simultaneously right ?
 Yes so ideally it should work but in practice it will bring some
 complexities. We have to test use-cases like creating user with SCIM 1.1
 and updating with SCIM 2.0.
 IMO we should support only one protocol at a time but not both.

>>>
>>> Can we please identify those complexities...?
>>>
>>> We cannot terminate support for SCIM 1.1 - both have to co-exist for few
>>> releases till we deprecate SCIM 1.1. If both cannot co-exist then we need
>>> to review our design...
>>>
>> What I am suggesting is not to terminate support for SCIM 1.1 but at a
>> time enable only.
>> Enable SCIM 1.1 as default option. If client applications work with SCIM
>> 1.1 they can continue. If client applications want to work with SCIM 2.0 we
>> should be able to enable SCIM 2.0 by disabling SCIM 1.1 from
>> configurations.
>>
>
> What I initially suggested was the other way around. That is having SCIM 2
> as default and make SCIM 1.1 to enable with a config change. The reason is,
> for any new users, they can use the newer standard OOTB without any config
> changes. And for existing users who are using SCIM 1.1 clients will anyway
> need to migrate to 5.4.0. During the migration, we keep the existing
> configuration. So for them SCIM 1.1 will be enabled by default after the
> migration process (They may switch later if needed).
>
> Anyway, as Darshana mentioned, We'll look for the possibility of having
> both of them enabled at once.
>
>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>>
>>>

> Created: https://wso2.org/jira/browse/IDENTITY-6458 to track this.
>
> Thanks,
>
> On Mon, Sep 18, 2017 at 8:11 AM, Darshana Gunawardana <
> darsh...@wso2.com> wrote:
>
>> Hi Gayan,
>>
>> Due to the limitation we have in the user core level, we don't
>> support complex filtering, pagination, sorting. Refer [1] & [2].
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-prov
>> isioning-scim2/blob/v1.0.5/components/org.wso2.carbon.identi
>> ty.scim2.common/src/main/java/org/wso2/carbon/identity/scim2
>> /common/impl/SCIMUserManager.java#L834
>> [2] https://github.com/wso2-extensions/identity-inbound-prov
>> isioning-scim2/blob/v1.0.5/components/org.wso2.carbon.identi
>> ty.scim2.common/src/main/java/org/wso2/carbon/identity/scim2
>> /common/impl/SCIMUserManager.java#L793
>>
>> Thanks,
>>
>> On Mon, Sep 18, 2017 at 7:50 AM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 11, 2017 at 9:14 PM, Vindula Jayawardana <
>>> vindula...@cse.mrt.ac.lk> wrote:
>>>
 Hi,

 +1 for this as the global adoption of SCIM 2.0 is right on the
 track as Ishara has mentioned.

>>> @Vindula
>>> Do we support pagination, complex filters and bulk operation to
>>> resolve cyclic dependencies. As I know you have implemented these 
>>> features
>>> but there are some limitations because of C4 user core component. I am 
>>> not
>>> 

Re: [Dev] [IS] [SCIM] Why Can't We Enable Both SCIM1 and SCIM2 at the Same Time?

[Johann Nallathamby]

On Fri, Sep 1, 2017 at 10:36 PM, Johann Nallathamby  wrote:

> In that case can we set a threadlocal variable in order to identify the
> SCIM version? Based on that the correct listener will execute and the other
> will not. Since SCIM1.1 listener will check for it's related threadlocal
> and SCIM2.0 listener it's related threadlocal there is not coupling between
> the two implementations. All the SCIM operations must set this threadlocal.
> I don't see any better solution for this problem.
>
> Regards,
> Johann.
>
> On Thu, Aug 31, 2017 at 6:54 PM, Sathya Bandara  wrote:
>
>>
>>
>> On Thu, Aug 31, 2017 at 2:18 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Sathya,
>>>
>>> On Thu, Aug 31, 2017 at 12:29 PM, Sathya Bandara 
>>> wrote:
>>>
 Hi Johann,

 IMO having two separate LDAP attributes for the same claims in both
 SCIM1 and SCIM2 would be redundant and cause problems in maintaining user
 attributes.

>>>
>>> True. I didn't say this is the correct solution. I only mentioned it as
>>> a work around for someone who wants to use both without any conflicts until
>>> we find a alternative or deprecate SCIM 1.1 :)
>>>
>>>
 If we need to have both listeners enabled at the time I would suggest
 to use a common util method to generate IDs and do the mappings for the
 claims that are common to both protocols.

>>>
>>> Didn't get how this would help exactly. May be I am missing some context.
>>>
>>> However, after reading through your first reply again, now I have
>>> another question. Why do both the listeners get executed when adding a new
>>> user? I know they both will get triggered. But can't we look at the dialect
>>> URI at the top and skip the execution if it's not for that listener?
>>>
>>> When adding a user through normal approach(management console) when SCIM
>>> is enabled, it is not possible to figure out the dialect URI. In this case
>>> this will not work AFAIU.
>>>
>>
> Hmm..
>

True, that when adding through management console we can't identify the
SCIM version. But do we need to? If both the listeners are doing the same
change in the user store for SCIM1 and SCIM2, then either of the listeners
doing the change will be enough right?

I think this is getting a bit too complicated over mail. We can chat
offline if needed and come to a conclusion :)


>
>
>>
>>> Thanks,
>>> Sathya
>>>
>>> Regards,
>>> Johann.
>>>
>>>

 Thanks,
 Sathya

 On Thu, Aug 31, 2017 at 11:37 AM, Johann Nallathamby 
 wrote:

> Will it work if we have two separate attributes for the problematic
> attributes like SCIM ID? If that works I guess that is one solution.
>
> Or we need to have one listener for both SCIM 1 and SCIM2. But don't
> think that's a good solution. Introduces direct coupling between two
> implementations.
>
> Regards,
> Johann.
>
> On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara 
> wrote:
>
>> Hi Thilina,
>>
>> If we enable both SCIM1 and SCIM2 listeners at the same time two
>> different SCIM IDs will be generated for the same user when adding a new
>> user through SCIM. Also both SCIM1 and SCIM2 claims are mapped to the 
>> same
>> LDAP user attributes. Even though both listeners get triggered only the
>> SCIM1 ID is mapped to the user ID attribute. But the SCIM2 user creation
>> response will contain the SCIM ID generated by SCIM2 listener.
>>
>> Thanks,
>> Sathya
>>
>> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal > > wrote:
>>
>>>
>>> Hi all,
>>>
>>> While I was trying to fix IDENTITY-6315
>>>  I got to know that we
>>> can't enable both SCIM1 and SCIM2 at the same time in WSO2 Identity 
>>> Server.
>>> Is it because of this specific issue or is there any other reasons?
>>>
>>> Thanks & Regards,
>>> Thilina.
>>>
>>> --
>>> *Thilina Madumal*
>>> *Software Engineer | **WSO2*
>>> Email: thilina...@wso2.com
>>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>>> Web:  http://wso2.com
>>>
>>> 
>>>
>>>
>>
>>
>> --
>> Sathya Bandara
>> Software Engineer
>> WSO2 Inc. http://wso2.com
>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>
>> <+94%2071%20411%205032>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com 

Re: [Dev] Remove outdated feature "Usage plan for the tenant"

[Johann Nallathamby]

IINM this comes from carbon-multitenancy. Not a identity feature. So if we
are removing it needs to be removed from all the products.

+1 to remove obsolete features if possible to avoid confusion. WSO2 Cloud
uses a completely different model I suppose.

On Sun, Sep 17, 2017 at 2:34 PM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> Since we are not using the following functionality we can remove this from
> management console and documentation.
>
> [1]* Usage plan for the tenant* - The usage plan defines limitations
> (such as number of users, bandwidth, etc.) for the tenant. The Identity
> Server comes with a predefined list, and you can add your item and/or
> tailor to the existing items. For on-premises deployment, there is only one
> default plan, i.e., Demo.
>
> Create a jira to track this[2]
>
> [1] https://docs.wso2.com/display/IS530/Creating+and+Managing+Tenants
>
> [2] https://wso2.org/jira/browse/IDENTITY-6457
> 
>
>
> Thanks,
> Nila.
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823 <+94%2077%20524%201823>
> Web : http://wso2.com/
>
>
> 
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Too Many Slots submitted to delete - WSO2 MB

[Júnior]

Hi,

I am seeing a lot of this message in my MB Broker Logs:

*TID: [] [] [2017-09-22 09:45:29,606]  WARN
{org.wso2.andes.kernel.slot.SlotDeletingTask} -  Too many slots submitted
to delete. Consider increasing  and 
parameters. Current submit value = 5755 safe zone value = 5586695713193984*

I have increased the thriftClientPoolSize, but I have not found this
deleteTaskCount in the broker.xml.

Do you guys know what are the recommended values for those parameters?

Thanks,

-- 
Francisco Ribeiro
*SCEA|SCJP|SCWCD|IBM Certified SOA Associate*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] MB Cluster node issue

[Júnior]

Hi Jason,

Thanks for the tip.

I am going to check that.

Thanks,

2017-09-21 23:06 GMT-03:00 Jason De Silva :

> Hi Junior,
>
> Can you verify whether time is synced across all MB nodes in the cluster
> because in order for MB cluster to function properly the nodes needs to be
> time synchronized [1].
>
> [1] https://docs.wso2.com/display/MB310/Clustering+and+Deployment
>
> Regards,
> Jason
>
> Jason De Silva
> *Software Engineer - QA*
> Mobile: +94 (0) 772 097 678
> Email: jas...@wso2.com
> WSO2 Inc. www.wso2.com
> 
>
> On Fri, Sep 22, 2017 at 2:08 AM, Júnior  wrote:
>
>> Hi,
>>
>> I have a MB CLuster using AWS Hazelcast configuration.
>>
>> One of the nodes keep entering and leaving the cluster, and i see a lot
>> of those messages:
>>
>> INFO {org.wso2.andes.server.cluster.ClusterManager} -  Handling cluster
>> gossip: Node NODE:X:5711  Joined the Cluster
>>
>> INFO {org.wso2.andes.server.cluster.ClusterManager} -  Handling cluster
>> gossip: Node NODE:X:5711  left the Cluster
>>
>>
>> This is causing a lot of problems on ESB side.
>>
>> Do you know which logger should I enable to troubleshoot this problem?
>>
>> Thanks,
>>
>> --
>> Francisco Ribeiro
>> *SCEA|SCJP|SCWCD|IBM Certified SOA Associate*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
Francisco Ribeiro
*SCEA|SCJP|SCWCD|IBM Certified SOA Associate*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Enterprise Integrator 6.1.1-update5 Released!

[Manuri Amaya Perera]

WSO2 Integration Team is pleased to announce the release of Enterprise
Integrator 6.1.1-update5. This is the immediate release following 6.2.0-m4
release.

Source and binary distribution files of WSO2 Enterprise Integrator
6.1.1-update5 are available for download from here
.

*Tasks/Bug Fixes and Improvements*

​WSO2 Jira - Fixed Issues 
Github WSO2 EI - Fixed Issues



​​*List of Open Issues*

​WSO2 Jira - Open Issues 
Github WSO2 EI - Open Issues



​*Contact Us *

​WSO2 Carbon developers​ can be contacted via following mailing lists:

   - WSO2 Developers List: dev@wso2.org
   - WSO2 Architecture List: architect...@wso2.org


User Forum: StackOverflow 
​

​*Reporting Issues*​

​We encourage you to report issues, improvements and feature requests for
WSO2 Enterprise Integrator through Github Issues
.
​

​~ WSO2 Integration Team ~​

-- 

*Manuri Amaya Perera*

*Senior Software Engineer*

*WSO2 Inc.*

*Blog: http://manuriamayaperera.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 IoT Server 3.1.0-UPDATE3 Released!

[Ruwan Yatawara]

WSO2 IoT Server 3.1.0-UPDATE3


We are pleased to announce the latest update to WSO2 IoT Server 3.1.0

WSO2 IoT Server is one of the most adaptive Apache licensed open source IoT
platforms available today. It provides best of breed technologies for
device manufacturers to develop connected products as well as rich
integration and smart analytics capabilities for system integrators to
adopt devices into systems they build.

These capabilities involve device management, smart analytics, API and app
management for devices, transport extensions for MQTT, XMPP and many more.
What's new in WSO2 IoTS 3.1.0 Update 3

Bug Fixes : A list of bug fixes shipped with this release can be found here

Documentation

Documentations: WSO2 IoT Server Documentation

Known Issues

The known set of issues in this version can be found here

Engaging with CommunityMailing Lists

Join our mailing list and correspondence with the developers directly.

Developer list: dev@wso2.org | Subscribe
 | Mail Archive

Reporting Issues

We encourage you to report issues, documentation faults and feature
requests regarding WSO2 IoT Server through WSO2 IoT GIT Issues
.
Discussion Forums

We encourage you to use stackoverflow

to
engage with developers as well as other users.

For more information about WSO2 IoT Server, please see
http://wso2.com/products/iot-server or visit the WSO2 Oxygen Tank
 developer portal for additional resources.

Thank you for your interest in WSO2 IoT Server.

*The WSO2 IoT Server Team*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] HTTP POST multipart/form-data via ESB

[Sudharma Subasinghe]

Hi Vivek,

If your problem is regarding not adding boundary, try the fix in[1]
relevant version, build and apply that jar as a patch. (Assuming you are
using APIM210)

[1] https://github.com/wso2/pro duct-ei/issues/780

Thanks
Sudharma

On Fri, Sep 22, 2017 at 2:12 PM, vivekkumar 
wrote:

> Hi
>
> I believe boundary issue has been fixed in July.
> In my case problem is that its not copying the content of file from Input
> to
> Backend service.
>
> I might be using the wrong syntax for copying the content. I just used the
> configuration mentioned in the original email.
>
> Cheers
> Vivek
>
>
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Development-f3.html
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>



-- 
Sudharma Subasinghe,
Software Engineer,
WSO2 Inc.
Email: sudhar...@wso2.com 
Mobile : +94 710 565 157 <%2B94%20718%20210%20200>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] HTTP POST multipart/form-data via ESB

[vivekkumar]

Hi 

I believe boundary issue has been fixed in July. 
In my case problem is that its not copying the content of file from Input to
Backend service. 

I might be using the wrong syntax for copying the content. I just used the
configuration mentioned in the original email.

Cheers
Vivek





--
Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] HTTP POST multipart/form-data via ESB

[João Abrantes]

Hi!,

I think your problem is related to this: 
https://stackoverflow.com/questions/45617964/wso2-missing-boundary-in-multipart-form-data-post
 


Problem being the Content-type line does not set the boundary as it should.

Haven’t found a solution yet.

Best regards,
Joao Abrantes

> On 22 Sep 2017, at 08:57, vivekkumar  wrote:
> 
> I tried the option recommend in previous mail.
> 
> Still have same issue. Following is my mediator with new changes and log
> captured in TcpMon
> 
> --- mediator -
> 
>  xmlns="http://ws.apache.org/ns/synapse;>
> value="true"/>
> value="true"/>
>
> value="paymentRef1"/>
>
>
>
>$1
>$2
> name="payload" xmlns="http://org.apache.axis2/xsd/form-data;>
> 
> $3
>
>
>
>
>
>
>
>
> value="multipart/form-data"/>
> 
> 
> --- TCPMON-
> 
> Content-Type: multipart/form-data
> Accept: */*
> Content-Length: 668
> Host: localhost:8082
> Connection: Keep-Alive
> User-Agent: Synapse-PT-HttpComponents-NIO
> 
> --MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
> Content-Disposition: form-data; name="entityId"
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
> 
> bank1
> --MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
> Content-Disposition: form-data; name="paymentRef"
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
> 
> paymentRef1
> --MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
> Content-Disposition: form-data; name="file"
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 8bit
> 
> 
> 
> 
> --MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed--
> 
> 
> 
> 
> --
> Sent from: 
> http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev

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

Re: [Dev] HTTP POST multipart/form-data via ESB

[vivekkumar]

I tried the option recommend in previous mail.

Still have same issue. Following is my mediator with new changes and log
captured in TcpMon

--- mediator -

http://ws.apache.org/ns/synapse;>







$1
$2
http://org.apache.axis2/xsd/form-data;>

$3











--- TCPMON-

Content-Type: multipart/form-data
Accept: */*
Content-Length: 668
Host: localhost:8082
Connection: Keep-Alive
User-Agent: Synapse-PT-HttpComponents-NIO

--MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
Content-Disposition: form-data; name="entityId"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

bank1
--MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
Content-Disposition: form-data; name="paymentRef"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

paymentRef1
--MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed
Content-Disposition: form-data; name="file"
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit




--MIMEBoundary_ed56c98c6eef392fa54834d54b1068a5832ea044544d85ed--




--
Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Identity Server 5.4.0 Alpha3 Released!

[Thilina Madumal]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.4.0 Alpha3. This distribution can be
downloaded from the following location.

https://github.com/wso2/product-is/releases/tag/v5.4.0-alpha3

The following list contains all the features, improvements, and bug fixes
available with the 5.4.0 Alpha3 release.
Patch

   - [IDENTITY-5968 ] - Old
   email templates are stored in registry even when they are never used
   - [IDENTITY-6136 ] - Results
   are not retrieved for 'http://wso2.org/claims/identity/' claims of
   GetUserList in the RemoteUserStoreManagerService
   - [IDENTITY-6190 ] - Error
   while validating SAML assertion timestamp when IDP is hosted in different
   time zone
   - [IDENTITY-6451 ] - In Saml
   error relay state is not returned to the saml notification jsp. No way to
   return the relay state back to SP in error case

Bug

   - [IDENTITY-4036 ] -
   [Logging] Error in backend when Clicking on Restore Defaults and it display
   message as "Restoring of Global Log4j Configuration is failed" but gets
   restored successfully
   - [IDENTITY-5722 ] - WSO2IS
   does not work for the LDAP users with DN with special characters such as "\"
   - [IDENTITY-5808 ] -
   Performance degradation due to expired Oauth2 authorization codes which
   have ACTIVE status
   - [IDENTITY-6048 ] - User
   list of a role is shown as empty for AD userstore when role has 1500+ users
   - [IDENTITY-6131 ] - IDP
   Resident IDP update button promt message even without doing any changes
   - [IDENTITY-6146 ] -
   ReadOnlyUserStoreManager has DisplayName property set to 'uid'
   - [IDENTITY-6195 ] - OIDC
   address claim is not in the required format
   - [IDENTITY-6216 ] -
   RemoteUserStoreManagerService getUserList for "
   http://wso2.org/claims/username; claim not working for JDBC user store
   manager.
   - [IDENTITY-6217 ] - User
   profile get update to incorrect value, when attribute value has
   intersection with MultiAttributeSeparator
   - [IDENTITY-6257 ] -
   Deploying multiple travelocity applications by renaming the web application
   name
   - [IDENTITY-6277 ] -
   NullPointerException thrown when enabling debug logs in OpenID Connect
   federated authenticator
   - [IDENTITY-6306 ] -
   Identity server not allowed to use role name with @ character
   - [IDENTITY-6307 ] -
   Auth_time is changing to session updated time
   - [IDENTITY-6313 ] - Typo in
   Add User Store
   - [IDENTITY-6346 ] - Account
   lock with failed login attempts not working for old identity listener
   configurations
   - [IDENTITY-6375 ] - cannot
   provision users to seconday userstores with outbound provisioning SCIM
   - [IDENTITY-6377 ] - Errors
   in DB2 scripts
   - [IDENTITY-6379 ] - OAuth
   DCRM send Internal Server Error when tried to retrieve application with
   invalid client id
   - [IDENTITY-6382 ] - Oracle
   sql script error with creating index
   - [IDENTITY-6383 ] - -Dsetup
   is not working for Oracle databases
   - [IDENTITY-6389 ] -
   Recovery with security questions(one by one and all at once)-REST api fails
   for tenant user
   - [IDENTITY-6393 ] -
   Couldn't add roles with admin permission when logged in with primary or
   secondary users
   - [IDENTITY-6402 ] - SCIM
   Create user response's 'location' is invalid
   - [IDENTITY-6409 ] - Can not
   update a SP name
   - [IDENTITY-6444 ] -
   Couldn't update the user profile when using AD(Active directory) as
   primary/secondary user store
   - [IDENTITY-6445 ] - New DCR
   endpoint should update correctly in swagger file
   - [IDENTITY-6447 ] - UI