[Architecture] [Dev] WSO2 API Microgateway 3.2.0 Released!

[Menaka Jayawardena]

The WSO2 API Manager team is pleased to announce the release of version
3.2.0 of WSO2 API Microgateway.

The WSO2 API Microgateway is a cloud-native, developer-centric and
decentralized API gateway for microservices.
You can download the product from API Microgateway webpage
<https://wso2.com/api-management/api-microgateway/#>.

*What's new in 3.2.0*

*New Features*

   - Back end JWT generation
   - Custom claim mapping for JWT
   - Custom and blocking condition support for global rate limiting
   - Advance endpoint configurations
   More 3.2.0 new features...
   
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3A%22Type%2FNew+Feature%22>

*Improvements*

   - Support reading open API definition in interceptors
   - Support reading configurations from java interceptors
   - Per API mutual SSL support
   - Binary publisher to support publishing to multiple TMs
   More 3.2.0 improvements
   
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FImprovement>


*Bug Fixes*
Fixed Issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>

*Known Issues*
Open Issues
<https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93=is%3Aopen+is%3Aissue>

*Try It.*
https://mg.docs.wso2.com/en/latest/getting-started/quick-start-guide/quick-start-guide-docker/

*Documentation*
https://mg.docs.wso2.com/en/latest/

*How You Can Contribute*

   - *Reporting Issues*
   We encourage you to report issues, documentation faults, and feature
   requests regarding WSO2 API Microgateway through the Github Issues.

   - *Contributing Code*
   Read through project Contribution Guidelines
   <https://github.com/wso2/product-microgateway/blob/master/CONTRIBUTING.md>
to
   learn how to contribute with code.

   - *Mailing Lists*
   Join our mailing list and receive updates on product development.
   Developer List: d...@wso2.org

   -
*User Forum * StackOverflow
   <https://stackoverflow.com/questions/tagged/wso2-mgw>

   - Join us on Slack
   
<https://join.slack.com/t/wso2-apim/shared_invite/zt-93qbqzja-gIJ21SJNQgz9uPffte_yPQ>


*--WSO2 API Manager Team--*

-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Menaka Jayawardena]

Hi all,

Thank you very much for testing the WSO2 API Microgateway 3.2.0-RC2.

Since this vote has passed with 12 [+1]s and 0 [-1]s, we’re hereby closing
the vote and proceeding with the WSO2 API Microgateway 3.2.0 GA release.

Thanks and Regards,
Menaka



On Wed, Aug 26, 2020 at 1:30 PM Rivindu Madushan  wrote:

> Hi all,
>
> I have tested the Microgateway 3.2.0 RC2 toolkit and docker runtime for Open
> Banking use cases with CDS-AU mgw docker image. The following scenarios
> were covered.
> - Adding custom filters
> - Adding interceptors
> - Using a custom production endpoint.
> - Oauth flows
> - Ballerina interceptors
> - Use of deployment.toml
>
> No issues found
> *[+] Stable* - Go ahead and release
>
> Thanks
> Rivindu
>
> On Wed, Aug 26, 2020 at 1:08 PM Nadee Poornima  wrote:
>
>> Hi all,
>>
>> [resending as earlier email got blocked]
>>
>> I think what you have explained should be the migration guide for 3.2.0.
>>>> I think we need to get it added to the docs. Even if there are zero steps
>>>> to be followed, that itself should be mentioned in the docs under migration
>>>> because otherwise the users will be in doubt.
>>>
>>>
>>> Noted. We will update the docs.
>>>
>>
>> I have created a doc issue[1] to add the migration process for MGW
>> product. Appreciate to fix this issue before releasing the product.
>>
>> [1]. https://github.com/wso2/docs-mg/issues/38
>>
>> Cheers,
>> Nadee
>>
>> On Wed, Aug 26, 2020 at 1:06 PM Malintha Amarasinghe 
>> wrote:
>>
>>> Hi all,
>>> [resending as earlier email got blocked]
>>>
>>> Tested followings,
>>>
>>> 1. Binary QSG
>>> 2. API Key and OAuth Authentication
>>> 3. Mutual SSL for client
>>> 4. Importing an API from API Manager and building a MicroGW, invoking
>>> with OAuth Token
>>>
>>> No blockers found.
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Thanks!
>>>
>>> On Wed, Aug 26, 2020 at 11:54 AM Shalki Wenushika 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Tested followings,
>>>>
>>>>- Testing on windows
>>>>- Schema validation
>>>>- Disable security for APIs
>>>>
>>>> No blockers found.
>>>>
>>>> *[+] Stable - Go ahead and release*
>>>>
>>>> Thanks,
>>>> Shalki.
>>>> *Shalki Wenushika *| Software Engineer | WSO2 Inc.
>>>> (m) +94716792399 | (e) sha...@wso2.com
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>>> On Tue, Aug 25, 2020 at 10:06 PM Praminda Jayawardana <
>>>> prami...@wso2.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Tested followings,
>>>>>
>>>>>- Docker QSG
>>>>>- Per API mutual ssl
>>>>>- Compatibility with apictl
>>>>>- JWT/Opaque token revocation
>>>>>- Kubernetes artifact generation and functionality
>>>>>- Service discovery with etcd
>>>>>- Compatibility with WSO2 APIM 2.6.0
>>>>>- Basic auth protected backend
>>>>>- Basic auth authentication
>>>>>
>>>>> No blockers found.
>>>>>
>>>>> *[+] Stable - Go ahead and release*
>>>>>
>>>>> Thanks,
>>>>> Praminda
>>>>>
>>>>> On Tue, Aug 25, 2020 at 2:39 PM Heshan Sudarshana 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Tested the following scenarios for Microgateway 3.2.0 RC2.
>>>>>>
>>>>>>- HTTP2 support
>>>>>>- Global throttling (API, resource, application, subscription
>>>>>>levels)
>>>>>>- Mutual SSL (mandatory/optional)
>>>>>>- API level throttle tiers
>>>>>>- API Resource level throttle tiers
>>>>>>- Custom policy throttling and blocking conditions
>>>>>>- Conditional Throttling
>>>>>>
>>>>>> No blockers found.
>>>>>>
>>>>>> *[+] Stable* - Go ahead and release
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Heshan.
>>>>>>
>

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Menaka Jayawardena]

Hi all,

I have tested the following.

   - Basic OAuth token scenario
   - Oauth(opaque tokens) with scopes
   - Oauth(opaque tokens) subscription validation
   - Backend JWT generation when OAuth is used
   - Gw cache for OAuth scenario
   - External key managers
   - Multiple JWT issuers
   - API auth key issue
   - API auth key authentication
   - API auth key authentication(API key taken from APIM 3.2.0)
   - Combined auth schemes
   - New Subscription Model


No blockers found.
[+] Stable - Go ahead and release.


On Tue, Aug 25, 2020 at 10:06 PM Praminda Jayawardana 
wrote:

> Hi all,
>
> Tested followings,
>
>- Docker QSG
>- Per API mutual ssl
>- Compatibility with apictl
>- JWT/Opaque token revocation
>- Kubernetes artifact generation and functionality
>- Service discovery with etcd
>- Compatibility with WSO2 APIM 2.6.0
>- Basic auth protected backend
>- Basic auth authentication
>
> No blockers found.
>
> *[+] Stable - Go ahead and release*
>
> Thanks,
> Praminda
>
> On Tue, Aug 25, 2020 at 2:39 PM Heshan Sudarshana 
> wrote:
>
>> Hi all,
>>
>> Tested the following scenarios for Microgateway 3.2.0 RC2.
>>
>>- HTTP2 support
>>- Global throttling (API, resource, application, subscription levels)
>>- Mutual SSL (mandatory/optional)
>>- API level throttle tiers
>>- API Resource level throttle tiers
>>- Custom policy throttling and blocking conditions
>>- Conditional Throttling
>>
>> No blockers found.
>>
>> *[+] Stable* - Go ahead and release
>>
>> Thanks and regards,
>> Heshan.
>>
>> On Tue, Aug 25, 2020 at 1:19 AM Chashika Weerathunga 
>> wrote:
>>
>>> Hi all,
>>>
>>> Tested the following scenarios for Microgateway 3.2.0 RC2.
>>>
>>>
>>>- Microgateway labeling
>>>- Microgateway analytics report
>>>- Analytics file writing
>>>- Analytics file uploading/publishing
>>>- Analytics GRPC publishing
>>>- Endpoint override for imported APIs
>>>- Endpoint override for Developer-first Approach APIs
>>>- Load balance and failover endpoints
>>>- Custom header and header sent to back end
>>>- Java interceptors
>>>- Ballerina interceptors
>>>- Advance endpoint configurations
>>>
>>>
>>> No blockers found.
>>>
>>> *[+] Stable* - Go ahead and release
>>>
>>> Thanks & Regards
>>>
>>> On Mon, Aug 24, 2020 at 2:22 PM Menaka Jayawardena 
>>> wrote:
>>>
>>>> Hi Amila,
>>>>
>>>> I think what you have explained should be the migration guide for
>>>>> 3.2.0. I think we need to get it added to the docs. Even if there are zero
>>>>> steps to be followed, that itself should be mentioned in the docs under
>>>>> migration because otherwise the users will be in doubt.
>>>>
>>>>
>>>> Noted. We will update the docs.
>>>>
>>>> Thanks and Regards,
>>>> Menaka
>>>>
>>>> On Mon, Aug 24, 2020 at 2:08 PM Nadee Poornima  wrote:
>>>>
>>>>> Hi Menaka,
>>>>> Thanks for the detailed explanation.
>>>>>
>>>>> I think what you have explained should be the migration guide for
>>>>>> 3.2.0. I think we need to get it added to the docs. Even if there are 
>>>>>> zero
>>>>>> steps to be followed, that itself should be mentioned in the docs under
>>>>>> migration because otherwise the users will be in doubt.
>>>>>
>>>>>
>>>>> +1 for this.
>>>>>
>>>>> Cheers,
>>>>> Nadee
>>>>>
>>>>> On Mon, Aug 24, 2020 at 2:00 PM Amila Maha Arachchi 
>>>>> wrote:
>>>>>
>>>>>> Hi Menaka,
>>>>>>
>>>>>> I think what you have explained should be the migration guide for
>>>>>> 3.2.0. I think we need to get it added to the docs. Even if there are 
>>>>>> zero
>>>>>> steps to be followed, that itself should be mentioned in the docs under
>>>>>> migration because otherwise the users will be in doubt.
>>>>>>
>>>>>> Regards,
>>>>>> Amila.
>>>>>>
>>>>>> On Mon, Aug 24, 2020 at 12:54 PM Menaka Jayawardena 
>>>>>> wrote:
>

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Menaka Jayawardena]

Hi Amila,

I think what you have explained should be the migration guide for 3.2.0. I
> think we need to get it added to the docs. Even if there are zero steps to
> be followed, that itself should be mentioned in the docs under migration
> because otherwise the users will be in doubt.


Noted. We will update the docs.

Thanks and Regards,
Menaka

On Mon, Aug 24, 2020 at 2:08 PM Nadee Poornima  wrote:

> Hi Menaka,
> Thanks for the detailed explanation.
>
> I think what you have explained should be the migration guide for 3.2.0. I
>> think we need to get it added to the docs. Even if there are zero steps to
>> be followed, that itself should be mentioned in the docs under migration
>> because otherwise the users will be in doubt.
>
>
> +1 for this.
>
> Cheers,
> Nadee
>
> On Mon, Aug 24, 2020 at 2:00 PM Amila Maha Arachchi 
> wrote:
>
>> Hi Menaka,
>>
>> I think what you have explained should be the migration guide for 3.2.0.
>> I think we need to get it added to the docs. Even if there are zero steps
>> to be followed, that itself should be mentioned in the docs under migration
>> because otherwise the users will be in doubt.
>>
>> Regards,
>> Amila.
>>
>> On Mon, Aug 24, 2020 at 12:54 PM Menaka Jayawardena 
>> wrote:
>>
>>> Hi Nadee,
>>>
>>> By default, Microgateway does not require any migration process. You can
>>> build the mgw project using the Microgateway 3.2.0 toolkit and run with the
>>> Microgateway 3.2.0 runtime with the old configurations. (Ex. build 3.1.0
>>> project with 3.2.0 toolkit and run with 3.2.0 runtime with the 3.1.0
>>> configs)
>>> All most all of the configurations are backwards compatible and there
>>> are only few config level changes which will be updated in the docs.
>>> (related to authentication and subscription validation).
>>>
>>> Migration would only be required if you have any customizations written
>>> in ballerina.
>>>
>>> Thanks and Regards,
>>> Menaka
>>>
>>> On Mon, Aug 24, 2020 at 11:37 AM Nadee Poornima  wrote:
>>>
>>>> Hi Menaka,
>>>>
>>>> Analysed the Micro GW documents[1], however, didn't see any document
>>>> relating the migration process (upgrade process) from Micro GW 3.1.0 to
>>>> Micro GW 3.2.0.
>>>> Is there any specific process to migrate Micro GW product? How we can
>>>> do that?
>>>>
>>>> Appreciate your valuable thought here.
>>>>
>>>> [1]. https://mg.docs.wso2.com/en/latest/#
>>>>
>>>> Cheers,
>>>> Nadee
>>>>
>>>> On Sat, Aug 22, 2020 at 4:10 PM Menaka Jayawardena 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> WSO2 Api Manager team is pleased to announce the second release
>>>>> candidate of WSO2 API Microgateway 3.2.0.
>>>>>
>>>>> The WSO2 API Microgateway is a lightweight, gateway distribution which
>>>>> can be used to expose single or multiple APIs.
>>>>>
>>>>> Please find the improvements and fixes related to this release in Fixed
>>>>> issues
>>>>> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>
>>>>>
>>>>> Download the product from here
>>>>> <https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc2>
>>>>>
>>>>> The Tag to be voted upon is
>>>>> https://github.com/wso2/product-microgateway/tree/v3.2.0-rc2
>>>>>
>>>>> *Documentation*: https://mg.docs.wso2.com/en/latest/
>>>>>
>>>>> Please download, test the product and vote.
>>>>>
>>>>> *[+] Stable* - Go ahead and release
>>>>>
>>>>> *[-] Broken* - Do not release (explain why)
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> WSO2 API Manager Team
>>>>>
>>>>>
>>>>> --
>>>>> *Menaka Jayawardena*
>>>>> Senior Software Engineer *|* *WSO2* *Inc*.
>>>>> +94 71 350 5470 | men...@wso2.com
>>>>>
>>>>> <https://wso2.com/signature>
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Nadee Poornima*
>>>> Software Engineer | WSO2
>>>>
>>>> Email : nad...@wso2.com
>>>> Mobile : +94713441341
>>>> MyBlog: https://medium.com/nadees-tech-stories
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>> *Menaka Jayawardena*
>>> Senior Software Engineer *|* *WSO2* *Inc*.
>>> +94 71 350 5470 | men...@wso2.com
>>>
>>> <https://wso2.com/signature>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> *Amila Mahaarachchi*
>> VP of Engineering, Integration
>> WSO2, Inc.; http://wso2.com
>> Mobile: +94719371446
>>
>> <http://wso2.com/signature>
>>
>>
>
> --
> *Nadee Poornima*
> Software Engineer | WSO2
>
> Email : nad...@wso2.com
> Mobile : +94713441341
> MyBlog: https://medium.com/nadees-tech-stories
>
> <https://wso2.com/signature>
>


-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev][Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Menaka Jayawardena]

Hi Nadee,

By default, Microgateway does not require any migration process. You can
build the mgw project using the Microgateway 3.2.0 toolkit and run with the
Microgateway 3.2.0 runtime with the old configurations. (Ex. build 3.1.0
project with 3.2.0 toolkit and run with 3.2.0 runtime with the 3.1.0
configs)
All most all of the configurations are backwards compatible and there are
only few config level changes which will be updated in the docs. (related
to authentication and subscription validation).

Migration would only be required if you have any customizations written in
ballerina.

Thanks and Regards,
Menaka

On Mon, Aug 24, 2020 at 11:37 AM Nadee Poornima  wrote:

> Hi Menaka,
>
> Analysed the Micro GW documents[1], however, didn't see any document
> relating the migration process (upgrade process) from Micro GW 3.1.0 to
> Micro GW 3.2.0.
> Is there any specific process to migrate Micro GW product? How we can do
> that?
>
> Appreciate your valuable thought here.
>
> [1]. https://mg.docs.wso2.com/en/latest/#
>
> Cheers,
> Nadee
>
> On Sat, Aug 22, 2020 at 4:10 PM Menaka Jayawardena 
> wrote:
>
>> Hi All,
>>
>> WSO2 Api Manager team is pleased to announce the second release candidate
>> of WSO2 API Microgateway 3.2.0.
>>
>> The WSO2 API Microgateway is a lightweight, gateway distribution which
>> can be used to expose single or multiple APIs.
>>
>> Please find the improvements and fixes related to this release in Fixed
>> issues
>> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>
>>
>> Download the product from here
>> <https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc2>
>>
>> The Tag to be voted upon is
>> https://github.com/wso2/product-microgateway/tree/v3.2.0-rc2
>>
>> *Documentation*: https://mg.docs.wso2.com/en/latest/
>>
>> Please download, test the product and vote.
>>
>> *[+] Stable* - Go ahead and release
>>
>> *[-] Broken* - Do not release (explain why)
>>
>>
>> Best Regards,
>> WSO2 API Manager Team
>>
>>
>> --
>> *Menaka Jayawardena*
>> Senior Software Engineer *|* *WSO2* *Inc*.
>> +94 71 350 5470 | men...@wso2.com
>>
>> <https://wso2.com/signature>
>>
>>
>
> --
> *Nadee Poornima*
> Software Engineer | WSO2
>
> Email : nad...@wso2.com
> Mobile : +94713441341
> MyBlog: https://medium.com/nadees-tech-stories
>
> <https://wso2.com/signature>
>


-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev][Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Menaka Jayawardena]

Hi All,

WSO2 Api Manager team is pleased to announce the second release candidate
of WSO2 API Microgateway 3.2.0.

The WSO2 API Microgateway is a lightweight, gateway distribution which can
be used to expose single or multiple APIs.

Please find the improvements and fixes related to this release in Fixed
issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>

Download the product from here
<https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc2>

The Tag to be voted upon is
https://github.com/wso2/product-microgateway/tree/v3.2.0-rc2

*Documentation*: https://mg.docs.wso2.com/en/latest/

Please download, test the product and vote.

*[+] Stable* - Go ahead and release

*[-] Broken* - Do not release (explain why)


Best Regards,
WSO2 API Manager Team


-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [DEV][VOTE] Release WSO2 API Microgateway 3.2.0 RC1

[Menaka Jayawardena]

Hi all,

We are cancelling this vote since we have identified some issues in the
product.
We will send a new vote for Microgateway 3.2.0 RC2 with the issues fixed.

Thanks and regards,
Menaka

On Mon, Aug 17, 2020, 4:44 PM Viraj Gamage  wrote:

> Hi all,
>
> Tested the following scenarios.
>
>- Invoke APIs using JWT/ JTI claim with APIM 3.2.0
>- Check scopes functionality using JWT/ JTI claim with APIM 3.2.0
>- Subscription Validation using JWT/JTI claim with APIM 3.2.0
>- JWTs with JWKS endpoint
>- JWTs from Third party STS
>- Large payload downloads.
>
> Encountered the following issues.
>
>- When the third party token does not contain required scopes, the
>error message does not contain the microgateway specific error code.
>
> Hence -1.
>
> On Mon, Aug 17, 2020 at 1:31 PM Chashika Weerathunga 
> wrote:
>
>> Hi all,
>>
>> Tested followings scenarios,
>>
>>- Endpoint override for imported APIs
>>- Micro gw labeleing
>>- Load balance and fail over endpoints
>>- Custom header and header sent to back end
>>- Java interceptors
>>
>> No issues found.
>>
>> *[+] Stable* - Go ahead and release
>>
>> On Mon, Aug 17, 2020 at 1:23 PM Praminda Jayawardana 
>> wrote:
>>
>>> Tested followings scenarios,
>>>
>>>- Docker quick start guide
>>>- Securing APIs with basic auth
>>>- OpenAPI 2/3 and yaml/json compatibility
>>>- Resource level endpoint definitions
>>>- Basic auth protected backend endpoints
>>>- Compatibility with WSO2 APIM 2.6.0
>>>
>>> No issues found.
>>>
>>> *[+] Stable* - Go ahead and release
>>>
>>> On Fri, Aug 14, 2020 at 7:03 PM Menaka Jayawardena 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> WSO2 Api Manager team is pleased to announce the first release
>>>> candidate of WSO2 API Microgateway 3.2.0.
>>>>
>>>> The WSO2 API Microgateway is a lightweight, gateway distribution which
>>>> can be used to expose single or multiple APIs.
>>>>
>>>> Please find the improvements and fixes related to this release in Fixed
>>>> issues
>>>> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>
>>>>
>>>> Download the product from here
>>>> <https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc1>
>>>>
>>>> The Tag to be voted upon is
>>>> https://github.com/wso2/product-microgateway/tree/v3.2.0-rc1
>>>>
>>>> *Documentation*: https://mg.docs.wso2.com/en/latest/
>>>>
>>>> Please download, test the product and vote.
>>>>
>>>> *[+] Stable* - Go ahead and release
>>>>
>>>> *[-] Broken* - Do not release (explain why)
>>>>
>>>>
>>>> Best Regards,
>>>> WSO2 API Manager Team
>>>>
>>>> --
>>>> *Menaka Jayawardena*
>>>> Senior Software Engineer *|* *WSO2* *Inc*.
>>>> +94 71 350 5470 | men...@wso2.com
>>>>
>>>> --
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>> *Praminda Jayawardana* | Associate Technical Lead | WSO2 Inc.
>>>> 
>>>> (e) prami...@wso2.com
>>>>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> *Chashika Weerathunga* | Software Engineer | WSO2 Inc.
>> (m) +94713731206 | Email: chash...@wso2.com
>> [image: http://wso2.com]
>> <http://wso2.com>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
> +94 710 618 178
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [DEV][VOTE] Release WSO2 API Microgateway 3.2.0 RC1

[Menaka Jayawardena]

Hi All,

WSO2 Api Manager team is pleased to announce the first release candidate of
WSO2 API Microgateway 3.2.0.

The WSO2 API Microgateway is a lightweight, gateway distribution which can
be used to expose single or multiple APIs.

Please find the improvements and fixes related to this release in Fixed
issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>

Download the product from here
<https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc1>

The Tag to be voted upon is
https://github.com/wso2/product-microgateway/tree/v3.2.0-rc1

*Documentation*: https://mg.docs.wso2.com/en/latest/

Please download, test the product and vote.

*[+] Stable* - Go ahead and release

*[-] Broken* - Do not release (explain why)


Best Regards,
WSO2 API Manager Team

-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Microgateway 3.2.0-Beta Released!

[Menaka Jayawardena]

The WSO2 API Manager team is pleased to announce the release of API
Microgateway version 3.2.0-Beta.
It's now available to download.Download
wso2am-micro-gw-3.2.0-beta
<https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-beta>

Bug Fixes and Improvements in 3.2.0-Beta

Fixed Issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+is%3Aclosed+milestone%3A3.2.0-beta>
Known Issues

Open Issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aopen+is%3Aissue>
Try it

https://mg.docs.wso2.com/en/latest/getting-started/quick-start-guide/quick-start-guide-overview/
Documentation

https://mg.docs.wso2.com/
How You Can Contribute

   -

   *Reporting Issues*
   We encourage you to report issues, documentation faults, and feature
   requests regarding WSO2 API Microgateway through the Github Issues
   <https://github.com/wso2/product-microgateway/issues>.
   -

   *Contributing Code*
   Read through project Contribution Guidelines
   <https://github.com/wso2/product-microgateway/blob/master/CONTRIBUTING.md>
to
   learn how to contribute with code.
   -

   *Mailing Lists*
   Join our mailing list and receive updates on product development.
   Developer List: d...@wso2.org
   -

   *User Forum*
   Go through the StackOverflow
   <https://stackoverflow.com/questions/tagged/wso2-mgw>
   -

   *Slack channels*
   Join us via our wso2-apim.slack.com for even better communication. You
   can talk to our developers directly regarding any issues, concerns about
   the product. We encourage you to start discussions or join any ongoing
   discussions with the team, via our slack channels.
 - Discussions about developments: Dev Channel
   <https://wso2-apim.slack.com/messages/microgateway>
 - New releases: Release Announcement Channel
   <https://wso2-apim.slack.com/messages/announcements>

*--WSO2 API Manager Team--*

-- 
*Menaka Jayawardena*
Senior Software Engineer *|* *WSO2* *Inc*.
+94 71 350 5470 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 API Manager 3.0.0 RC3

[Menaka Jayawardena]

gt;>>>> Hi All,
>>>>>>
>>>>>> We are pleased to announce the second release candidate of WSO2 API
>>>>>> Manager 3.0.0.
>>>>>>
>>>>>> This release fixes the following issues.
>>>>>>
>>>>>>- Fixes : product-apim
>>>>>>
>>>>>> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>>>>>>- Fixes : carbon-apimgt
>>>>>>
>>>>>> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24+>
>>>>>>- Fixes : analytics-apim
>>>>>>
>>>>>> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>>>>>>
>>>>>> Source and distribution,
>>>>>> Runtime :
>>>>>> https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc3
>>>>>> Analytics :
>>>>>> https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc3
>>>>>> APIM Tooling :
>>>>>> https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc
>>>>>>
>>>>>> Please download, test the product and vote.
>>>>>>
>>>>>> [+] Stable - go ahead and release
>>>>>> [-] Broken - do not release (explain why)
>>>>>>
>>>>>> Thanks,
>>>>>> WSO2 API Manager Team
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Samitha Chathuranga*
>>>>>> *Senior Software Engineer*, *WSO2 Inc.*
>>>>>> lean.enterprise.middleware
>>>>>> Mobile: +94715123761
>>>>>>
>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mushthaq Rumy
>>>>> *Senior Software Engineer*
>>>>> Mobile : +94 (0) 779 492140
>>>>> Email : musht...@wso2.com
>>>>> WSO2, Inc.; http://wso2.com/
>>>>> lean . enterprise . middleware.
>>>>>
>>>>> <http://wso2.com/signature>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>> Chamin Dias
>>>> Mobile : 0716097455
>>>> Email : cham...@wso2.com
>>>> LinkedIn : https://www.linkedin.com/in/chamindias
>>>>
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>
>>>
>>> --
>>> *Kavishka Fernando*
>>> *Software Engineer | WSO2*
>>> Email: kavis...@wso2.com
>>> Mobile:  +94773838069
>>> Web: http://wso2.com
>>> Blog: https://medium.com/@kavishkafernando
>>>
>>> <http://wso2.com/signature>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 

*Menaka Jayawardena*
Senior Software Engineer | WSO2 Inc.
+94 71 350 5470 | +94 76 717 2511 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 API Manager 3.0.0 RC2

[Menaka Jayawardena]

Tested the following.

- New API creation/ invocation.
- Websocket api creation and invocation.
- API product creation and invocation
- Advanced throttling policies
- Create new version of the api
- Invoke api with dynamic ssl certificates applied. (Protected backends)
- Tested mock endpoints.

No blockers found. +1

On Thu, Oct 24, 2019 at 8:51 AM Mushthaq Rumy  wrote:

> Hi All,
>
> We are pleased to announce the second release candidate of WSO2 API
> Manager 3.0.0.
>
> This release fixes the following issues.
>
>- Fixes : carbon-apimgt
>
> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23+>
>- Fixes : product-apim
>
> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23>
>- Fixes : analytics-apim
>
> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-23>
>
> Source and distribution,
> Runtime : https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc2
> Analytics :
> https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc2
> APIM Tooling :
> https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> WSO2 API Manager Team
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
> ___________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 

*Menaka Jayawardena*
Senior Software Engineer | WSO2 Inc.
+94 71 350 5470 | +94 76 717 2511 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM-3.0] Publisher rest API to check a role name existence

[Menaka Jayawardena]

gt;>>>>>>> Access Control and Store Visibility and when adding Scopes.
>>>>>>>>>>
>>>>>>>>>> The swagger definition for the new endpoint would be as follows.
>>>>>>>>>>
>>>>>>>>>> ##
>>>>>>>>>> # The Role Name Existence
>>>>>>>>>> ##
>>>>>>>>>>   /roles/{roleName}:
>>>>>>>>>> #-
>>>>>>>>>> # The role name existence check resource
>>>>>>>>>> #-
>>>>>>>>>> head:
>>>>>>>>>>   security:
>>>>>>>>>> - OAuth2Security:
>>>>>>>>>> - apim:api_view
>>>>>>>>>>   summary: |
>>>>>>>>>> Check given role name is already exist
>>>>>>>>>>   description: |
>>>>>>>>>> Using this operation, you can check a given role name
>>>>>>>>>> is already used. You need to provide the role name you want to check.
>>>>>>>>>>   parameters:
>>>>>>>>>> - $ref : '#/parameters/roleName'
>>>>>>>>>>   responses:
>>>>>>>>>> 200:
>>>>>>>>>>   description: |
>>>>>>>>>> OK.
>>>>>>>>>> Requested role name is returned.
>>>>>>>>>> 404:
>>>>>>>>>>   description: |
>>>>>>>>>> Not Found.
>>>>>>>>>> Requested role name does not exist.
>>>>>>>>>> ##
>>>>>>>>>> # Role Name
>>>>>>>>>>   roleName:
>>>>>>>>>> name: roleName
>>>>>>>>>> in: path
>>>>>>>>>> description: |
>>>>>>>>>>   The role name
>>>>>>>>>> required: true
>>>>>>>>>> type: string
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is a HEAD method (*/roles/{roleName}*) which will return a
>>>>>>>>>> 200 status code if the given role name exists and a 404 status code 
>>>>>>>>>> if the
>>>>>>>>>> give role name is not found. Sample requests and responses are given 
>>>>>>>>>> below.
>>>>>>>>>>
>>>>>>>>>> Request:
>>>>>>>>>> HEAD
>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/valid-role
>>>>>>>>>> HTTP/1.1
>>>>>>>>>> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>>>>>>>>
>>>>>>>>>> Response:
>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>> Connection: keep-alive
>>>>>>>>>> Content-Length: 0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Request:
>>>>>>>>>> HEAD
>>>>>>>>>> https://localhost:9443/api/am/publisher/v1.0/roles/invalid-role
>>>>>>>>>> HTTP/1.1
>>>>>>>>>> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>>>>>>>>
>>>>>>>>>> Response:
>>>>>>>>>> HTTP/1.1 404 Not Found
>>>>>>>>>> Connection: keep-alive
>>>>>>>>>> Content-Length: 0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Are we good to have the endpoint definition as this? Appreciate
>>>>>>>>>> your inputs to proceed further.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Naduni
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
>>>>>>>>>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Harsha Kumara*
>>>>>>>>>
>>>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>>>> Mobile: +94775505618
>>>>>>>>> Email: hars...@wso2.coim
>>>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>>>
>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mushthaq Rumy
>>>>>>>> *Senior Software Engineer*
>>>>>>>> Mobile : +94 (0) 779 492140
>>>>>>>> Email : musht...@wso2.com
>>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>>> lean . enterprise . middleware.
>>>>>>>>
>>>>>>>> <http://wso2.com/signature>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mushthaq Rumy
>>>>>>> *Senior Software Engineer*
>>>>>>> Mobile : +94 (0) 779 492140
>>>>>>> Email : musht...@wso2.com
>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>> lean . enterprise . middleware.
>>>>>>>
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Harsha Kumara*
>>>>>>
>>>>>> Technical Lead, WSO2 Inc.
>>>>>> Mobile: +94775505618
>>>>>> Email: hars...@wso2.coim
>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Malintha Amarasinghe
>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>> http://wso2.com/
>>>>>
>>>>> Mobile : +94 712383306
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Harsha Kumara*
>>>>
>>>> Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Email: hars...@wso2.coim
>>>> Blog: harshcreationz.blogspot.com
>>>>
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>>
>>
>>
>> --
>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
>> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>>
>>
>>
>
> --
> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>

-- 

*Menaka Jayawardena*
Senior Software Engineer | WSO2 Inc.
+94 71 350 5470 | +94 76 717 2511 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [DEV] [VOTE] Release WSO2 API Microgateway 3.0.1 RC3

[Menaka Jayawardena]

Tested following.
- Basic flow with JWT token
- Resource level throttling
- Request/ Response intercepting.

No blockers found.
*[+] Stable - Go ahead and release*

On Mon, Jun 10, 2019 at 4:26 PM Praminda Jayawardana 
wrote:

> Tested followings,
>
>- Basic flow with import APIs
>- Basic Auth
>- Analytics file writing/ uploading/ APIM Dashboard visibility
>
> No blockers found.
> *[+] Stable - Go ahead and release*
>
> Thanks,
> Praminda
>
> On Mon, Jun 10, 2019 at 2:01 PM Rajith Roshan  wrote:
>
>> Tested the following scenarios.
>>
>>
>>- Basic throttling
>>- Custom application throttling for open API based api and imported
>>APIs
>>- Custom subscription throttling for imported APIs
>>- Global throttling
>>- Basic flow in dev first approach
>>- Load balance and fail over endpoints
>>
>> No blockers found.
>> *[+] Stable - Go ahead and release*
>>
>> Thanks!
>> Rajith
>>
>> On Sun, Jun 9, 2019 at 10:25 AM Praminda Jayawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> WSO2 Api Manager team is pleased to announce the third release candidate
>>> of WSO2 API Microgateway 3.0.1.
>>>
>>> The WSO2 API Microgateway is a lightweight, gateway distribution which
>>> can be used with single or multiple APIs.
>>>
>>> Please find the improvements and fixes related to this release in Fixed
>>> issues
>>> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93=is%3Aissue+closed%3A2018-10-12..2019-06-09>
>>>
>>> Download the product from here
>>> <https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3>
>>>
>>> The Tag to be voted upon is
>>> https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3
>>>
>>> Please download, test the product and vote.
>>>
>>> *[+] Stable - Go ahead and release*
>>>
>>> *[-] Broken - Do not release *(explain why)
>>>
>>>
>>> Documentation: https://docs.wso2.com/display/MG301/
>>>
>>> Best Regards,
>>> WSO2 API Manager Team
>>>
>>
>>
>> --
>> *Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
>> (m) +94-717-064-214 |  (e) raji...@wso2.com 
>>
>> <https://wso2.com/signature>
>>
>
>
> --
>
> *Praminda Jayawardana* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (0) 716 590918 | (e) prami...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 

*Menaka Jayawardena*
Senior Software Engineer | WSO2 Inc.
+94 71 350 5470 | +94 76 717 2511 | men...@wso2.com

<https://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Carbon][RRT] Masking sensitive information in carbon logs.

[Menaka Jayawardena]

Hi all,

I am working on implementing the $subject.

*Requirement*.

The initial requirement was to add masking capability as an improvement for
the log mediator so that the users can configure the masking parameters
(for EI and APIM). But due to the fact that this can be applied globally
(wire logs, debug logs etc), it was decided to implement this as new log
appenders, which can be used by any product.

*Configuration*

For this feature, the following configuration should be done.
1. Log appender should be added to log4j.properties
2. A new properties file which contains the masking parameters (regex)
should be configured.

Example:
log4j.appender.CARBON_CONSOLE=org.wso2.carbon.utils.logging.appenders.MaskedCarbonConsoleAppender
log4j.appender.CARBON_CONSOLE.maskingPatternFile=[carbon_home]/repository/conf/wso2-log-masking.properties
.
.
.

log4j.appender.CARBON_LOGFILE=org.wso2.carbon.utils.logging.appenders.MaskedCarbonDailyRollingFileAppender
log4j.appender.CARBON_LOGFILE.maskingPatternFile=[carbon_home]/repository/conf/wso2-log-masking.properties


*wso2-log-masking.properties file configs:*
wso2.masking.pattern.AccountNo=/^(?:[0-9]{11}|[0-9]{2}-[0-9]{3}-[0-9]{6})$/
wso2.masking.pattern.CardNumber=^5[1-5][0-9]{0,14}|
^(222[1-9]|2[3-6]\\d{2}|27[0-1]\\d|2720)[0-9]{0,12}
.
.
.

The maskingPatternFile can be configured as required. If not, as the
default wso2-log-masking.properties file will be used. (which will be an
added file.)

Any ideas comments are highly appreciated.

Thanks and Regards,
Menaka
-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Menaka Jayawardena]

Hi Isuru,

The certificate will be added to the nodes that are configured in
Environments in the api-manager.xml. If there is a gateway cluster, only
the manager node trust store will be updated. So we need to sync the trust
store and the sslprofiles.xml file among the other nodes in the cluster.
This should be done manually.

Thanks and Regards,
Menaka


On Wed, Jul 18, 2018 at 1:30 PM, Isuru Haththotuwa  wrote:

> Hi Menaka,
>
> In this feature, if there are a more than one Gateway nodes, how do we
> handle the trust store synchronization across those?
>
> Sorry about the extremely late question.
>
> On Wed, Jul 11, 2018 at 5:32 PM, Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>> I had an offline discussion with Sanjeewa and Malintha regarding the rest
>> API convention of using uuid instead of certificate alias.
>>
>> But, for this feature, if we adopt the UUID approach, there will be a DB
>> level modification and method signature changes. In the current approach,
>> the certificate alias is considered as the unique attribute. So, for this
>> implementation, instead of using uuid, we will be using the alias as the
>> certificate identifier.
>>
>> In the next APIM releases, necessary modifications will be done to the
>> implementation.
>>
>> Thanks and Regards,
>> Menaka
>>
>> On Tue, Jul 10, 2018 at 4:41 PM, Malintha Amarasinghe > > wrote:
>>
>>>
>>>
>>> On Tue, 10 Jul 2018, 14:40 Sanjeewa Malalgoda, 
>>> wrote:
>>>
>>>> In our REST API design we keep using UUID to represent path to atomic
>>>> resource. Sometimes even we had unique attribute we still used auto
>>>> generated UUID. If we are using alias to identify resource within resource
>>>> collection we are deviating from that convention. So i think we need to
>>>> think about this again.
>>>> @Malintha Amarasinghe   Thoughts?
>>>>
>>>
>>> +1. Having get certificates using UUID (GET /certificates/{uuid}) is a
>>> better approach which is also consistent with other resources we already
>>> have. Similarly we can do PUT and DELETE to the same resource. To get a
>>> certificate by alias I think we can use the search functionality. (GET
>>> /certificates?alias=wso2carbon)
>>>
>>> Thanks,
>>> Malintha
>>>
>>>
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>> On Tue, Jul 10, 2018 at 2:24 PM Menaka Jayawardena 
>>>> wrote:
>>>>
>>>>> Hi  Mushthaq/ Fazlan,
>>>>>
>>>>> Thank you very much for the suggestions.
>>>>>
>>>>> I have used the resource path as* '/certificates/{alias}/info'*
>>>>> because it's self-explanatory. The main objective of the API (the initial
>>>>> thought) is to get the status of the certificate. (Whether it is expired 
>>>>> or
>>>>> not and the expiry date). But, we can extend this to get other basic
>>>>> information as well.
>>>>>
>>>>> So, I also think that GET *'/certificates/{alias}*' is the better
>>>>> approach.
>>>>>
>>>>> Thanks and Regards,
>>>>> Menaka
>>>>>
>>>>>
>>>>> On Tue, Jul 10, 2018 at 2:02 PM, Fazlan Nazeem 
>>>>> wrote:
>>>>>
>>>>>> Hi Menaka,
>>>>>>
>>>>>> DELETE is expecting alias in a query param and GET is expecting it to
>>>>>> be passed in a path param. I think modifying DELETE as DELETE
>>>>>> certidicates/{alias} and GET as GET certificate/{alias} is more Restful.
>>>>>>
>>>>>> On Tue, Jul 10, 2018 at 12:09 PM Menaka Jayawardena 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm working on implementing a REST API for the Dynamic Certificate
>>>>>>> Installation feature for API Manager. (User stories
>>>>>>> <https://docs.google.com/document/d/1wZfv3gTL65FT-Jzs9CBYcVoIRFFNvSBuIJg3BiC_7PU/edit?usp=sharing>
>>>>>>> )
>>>>>>>
>>>>>>> The current implementation only supports add, retrieve and delete
>>>>>>> certificate functions. For the REST API, the following additional 
>>>>>>> functions
>>>>>>> will be added.
>>>>>>>
>>>&

Re: [Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Menaka Jayawardena]

Hi,

I had an offline discussion with Sanjeewa and Malintha regarding the rest
API convention of using uuid instead of certificate alias.

But, for this feature, if we adopt the UUID approach, there will be a DB
level modification and method signature changes. In the current approach,
the certificate alias is considered as the unique attribute. So, for this
implementation, instead of using uuid, we will be using the alias as the
certificate identifier.

In the next APIM releases, necessary modifications will be done to the
implementation.

Thanks and Regards,
Menaka

On Tue, Jul 10, 2018 at 4:41 PM, Malintha Amarasinghe 
wrote:

>
>
> On Tue, 10 Jul 2018, 14:40 Sanjeewa Malalgoda,  wrote:
>
>> In our REST API design we keep using UUID to represent path to atomic
>> resource. Sometimes even we had unique attribute we still used auto
>> generated UUID. If we are using alias to identify resource within resource
>> collection we are deviating from that convention. So i think we need to
>> think about this again.
>> @Malintha Amarasinghe   Thoughts?
>>
>
> +1. Having get certificates using UUID (GET /certificates/{uuid}) is a
> better approach which is also consistent with other resources we already
> have. Similarly we can do PUT and DELETE to the same resource. To get a
> certificate by alias I think we can use the search functionality. (GET
> /certificates?alias=wso2carbon)
>
> Thanks,
> Malintha
>
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Tue, Jul 10, 2018 at 2:24 PM Menaka Jayawardena 
>> wrote:
>>
>>> Hi  Mushthaq/ Fazlan,
>>>
>>> Thank you very much for the suggestions.
>>>
>>> I have used the resource path as* '/certificates/{alias}/info'* because
>>> it's self-explanatory. The main objective of the API (the initial thought)
>>> is to get the status of the certificate. (Whether it is expired or not and
>>> the expiry date). But, we can extend this to get other basic information as
>>> well.
>>>
>>> So, I also think that GET *'/certificates/{alias}*' is the better
>>> approach.
>>>
>>> Thanks and Regards,
>>> Menaka
>>>
>>>
>>> On Tue, Jul 10, 2018 at 2:02 PM, Fazlan Nazeem  wrote:
>>>
>>>> Hi Menaka,
>>>>
>>>> DELETE is expecting alias in a query param and GET is expecting it to
>>>> be passed in a path param. I think modifying DELETE as DELETE
>>>> certidicates/{alias} and GET as GET certificate/{alias} is more Restful.
>>>>
>>>> On Tue, Jul 10, 2018 at 12:09 PM Menaka Jayawardena 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm working on implementing a REST API for the Dynamic Certificate
>>>>> Installation feature for API Manager. (User stories
>>>>> <https://docs.google.com/document/d/1wZfv3gTL65FT-Jzs9CBYcVoIRFFNvSBuIJg3BiC_7PU/edit?usp=sharing>
>>>>> )
>>>>>
>>>>> The current implementation only supports add, retrieve and delete
>>>>> certificate functions. For the REST API, the following additional 
>>>>> functions
>>>>> will be added.
>>>>>
>>>>> 1. Update a certificate: Users can update an uploaded certificate.
>>>>> 2. Get certificate information: Retrieve the basic information of a
>>>>> certificate. i.e expiry date, etc.
>>>>>
>>>>> I have attached the swagger definition for the APIs herewith.
>>>>>
>>>>> Any suggestions, comments are highly appreciated.
>>>>>
>>>>> Thanks and Regards,
>>>>> Menaka
>>>>>
>>>>> --
>>>>>
>>>>> *Menaka Jayawardena*
>>>>> Senior Software Engineer
>>>>> WSO2 Inc.
>>>>>
>>>>> Phone: +94 71 350 5470
>>>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>>>>> Blog   : https://menakamadushanka.wordpress.com/
>>>>>
>>>>>
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> *Fazlan Nazeem*
>>>> Senior Software Engineer
>>>> WSO2 Inc
>>>> Mobile : +94772338839
>>>> fazl...@wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Menaka Jayawardena*
>>> Senior Software Engineer
>>> WSO2 Inc.
>>>
>>> Phone: +94 71 350 5470
>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>>> Blog   : https://menakamadushanka.wordpress.com/
>>>
>>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>


-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Menaka Jayawardena]

Hi  Mushthaq/ Fazlan,

Thank you very much for the suggestions.

I have used the resource path as* '/certificates/{alias}/info'* because
it's self-explanatory. The main objective of the API (the initial thought)
is to get the status of the certificate. (Whether it is expired or not and
the expiry date). But, we can extend this to get other basic information as
well.

So, I also think that GET *'/certificates/{alias}*' is the better approach.

Thanks and Regards,
Menaka


On Tue, Jul 10, 2018 at 2:02 PM, Fazlan Nazeem  wrote:

> Hi Menaka,
>
> DELETE is expecting alias in a query param and GET is expecting it to be
> passed in a path param. I think modifying DELETE as DELETE
> certidicates/{alias} and GET as GET certificate/{alias} is more Restful.
>
> On Tue, Jul 10, 2018 at 12:09 PM Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>> I'm working on implementing a REST API for the Dynamic Certificate
>> Installation feature for API Manager. (User stories
>> <https://docs.google.com/document/d/1wZfv3gTL65FT-Jzs9CBYcVoIRFFNvSBuIJg3BiC_7PU/edit?usp=sharing>
>> )
>>
>> The current implementation only supports add, retrieve and delete
>> certificate functions. For the REST API, the following additional functions
>> will be added.
>>
>> 1. Update a certificate: Users can update an uploaded certificate.
>> 2. Get certificate information: Retrieve the basic information of a
>> certificate. i.e expiry date, etc.
>>
>> I have attached the swagger definition for the APIs herewith.
>>
>> Any suggestions, comments are highly appreciated.
>>
>> Thanks and Regards,
>> Menaka
>>
>> --
>>
>> *Menaka Jayawardena*
>> Senior Software Engineer
>> WSO2 Inc.
>>
>> Phone: +94 71 350 5470
>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>> Blog   : https://menakamadushanka.wordpress.com/
>>
>>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>



-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] REST API Support for Dynamic SSL Certificate Installation Feature.

[Menaka Jayawardena]

Hi,

I'm working on implementing a REST API for the Dynamic Certificate
Installation feature for API Manager. (User stories
<https://docs.google.com/document/d/1wZfv3gTL65FT-Jzs9CBYcVoIRFFNvSBuIJg3BiC_7PU/edit?usp=sharing>
)

The current implementation only supports add, retrieve and delete
certificate functions. For the REST API, the following additional functions
will be added.

1. Update a certificate: Users can update an uploaded certificate.
2. Get certificate information: Retrieve the basic information of a
certificate. i.e expiry date, etc.

I have attached the swagger definition for the APIs herewith.

Any suggestions, comments are highly appreciated.

Thanks and Regards,
Menaka

-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/


apim-certificate-mgt-api.yaml
Description: application/yaml
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Sending Custom headers to Websocket back ends.

[Menaka Jayawardena]

Hi Harsha,

We discussed this in the code review as well. But, the issue is, the only
way to pass any additional information in websocket handshake is as
headers. When the request is forwarded to the websocket transport layer,
all these headers are added to the axis2 message context as properties. So
we cannot distinguish the incomming headers with other properties.

As a solution for this, users can send an additional header which contains
the list of headers that should be preserved or we define a prefix which
users should add to the header where we can filter them from the
properties.

A per our initial requirement, adding jwt header, I have followed the
second option because it can be used for other headers as well. So that the
websocket transport implementation can be done in a generic way.

Thanks and Regards,
Menaka



On Fri, Jun 29, 2018 at 9:32 PM Harsha Kumara  wrote:

> On Fri, Jun 29, 2018 at 8:10 PM Menaka Jayawardena 
> wrote:
>
>> Hi Harsha, Chamin,
>>
>> Please find my answers inline.
>>
>> So this means we are having two ways of handling JWT (normal method and
>>> WS specific method) scenarios? If so, we will need additional methods to
>>> cover this flow. Will there be a code/logic duplication due to this?
>>>
>>
>> No. In this implementation, the same JWT token generation method is used.
>> The default ws token validation method is modified to generate the jwt
>> token.
>>
>>
>> https://github.com/wso2/carbon-apimgt/pull/5519/commits/decc193eddecbaccc8eccc22075d2d9876821480
>>
>> In WS APIs, when user send a Header, isn't it going to back-end by
>>> default? Why we need special prefix as we removed it in the outflow?
>>>
>>
>> In Web Socket apis, the headers that we send in the client - gateway
>> handshake are not being sent in the gateway - backend handshake. Only the
>> default headers were set[1] and the incoming headers are set as the
>> properties in axis2 message context. In order to send the header to the
>> backend, we need to get the specific property and attach it as a header to
>> the gateway - backend handshake.
>>
>> As the transport sender implementation should be generic, we send the
>> headers that should be sent to the backend with a prefix and in the
>> WebSocketTransportSender, we get those properties, extract the actual
>> header and set them as handshake headers.[2] So we do not need to alter the
>> transport implementation if we need to send any headers as required.
>>
> Ok. Is there any reason not to send incoming header to the backend? If not
> we ideally should send the headers to the backend. Can't we give a option
> to client to configure the headers that should forward to the backend?
>
>>
>> [1]
>> https://github.com/wso2/carbon-mediation/blob/master/components/carbon-transports/websocket/org.wso2.carbon.websocket.transport/src/main/java/org/wso2/carbon/websocket/transport/WebsocketConnectionFactory.java#L170
>> [2]
>> https://github.com/wso2/carbon-mediation/pull/1068/commits/a3d204dfc53138aab7097d6e168d1c0df7382c01
>>
>> On Fri, Jun 29, 2018 at 7:55 PM, Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Fri, Jun 29, 2018 at 11:25 AM Menaka Jayawardena 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> *With reference to [RRT][APIM] Code Review - Sending Enduser
>>>> information to WS Backends and based on the offline discussion with Kevin.*
>>>>
>>>> *Initial Requirement:* When the JWT token generation is enabled in API
>>>> Manager, the jwt token should be sent to the Web socket backend.
>>>>
>>>> *Current Approach:* As the websocket communication happens as frames,
>>>> we could not add the jwt token into the frames. And also it is not a best
>>>> practice as it is a overhead for the message that is being sent.
>>>> So, the token will be attached as a header to the initial web socket
>>>> handshake.
>>>>
>>>> In the current implementation, we generate the jwt token and  set as an
>>>> intermediate header from the api gateway. This header is then picked up
>>>> from the axis2 message context in the WebSocketTransportSender and attach
>>>> to the Gateway - WS-BackEnd handshake requst.
>>>>
>>>> But, as per this implementation, if the user needs to send another
>>>> header, the WebSocketTransportSender implementation should be changed to
>>>> support the new header. To avoid this, the implementation will be done in a
>>>> generic manner.
>>>>
>

Re: [Architecture] [APIM] Sending Custom headers to Websocket back ends.

[Menaka Jayawardena]

Hi Harsha, Chamin,

Please find my answers inline.

So this means we are having two ways of handling JWT (normal method and WS
> specific method) scenarios? If so, we will need additional methods to cover
> this flow. Will there be a code/logic duplication due to this?
>

No. In this implementation, the same JWT token generation method is used.
The default ws token validation method is modified to generate the jwt
token.

https://github.com/wso2/carbon-apimgt/pull/5519/commits/decc193eddecbaccc8eccc22075d2d9876821480

In WS APIs, when user send a Header, isn't it going to back-end by default?
> Why we need special prefix as we removed it in the outflow?
>

In Web Socket apis, the headers that we send in the client - gateway
handshake are not being sent in the gateway - backend handshake. Only the
default headers were set[1] and the incoming headers are set as the
properties in axis2 message context. In order to send the header to the
backend, we need to get the specific property and attach it as a header to
the gateway - backend handshake.

As the transport sender implementation should be generic, we send the
headers that should be sent to the backend with a prefix and in the
WebSocketTransportSender, we get those properties, extract the actual
header and set them as handshake headers.[2] So we do not need to alter the
transport implementation if we need to send any headers as required.

[1]
https://github.com/wso2/carbon-mediation/blob/master/components/carbon-transports/websocket/org.wso2.carbon.websocket.transport/src/main/java/org/wso2/carbon/websocket/transport/WebsocketConnectionFactory.java#L170
[2]
https://github.com/wso2/carbon-mediation/pull/1068/commits/a3d204dfc53138aab7097d6e168d1c0df7382c01

On Fri, Jun 29, 2018 at 7:55 PM, Harsha Kumara  wrote:

>
>
> On Fri, Jun 29, 2018 at 11:25 AM Menaka Jayawardena 
> wrote:
>
>> Hi,
>>
>>
>> *With reference to [RRT][APIM] Code Review - Sending Enduser information
>> to WS Backends and based on the offline discussion with Kevin.*
>>
>> *Initial Requirement:* When the JWT token generation is enabled in API
>> Manager, the jwt token should be sent to the Web socket backend.
>>
>> *Current Approach:* As the websocket communication happens as frames, we
>> could not add the jwt token into the frames. And also it is not a best
>> practice as it is a overhead for the message that is being sent.
>> So, the token will be attached as a header to the initial web socket
>> handshake.
>>
>> In the current implementation, we generate the jwt token and  set as an
>> intermediate header from the api gateway. This header is then picked up
>> from the axis2 message context in the WebSocketTransportSender and attach
>> to the Gateway - WS-BackEnd handshake requst.
>>
>> But, as per this implementation, if the user needs to send another
>> header, the WebSocketTransportSender implementation should be changed to
>> support the new header. To avoid this, the implementation will be done in a
>> generic manner.
>>
>> *Solution:*
>> The headers that should be sent to the websocket backends, have to be
>> sent with a prefix. The format of would be .
>>
>> Ex: If we need to send the header X-JWT-Assertion to the backend, it
>> should be sent as *websocket.header.**X-JWT-Assertion*.
>>
>> In WebSocketTransportSender, it will get only the properties with the
>> *websocket.header.* prefix, extract the header string and attach them as
>> new headers to the Handshake request.
>>
> In WS APIs, when user send a Header, isn't it going to back-end by
> default? Why we need special prefix as we removed it in the outflow?
>
>>
>> Any comments, suggestions are highly appreciated.
>>
>> Thanks and Regards,
>> Menaka
>>
>> --
>>
>> *Menaka Jayawardena*
>> Senior Software Engineer
>> WSO2 Inc.
>>
>> Phone: +94 71 350 5470
>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>> Blog   : https://menakamadushanka.wordpress.com/
>>
>>
>
> --
> Harsha Kumara
> Associate Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Blog:harshcreationz.blogspot.com
>



-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Sending Custom headers to Websocket back ends.

[Menaka Jayawardena]

Hi,


*With reference to [RRT][APIM] Code Review - Sending Enduser information to
WS Backends and based on the offline discussion with Kevin.*

*Initial Requirement:* When the JWT token generation is enabled in API
Manager, the jwt token should be sent to the Web socket backend.

*Current Approach:* As the websocket communication happens as frames, we
could not add the jwt token into the frames. And also it is not a best
practice as it is a overhead for the message that is being sent.
So, the token will be attached as a header to the initial web socket
handshake.

In the current implementation, we generate the jwt token and  set as an
intermediate header from the api gateway. This header is then picked up
from the axis2 message context in the WebSocketTransportSender and attach
to the Gateway - WS-BackEnd handshake requst.

But, as per this implementation, if the user needs to send another header,
the WebSocketTransportSender implementation should be changed to support
the new header. To avoid this, the implementation will be done in a generic
manner.

*Solution:*
The headers that should be sent to the websocket backends, have to be sent
with a prefix. The format of would be .

Ex: If we need to send the header X-JWT-Assertion to the backend, it should
be sent as *websocket.header.**X-JWT-Assertion*.

In WebSocketTransportSender, it will get only the properties with the
*websocket.header.* prefix, extract the header string and attach them as
new headers to the Handshake request.

Any comments, suggestions are highly appreciated.

Thanks and Regards,
Menaka

-- 

*Menaka Jayawardena*
Senior Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Menaka Jayawardena]

Adding Dimuthu

On Wed, Apr 11, 2018 at 3:21 PM, Menaka Jayawardena <men...@wso2.com> wrote:

> Hi,
>
> In WSO2 Identity Server, users can be provisioned to the internal User
> store when the users are signing up with social accounts. But in this case,
> the users should always use the social login option to login to the
> application and the identity admins could not manage them as internal users.
>
> The main idea of this feature is to provision the users with password so
> that a proper user account will be created in the identity server so that
> they can use the user name and password to login and the identity admins
> can manage the users as internal users.
>
> As per the Flash PC[1], we need to consider following aspects when
> implementing this feature.
>
> *1. Configuring password provisioning in the IDP level.*
> A new option can be provided in the Just-In-Time Provision section to
> enable/ disable provisioing with password.
>
> *2. Prompting a page to get the user claims and password*
> When a user is using social sign up, in the sign up flow, new page will be
> shown with the claims. The claims that are retrieved from the social signup
> response will be automatically populated. Users need to fill any mandatory
> claims that are missing in the request as well as they need to provide a
> valid password.
>
>
> *3. How multiple social accounts can be associated*This applies when we
> support multiple social signup options (Facebook, Google, Twitter etc).
> When a user has already signed up with one social account, after some
> time, he/she again tries to signup using a different account.
> As different social accounts use differnt ids for users, there shoul be a
> mechanism to map the values to the existing user.
>
> As a solution for this we can allow users to add their other social
> account details in the user profile. So, when the user is trying to sign up
> using another account he/she will be logged into the existing account.
>
> *4. What are the user claims that we should retrieve from the social
> account and do we allow users to edit those claims.*
> As we show the claims that are retrieved from the signup request, have to
> decide whether we allow users to modify those details. As per the
> discussion [1] we only allow to edit the exact claims that can be edited in
> the user profile.
>
> I have written the use cases that will be involved in this use case and
> attached herewith.
> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_
> 2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing
>
> Any ideas suggestions are highly appreciated.
>
> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm
> (IST) (Rapid Response Group)
>
> Thanks and Regards,
> Menaka
> --
> *Menaka Jayawardena*
> Software Engineer
> WSO2 Inc.
>
> Phone: +94 71 350 5470
> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
> Blog   : https://menakamadushanka.wordpress.com/
>
>


-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Menaka Jayawardena]

[+ Sagara]

On Wed, Apr 11, 2018 at 3:29 PM, Chandana Napagoda <cnapag...@gmail.com>
wrote:

> Hi Prasanna,
>
> Modifying swagger content means you might have to alter associated Rest
> Service as well. In a Rest Service, there can be user-defined metadata and
> autogenerated metadata. How are you going to identify user added metadata?
>
> Also changing swagger content mean you might move/create the RestService
> in a different registry location(Ex: changing title or version). So you
> need to think about how to handle such use cases and what information need
> to be copied to the new artifact. I believe these pieces of information
> should be there in use case acceptance criteria to avoid future confusion.
>
> Regards,
> Chandana
>
> On 10 April 2018 at 16:04, Prasanna Dangalla <prasa...@wso2.com> wrote:
>
>> Hi Chandana,
>>
>> On Tue, Apr 10, 2018 at 11:55 AM, Chandana Napagoda <cnapag...@gmail.com>
>> wrote:
>>
>>> Hi Menaka,
>>>
>>> When adding a swagger file, it will automatically create a rest service
>>> with metadata available in the swagger file. So when adding a swagger
>>> content through this swagger editor, are we creating rest service metadata
>>> as well?
>>>
>> AFAIU what Menaka is suggesting is to have a backwrod compatability to
>> update the rest service when we edit the swagger from the swagger editor.
>> We need to rethink whether we are editing the same registry artifact or
>> whether we create a new version of the exiting artifact and let the changes
>> reflect on it.
>>
>> Thanks
>> Prasanna
>>
>>>
>>> Regards,
>>> Chandana
>>>
>>>
>>> On 10 April 2018 at 14:28, Menaka Jayawardena <men...@wso2.com> wrote:
>>>
>>>> Hi Shazni,
>>>>
>>>> Thank you very much for the feedback.
>>>>
>>>> On Tue, Apr 10, 2018 at 10:13 AM, Shazni Nazeer <sha...@wso2.com>
>>>> wrote:
>>>>
>>>>> Agreed with Shiro.
>>>>>
>>>>> Regarding #2,  IMO editing a swagger should limit to whatever the
>>>>> version being edited. Say the edited swagger has to be a newer version,
>>>>> then I suppose in G-Reg publisher there's a copy artifact feature, after
>>>>> which the developer can modify the newer version.
>>>>>
>>>>> However regarding #1 I think in publisher there's an option to upload
>>>>> the swagger. When a developer created, it would be beneficial to create a
>>>>> new swagger by start editing if this could be added.
>>>>>
>>>>> On Wed, Apr 4, 2018 at 4:09 AM, Menaka Jayawardena <men...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Yes... The points 1 and 3 are the same.
>>>>>> Sorry for the mistake.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 4, 2018 at 2:22 PM, Shiro Kulatilake <sh...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Menaka,
>>>>>>>
>>>>>>> Comments inline.
>>>>>>>
>>>>>>> On Wed, Apr 4, 2018 at 2:02 PM, Menaka Jayawardena <men...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Currently, in G-Reg publisher, users cannot edit the uploaded
>>>>>>>> swagger files. Neither it can be downloaded. So, in order to edit an
>>>>>>>> uploaded file, they need to either,
>>>>>>>>
>>>>>>> This is when creating REST APIs.
>>>>>>>
>>>>>>>>
>>>>>>>>1.  Edit the local copy, delete the resource in the G-Reg and
>>>>>>>>re-upload it.
>>>>>>>>2.  Copy the content of the file, make the changes, delete the
>>>>>>>>existing G-Reg resource and re-upload it.
>>>>>>>>
>>>>>>>> In user's perspective, this is a very cumbersome process to perform
>>>>>>>> in-order to get a simple task done.
>>>>>>>>
>>>>>>>> As a solution for this, I'm working on integrating the swagger
>>>>>>>> editor in G-Reg publisher, where users can edit the swagger files in 
>>>>>>>&

[Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

[Menaka Jayawardena]

Hi,

In WSO2 Identity Server, users can be provisioned to the internal User
store when the users are signing up with social accounts. But in this case,
the users should always use the social login option to login to the
application and the identity admins could not manage them as internal users.

The main idea of this feature is to provision the users with password so
that a proper user account will be created in the identity server so that
they can use the user name and password to login and the identity admins
can manage the users as internal users.

As per the Flash PC[1], we need to consider following aspects when
implementing this feature.

*1. Configuring password provisioning in the IDP level.*
A new option can be provided in the Just-In-Time Provision section to
enable/ disable provisioing with password.

*2. Prompting a page to get the user claims and password*
When a user is using social sign up, in the sign up flow, new page will be
shown with the claims. The claims that are retrieved from the social signup
response will be automatically populated. Users need to fill any mandatory
claims that are missing in the request as well as they need to provide a
valid password.


*3. How multiple social accounts can be associated*This applies when we
support multiple social signup options (Facebook, Google, Twitter etc).
When a user has already signed up with one social account, after some time,
he/she again tries to signup using a different account.
As different social accounts use differnt ids for users, there shoul be a
mechanism to map the values to the existing user.

As a solution for this we can allow users to add their other social account
details in the user profile. So, when the user is trying to sign up using
another account he/she will be logged into the existing account.

*4. What are the user claims that we should retrieve from the social
account and do we allow users to edit those claims.*
As we show the claims that are retrieved from the signup request, have to
decide whether we allow users to modify those details. As per the
discussion [1] we only allow to edit the exact claims that can be edited in
the user profile.

I have written the use cases that will be involved in this use case and
attached herewith.
https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_2F9Ezk_WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing

Any ideas suggestions are highly appreciated.

[1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm (IST)
(Rapid Response Group)

Thanks and Regards,
Menaka
-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Menaka Jayawardena]

Hi Shazni,

Thank you very much for the feedback.

On Tue, Apr 10, 2018 at 10:13 AM, Shazni Nazeer <sha...@wso2.com> wrote:

> Agreed with Shiro.
>
> Regarding #2,  IMO editing a swagger should limit to whatever the version
> being edited. Say the edited swagger has to be a newer version, then I
> suppose in G-Reg publisher there's a copy artifact feature, after which the
> developer can modify the newer version.
>
> However regarding #1 I think in publisher there's an option to upload the
> swagger. When a developer created, it would be beneficial to create a new
> swagger by start editing if this could be added.
>
> On Wed, Apr 4, 2018 at 4:09 AM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Yes... The points 1 and 3 are the same.
>> Sorry for the mistake.
>>
>>
>>
>> On Wed, Apr 4, 2018 at 2:22 PM, Shiro Kulatilake <sh...@wso2.com> wrote:
>>
>>> Hi Menaka,
>>>
>>> Comments inline.
>>>
>>> On Wed, Apr 4, 2018 at 2:02 PM, Menaka Jayawardena <men...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Currently, in G-Reg publisher, users cannot edit the uploaded swagger
>>>> files. Neither it can be downloaded. So, in order to edit an uploaded file,
>>>> they need to either,
>>>>
>>> This is when creating REST APIs.
>>>
>>>>
>>>>1.  Edit the local copy, delete the resource in the G-Reg and
>>>>re-upload it.
>>>>2.  Copy the content of the file, make the changes, delete the
>>>>existing G-Reg resource and re-upload it.
>>>>
>>>> In user's perspective, this is a very cumbersome process to perform
>>>> in-order to get a simple task done.
>>>>
>>>> As a solution for this, I'm working on integrating the swagger editor
>>>> in G-Reg publisher, where users can edit the swagger files in the G-Reg
>>>> publisher it self.
>>>>
>>>> The functionality would be similar to the swagger editor in API-M
>>>> Publisher and need some clarification on the following aspects as well.
>>>>
>>>> 1. Do we provide the capability of create a swagger file with the
>>>> editor?
>>>> 2. Saving the edited file with a different name.
>>>> 3. Do we need to incorporate the editor in the new file creation
>>>> process. i.e, when the user is creating a new swagger file, do we supposed
>>>> to give them to create it with editor as well?
>>>>
>>>
>>> Whats the difference between 1 and 3 ? Creating a new swagger file will
>>> amount to a new file creation right ?
>>> If we do 2 then we will have to incorporate versioning capabilities here
>>> as well.
>>>
>>> I think in phase 1 we should just do the basic functionality you have
>>> mentioned in the document - just the same that is there in API Manager.
>>>
>>> Thank you,
>>> Shiro
>>>
>>>
>>>>
>>>> I have attached the user stories for the basic functionality.
>>>>
>>>> https://docs.google.com/document/d/1JHmsaWBaUFa_CXBVkDrwL_Bm
>>>> GL1AhD7iw_T3-f6flsI/edit?usp=sharing
>>>>
>>>> Any ideas, suggestions are highly appreciated.
>>>>
>>>> Thanks and Regards,
>>>> Menaka
>>>>
>>>> --
>>>> *Menaka Jayawardena*
>>>> Software Engineer
>>>> WSO2 Inc.
>>>>
>>>> Phone: +94 71 350 5470
>>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>>>> Blog   : https://menakamadushanka.wordpress.com/
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> *Shiroshica Kulatilake | Director, Solutions Architecture,  WSO2 Inc.+94
>>> 776523867 *
>>>
>>
>>
>>
>> --
>> *Menaka Jayawardena*
>> Software Engineer
>> WSO2 Inc.
>>
>> Phone: +94 71 350 5470
>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>> Blog   : https://menakamadushanka.wordpress.com/
>>
>>
>
>
> --
> Shazni Nazeer
>
> Mob : +94 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>
> Blogs :
>
> https://medium.com/@mshazninazeer
> http://shazninazeer.blogspot.com
>
> <http://wso2.com/signature>
>



-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

Hi all,

Based on the internal discussion I had with Darshana, following changes
were done in the implementation.

1. Use a proper JSON schema for data and the result.
2. Removed the sensitive information (ex: password) from data.
3. As the claims are also logged by the audit logger, remove them from the
data.

Here is the new audit log.

Initiator : admin@carbon.super | Action : bulk_user_import | Target :
PRIMARY | Data : {"users":["name1","name2","nam
e74","name3","name3","namsdsa","name2","name","name83","name5","name522"]}
| Result : {"operation":"bulk_user_import","performedBy":"admin","
userStore":"PRIMARY","successCount":0,"duplicateUsers":{"
count":8,"users":["name1","name2","name74","name3","
name3","name","name83","name5"]},"failedUsers":{"count":3,"u
sers":[{"name":"namsdsa","cause":"Invalid claim uri has been provided:
http://wso2.org/claims/ctry"},{"name":"name2","cause":"Invalid claim
uri has been provided: http://wso2.org/claims/emaiaddress
"},{"name":"name522","cause":"Claims and values are not in correct
format"}]}}

Thanks and Regards,
Menaka




On Mon, Mar 19, 2018 at 7:28 PM, Menaka Jayawardena <men...@wso2.com> wrote:

> Hi Denuwanthi,
>
> It's just a template of the audit log that is being used currently.
> For Bulk user import the action would be "*Bulk User Import*".
>
> On Mon, Mar 19, 2018 at 7:02 PM, Denuwanthi De Silva <denuwan...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Mar 19, 2018 at 3:46 PM, Menaka Jayawardena <men...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> As we discussed in the meeting today[1] (19/03/2018), I modified the
>>> summary log as follows.
>>>
>>> {"Bulk User Import Operation Performed by":"admin","User
>>> Store":"PRIMARY","Duplicate Users":{"Duplicate User Count":8,"User
>>> Names":[{"Name":"name1"},{"Name":"name2"},{"Name":"name74"},
>>> {"Name":"name3"},{"Name":"name3"},{"Name":"name"},{"Name":"n
>>> ame83"},{"Name":"name5"}]},"Failed Users":{"Failed User
>>> Count":2,"Failed Users List":[{"Name":"namsdsa","Cause":"Invalid claim
>>> uri has been provided: http://wso2.org/claims/ctry"},
>>> {"Name":"name2","Cause":"Invalid claim uri has been provided:
>>> http://wso2.org/claims/emaiaddress"}]}}
>>>
>>> And also, we discussed to log the bulk user import summary to the audit
>>> logs in the following format.
>>>
>>> Initiator : admin@carbon.super | Action : Add Role | Target : admin |
>>> Data :  {} | Result
>>>
>> Does this audit log gives us the message that a bulk user import happened?
>> Action 'Add Role' does not imply a bulk user import happened IMO.
>> Is it possible to introduce an action which clearly conveys the actual
>> operation that occurred?
>>
>>
>>>
>>> The data section will contain the importing user list. As in the
>>> documentation, we support importing a maximum of 500,000 users at a time.
>>> So, considering the worse case scenario, if we log these users as well, it
>>> will eat up the storage very quickly and cause in threat conditions.
>>>
>>> So IMO, we do not need to log users that are being imported. Also with
>>> the Megala's feature [2], as the information is also being logged, I think
>>> it's enough if we only log the result of the operation with Initiator,
>>> Action and the Target values.
>>>
>>> WDYT?
>>>
>>> [1]  [IAM] [Discussion] Bulk User Import Improvements
>>> [2] Discussion on Improving Audit logs Related with User Management
>>>
>>> Thanks and Regards,
>>> Menaka
>>>
>>> On Tue, Mar 13, 2018 at 12:45 PM, Dimuthu Leelarathne <dimut...@wso2.com
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Tue, Mar 13, 2018 at 11:47 AM, Menaka Jayawardena <men...@wso2.com>
>>>> wrote:
>>>>
>&g

Re: [Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Menaka Jayawardena]

Yes... The points 1 and 3 are the same.
Sorry for the mistake.



On Wed, Apr 4, 2018 at 2:22 PM, Shiro Kulatilake <sh...@wso2.com> wrote:

> Hi Menaka,
>
> Comments inline.
>
> On Wed, Apr 4, 2018 at 2:02 PM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Currently, in G-Reg publisher, users cannot edit the uploaded swagger
>> files. Neither it can be downloaded. So, in order to edit an uploaded file,
>> they need to either,
>>
> This is when creating REST APIs.
>
>>
>>1.  Edit the local copy, delete the resource in the G-Reg and
>>re-upload it.
>>2.  Copy the content of the file, make the changes, delete the
>>existing G-Reg resource and re-upload it.
>>
>> In user's perspective, this is a very cumbersome process to perform
>> in-order to get a simple task done.
>>
>> As a solution for this, I'm working on integrating the swagger editor in
>> G-Reg publisher, where users can edit the swagger files in the G-Reg
>> publisher it self.
>>
>> The functionality would be similar to the swagger editor in API-M
>> Publisher and need some clarification on the following aspects as well.
>>
>> 1. Do we provide the capability of create a swagger file with the editor?
>> 2. Saving the edited file with a different name.
>> 3. Do we need to incorporate the editor in the new file creation process.
>> i.e, when the user is creating a new swagger file, do we supposed to give
>> them to create it with editor as well?
>>
>
> Whats the difference between 1 and 3 ? Creating a new swagger file will
> amount to a new file creation right ?
> If we do 2 then we will have to incorporate versioning capabilities here
> as well.
>
> I think in phase 1 we should just do the basic functionality you have
> mentioned in the document - just the same that is there in API Manager.
>
> Thank you,
> Shiro
>
>
>>
>> I have attached the user stories for the basic functionality.
>>
>> https://docs.google.com/document/d/1JHmsaWBaUFa_CXBVkDrwL_
>> BmGL1AhD7iw_T3-f6flsI/edit?usp=sharing
>>
>> Any ideas, suggestions are highly appreciated.
>>
>> Thanks and Regards,
>> Menaka
>>
>> --
>> *Menaka Jayawardena*
>> Software Engineer
>> WSO2 Inc.
>>
>> Phone: +94 71 350 5470
>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena
>> Blog   : https://menakamadushanka.wordpress.com/
>>
>>
>
>
> --
>
>
> *Shiroshica Kulatilake | Director, Solutions Architecture,  WSO2 Inc.+94
> 776523867 *
>



-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [G-Reg] [RRT] Integrating Swagger Editor with Governance Registry

[Menaka Jayawardena]

Hi,

Currently, in G-Reg publisher, users cannot edit the uploaded swagger
files. Neither it can be downloaded. So, in order to edit an uploaded file,
they need to either,

   1.  Edit the local copy, delete the resource in the G-Reg and re-upload
   it.
   2.  Copy the content of the file, make the changes, delete the existing
   G-Reg resource and re-upload it.

In user's perspective, this is a very cumbersome process to perform
in-order to get a simple task done.

As a solution for this, I'm working on integrating the swagger editor in
G-Reg publisher, where users can edit the swagger files in the G-Reg
publisher it self.

The functionality would be similar to the swagger editor in API-M Publisher
and need some clarification on the following aspects as well.

1. Do we provide the capability of create a swagger file with the editor?
2. Saving the edited file with a different name.
3. Do we need to incorporate the editor in the new file creation process.
i.e, when the user is creating a new swagger file, do we supposed to give
them to create it with editor as well?

I have attached the user stories for the basic functionality.

https://docs.google.com/document/d/1JHmsaWBaUFa_CXBVkDrwL_BmGL1AhD7iw_T3-f6flsI/edit?usp=sharing

Any ideas, suggestions are highly appreciated.

Thanks and Regards,
Menaka

-- 
*Menaka Jayawardena*
Software Engineer
WSO2 Inc.

Phone: +94 71 350 5470
LinkedIn : https://lk.linkedin.com/in/menakajayawardena
Blog   : https://menakamadushanka.wordpress.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

Hi Denuwanthi,

It's just a template of the audit log that is being used currently.
For Bulk user import the action would be "*Bulk User Import*".

On Mon, Mar 19, 2018 at 7:02 PM, Denuwanthi De Silva <denuwan...@wso2.com>
wrote:

>
>
> On Mon, Mar 19, 2018 at 3:46 PM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Hi,
>>
>> As we discussed in the meeting today[1] (19/03/2018), I modified the
>> summary log as follows.
>>
>> {"Bulk User Import Operation Performed by":"admin","User
>> Store":"PRIMARY","Duplicate Users":{"Duplicate User Count":8,"User
>> Names":[{"Name":"name1"},{"Name":"name2"},{"Name":"name74"},
>> {"Name":"name3"},{"Name":"name3"},{"Name":"name"},{"Name":"n
>> ame83"},{"Name":"name5"}]},"Failed Users":{"Failed User Count":2,"Failed
>> Users List":[{"Name":"namsdsa","Cause":"Invalid claim uri has been
>> provided: http://wso2.org/claims/ctry"},{"Name":"name2","Cause":"Invalid
>> claim uri has been provided: http://wso2.org/claims/emaiaddress"}]}}
>>
>> And also, we discussed to log the bulk user import summary to the audit
>> logs in the following format.
>>
>> Initiator : admin@carbon.super | Action : Add Role | Target : admin |
>> Data :  {} | Result
>>
> Does this audit log gives us the message that a bulk user import happened?
> Action 'Add Role' does not imply a bulk user import happened IMO.
> Is it possible to introduce an action which clearly conveys the actual
> operation that occurred?
>
>
>>
>> The data section will contain the importing user list. As in the
>> documentation, we support importing a maximum of 500,000 users at a time.
>> So, considering the worse case scenario, if we log these users as well, it
>> will eat up the storage very quickly and cause in threat conditions.
>>
>> So IMO, we do not need to log users that are being imported. Also with
>> the Megala's feature [2], as the information is also being logged, I think
>> it's enough if we only log the result of the operation with Initiator,
>> Action and the Target values.
>>
>> WDYT?
>>
>> [1]  [IAM] [Discussion] Bulk User Import Improvements
>> [2] Discussion on Improving Audit logs Related with User Management
>>
>> Thanks and Regards,
>> Menaka
>>
>> On Tue, Mar 13, 2018 at 12:45 PM, Dimuthu Leelarathne <dimut...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 11:47 AM, Menaka Jayawardena <men...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> @Denuwanthi: Yes. It can be done. Please find the summery below.
>>>>
>>>> SUMMERY :
>>>> Bulk User Import Operation Performed by: admin
>>>> User Store  : PRIMARY
>>>> Duplicate user count : 8
>>>> .
>>>>
>>>>
>>>> *UI Message Modification.*
>>>>
>>>> Currently, if an error occurred in the process of performing the Bulk
>>>> User Import Operation, the following Error message will be shown.
>>>>
>>>> *Error occurs while importing usernames. All usernames were not
>>>> imported. Last error was : Invalid claim uri has been provided:
>>>> http://wso2.org/claims/emaiaddress <http://wso2.org/claims/emaiaddress>*
>>>>
>>>> But there are multiple errors (Duplicate user etc). In this case, I
>>>> think it's better if we show a more generic error with a brief summery and
>>>> direct them to view the log file for more information.
>>>>
>>>> For an example:
>>>> Bulk User Import Completed with Errors.
>>>> Success user count: x  Duplicate user count: y  Failed user count: z
>>>> Please check the user import log for more detailed information.
>>>>
>>>
>>> +1
>>>
>>> And in the detail log we can log errors and duplicates.
>>>
>>> thanks,
>>> Dimuthu
>>>
>>>
>>>
>>>>
>>>> Any ideas, suggestions are highly appreciated.
>>>>
>>>> Thanks and Regards,
>>>> Menaka
>>>>
>>>> On Tue, Mar 13, 2018 at 9:24 AM, Denuwanthi De Silva <
>>>> 

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

Hi,

As we discussed in the meeting today[1] (19/03/2018), I modified the
summary log as follows.

{"Bulk User Import Operation Performed by":"admin","User
Store":"PRIMARY","Duplicate Users":{"Duplicate User Count":8,"User
Names":[{"Name":"name1"},{"Name":"name2"},{"Name":"name74"},
{"Name":"name3"},{"Name":"name3"},{"Name":"name"},{"
Name":"name83"},{"Name":"name5"}]},"Failed Users":{"Failed User
Count":2,"Failed Users List":[{"Name":"namsdsa","Cause":"Invalid claim uri
has been provided: http://wso2.org/claims/ctry"},
{"Name":"name2","Cause":"Invalid claim uri has been provided:
http://wso2.org/claims/emaiaddress"}]}}

And also, we discussed to log the bulk user import summary to the audit
logs in the following format.

Initiator : admin@carbon.super | Action : Add Role | Target : admin | Data
:  {} | Result

The data section will contain the importing user list. As in the
documentation, we support importing a maximum of 500,000 users at a time.
So, considering the worse case scenario, if we log these users as well, it
will eat up the storage very quickly and cause in threat conditions.

So IMO, we do not need to log users that are being imported. Also with the
Megala's feature [2], as the information is also being logged, I think it's
enough if we only log the result of the operation with Initiator, Action
and the Target values.

WDYT?

[1]  [IAM] [Discussion] Bulk User Import Improvements
[2] Discussion on Improving Audit logs Related with User Management

Thanks and Regards,
Menaka

On Tue, Mar 13, 2018 at 12:45 PM, Dimuthu Leelarathne <dimut...@wso2.com>
wrote:

>
>
> On Tue, Mar 13, 2018 at 11:47 AM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Hi,
>>
>> @Denuwanthi: Yes. It can be done. Please find the summery below.
>>
>> SUMMERY :
>> Bulk User Import Operation Performed by: admin
>> User Store  : PRIMARY
>> Duplicate user count : 8
>> .
>>
>>
>> *UI Message Modification.*
>>
>> Currently, if an error occurred in the process of performing the Bulk
>> User Import Operation, the following Error message will be shown.
>>
>> *Error occurs while importing usernames. All usernames were not imported.
>> Last error was : Invalid claim uri has been provided:
>> http://wso2.org/claims/emaiaddress <http://wso2.org/claims/emaiaddress>*
>>
>> But there are multiple errors (Duplicate user etc). In this case, I think
>> it's better if we show a more generic error with a brief summery and direct
>> them to view the log file for more information.
>>
>> For an example:
>> Bulk User Import Completed with Errors.
>> Success user count: x  Duplicate user count: y  Failed user count: z
>> Please check the user import log for more detailed information.
>>
>
> +1
>
> And in the detail log we can log errors and duplicates.
>
> thanks,
> Dimuthu
>
>
>
>>
>> Any ideas, suggestions are highly appreciated.
>>
>> Thanks and Regards,
>> Menaka
>>
>> On Tue, Mar 13, 2018 at 9:24 AM, Denuwanthi De Silva <denuwan...@wso2.com
>> > wrote:
>>
>>>
>>>
>>> On Mon, Mar 12, 2018 at 4:29 PM, Menaka Jayawardena <men...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Here is an experimental user import summery.
>>>>
>>>> SUMMERY :
>>>> Bulk User Import Operation Performed by: admin
>>>> Duplicate user count: 8
>>>> Duplicate Users :
>>>> name1, name2, name74, name3, name3, name, name83, name5,
>>>>
>>>> Failed User Count: 2Failed Users:
>>>> Name : namsdsa
>>>> Cause : Invalid claim uri has been provided:
>>>> http://wso2.org/claims/ctry
>>>> Name : name2
>>>> Cause : Invalid claim uri has been provided:
>>>> http://wso2.org/claims/emaiaddress
>>>>
>>>
>>> Hi Menaka,
>>>
>>> Is it possible to print the user domain in the summary as well? Then the
>>> information of the  userstore the users were imported will be available as
>>> well.
>>>
>>> Thanks,
>>>
>>>>
>>>>
>>>> The cause string is the standard error which comes from the exception.
>>>

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

Hi,

@Denuwanthi: Yes. It can be done. Please find the summery below.

SUMMERY :
Bulk User Import Operation Performed by: admin
User Store  : PRIMARY
Duplicate user count : 8
.


*UI Message Modification.*

Currently, if an error occurred in the process of performing the Bulk User
Import Operation, the following Error message will be shown.

*Error occurs while importing usernames. All usernames were not imported.
Last error was : Invalid claim uri has been provided:
http://wso2.org/claims/emaiaddress <http://wso2.org/claims/emaiaddress>*

But there are multiple errors (Duplicate user etc). In this case, I think
it's better if we show a more generic error with a brief summery and direct
them to view the log file for more information.

For an example:
Bulk User Import Completed with Errors.
Success user count: x  Duplicate user count: y  Failed user count: z
Please check the user import log for more detailed information.

Any ideas, suggestions are highly appreciated.

Thanks and Regards,
Menaka

On Tue, Mar 13, 2018 at 9:24 AM, Denuwanthi De Silva <denuwan...@wso2.com>
wrote:

>
>
> On Mon, Mar 12, 2018 at 4:29 PM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Here is an experimental user import summery.
>>
>> SUMMERY :
>> Bulk User Import Operation Performed by: admin
>> Duplicate user count: 8
>> Duplicate Users :
>> name1, name2, name74, name3, name3, name, name83, name5,
>>
>> Failed User Count: 2Failed Users:
>> Name : namsdsa
>> Cause : Invalid claim uri has been provided:
>> http://wso2.org/claims/ctry
>> Name : name2
>> Cause : Invalid claim uri has been provided:
>> http://wso2.org/claims/emaiaddress
>>
>
> Hi Menaka,
>
> Is it possible to print the user domain in the summary as well? Then the
> information of the  userstore the users were imported will be available as
> well.
>
> Thanks,
>
>>
>>
>> The cause string is the standard error which comes from the exception. Do
>> we need to print the stack trace here?
>>
>> Also, there are two BulkUserImport classes (CSVUserBulkImport[1] and
>> ExcelUserBulkImport[2]) and also an unused interface [3] (The classes [1]
>> and [2] are concreet classes).
>>
>> @IAM Team: Is there any particular reason why it kept like this?
>>
>> IMO in this implementation, we could use it to avoid code and method
>> duplication. (By making it an Abstract class)
>>
>> [1] https://github.com/wso2/carbon-identity-framework/blob/maste
>> r/components/user-mgt/org.wso2.carbon.user.mgt/src/main/
>> java/org/wso2/carbon/user/mgt/bulkimport/CSVUserBulkImport.java
>> [2] https://github.com/wso2/carbon-identity-framework/blob/maste
>> r/components/user-mgt/org.wso2.carbon.user.mgt/src/main/
>> java/org/wso2/carbon/user/mgt/bulkimport/ExcelUserBulkImport.java
>> [3] https://github.com/wso2/carbon-identity-framework/blob/maste
>> r/components/user-mgt/org.wso2.carbon.user.mgt/src/main/
>> java/org/wso2/carbon/user/mgt/bulkimport/UserBulkImport.java
>>
>> Thanks and Regards,
>> Menaka
>>
>>
>> On Mon, Mar 12, 2018 at 2:14 PM, Menaka Jayawardena <men...@wso2.com>
>> wrote:
>>
>>> [- strategy +Architecture]
>>>
>>>
>>> On Mon, Mar 12, 2018 at 12:21 PM, Menaka Jayawardena <men...@wso2.com>
>>> wrote:
>>>
>>>> Hi Dimuthu,
>>>>
>>>> Are you going to add this log appender by default to the configuration?
>>>>>
>>>> We can add the log appender by default and keep it commented. So when
>>>> the user enables the Bulk User import, he also can enable the log appender
>>>> as well.
>>>>
>>>>
>>>> On Mon, Mar 12, 2018 at 12:07 PM, Dimuthu Leelarathne <
>>>> dimut...@wso2.com> wrote:
>>>>
>>>>> Hi Menaka,
>>>>>
>>>>> Are you going to add this log appender by default to the configuration?
>>>>>
>>>>> thanks,
>>>>> Dimuthu
>>>>>
>>>>> On Mon, Mar 12, 2018 at 11:48 AM, Dakshika Jayathilaka <
>>>>> daksh...@wso2.com> wrote:
>>>>>
>>>>>> Hi Ruwan,
>>>>>>
>>>>>> Do we need to log each success? IMO admin will more interest on
>>>>>> failures or duplicates. IMHO we can add detail log on failures and
>>>>>> duplicates and then log the summary which includes the success count.
>>>>>>
>>>

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

Hi,

Here is an experimental user import summery.

SUMMERY :
Bulk User Import Operation Performed by: admin
Duplicate user count: 8
Duplicate Users :
name1, name2, name74, name3, name3, name, name83, name5,

Failed User Count: 2Failed Users:
Name : namsdsa
Cause : Invalid claim uri has been provided:
http://wso2.org/claims/ctry
Name : name2
Cause : Invalid claim uri has been provided:
http://wso2.org/claims/emaiaddress

The cause string is the standard error which comes from the exception. Do
we need to print the stack trace here?

Also, there are two BulkUserImport classes (CSVUserBulkImport[1] and
ExcelUserBulkImport[2]) and also an unused interface [3] (The classes [1]
and [2] are concreet classes).

@IAM Team: Is there any particular reason why it kept like this?

IMO in this implementation, we could use it to avoid code and method
duplication. (By making it an Abstract class)

[1]
https://github.com/wso2/carbon-identity-framework/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/bulkimport/CSVUserBulkImport.java
[2]
https://github.com/wso2/carbon-identity-framework/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/bulkimport/ExcelUserBulkImport.java
[3]
https://github.com/wso2/carbon-identity-framework/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/bulkimport/UserBulkImport.java

Thanks and Regards,
Menaka


On Mon, Mar 12, 2018 at 2:14 PM, Menaka Jayawardena <men...@wso2.com> wrote:

> [- strategy +Architecture]
>
>
> On Mon, Mar 12, 2018 at 12:21 PM, Menaka Jayawardena <men...@wso2.com>
> wrote:
>
>> Hi Dimuthu,
>>
>> Are you going to add this log appender by default to the configuration?
>>>
>> We can add the log appender by default and keep it commented. So when the
>> user enables the Bulk User import, he also can enable the log appender as
>> well.
>>
>>
>> On Mon, Mar 12, 2018 at 12:07 PM, Dimuthu Leelarathne <dimut...@wso2.com>
>> wrote:
>>
>>> Hi Menaka,
>>>
>>> Are you going to add this log appender by default to the configuration?
>>>
>>> thanks,
>>> Dimuthu
>>>
>>> On Mon, Mar 12, 2018 at 11:48 AM, Dakshika Jayathilaka <
>>> daksh...@wso2.com> wrote:
>>>
>>>> Hi Ruwan,
>>>>
>>>> Do we need to log each success? IMO admin will more interest on
>>>> failures or duplicates. IMHO we can add detail log on failures and
>>>> duplicates and then log the summary which includes the success count.
>>>>
>>>> WDYT?
>>>>
>>>> Regards,
>>>>
>>>> *Dakshika Jayathilaka*
>>>> PMC Member & Committer of Apache Stratos
>>>> Associate Technical Lead
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>> 0771100911 <077%20110%200911>
>>>>
>>>> On Mon, Mar 12, 2018 at 11:35 AM, Ruwan Abeykoon <ruw...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Menaka,
>>>>> This is nice feature.
>>>>> I would suggest adding one line per each user, before adding, and one
>>>>> line for each success, failure(with reason).
>>>>> Also add a line who performs this operation. Any trackable information
>>>>> of the request for audit purposes.
>>>>>
>>>>> Cheers,
>>>>> Ruwan
>>>>>
>>>>>
>>>>> On Mon, Mar 12, 2018 at 11:21 AM, Menaka Jayawardena <men...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Currently, when performing bulk user import operation in Identity
>>>>>> Server, users face following issues.
>>>>>>
>>>>>> 1. To check import failed users, need to filter the carbon log file.
>>>>>> 2. In UI, it shows only the last error that occurred when importing
>>>>>> users.
>>>>>>
>>>>>> *Requirement Description.*
>>>>>> There should be a user friendly way to view the import failed users.
>>>>>>
>>>>>> As a solution for this, we will provide a new log appender which will
>>>>>> log the messages to a separate log file specific for bulk user import. 
>>>>>> This
>>>>>> will help users to easily view the status of the imported users and all 
>>>>>> the

Re: [Architecture] [IAM] Bulk User Import Improvements

[Menaka Jayawardena]

[- strategy +Architecture]


On Mon, Mar 12, 2018 at 12:21 PM, Menaka Jayawardena <men...@wso2.com>
wrote:

> Hi Dimuthu,
>
> Are you going to add this log appender by default to the configuration?
>>
> We can add the log appender by default and keep it commented. So when the
> user enables the Bulk User import, he also can enable the log appender as
> well.
>
>
> On Mon, Mar 12, 2018 at 12:07 PM, Dimuthu Leelarathne <dimut...@wso2.com>
> wrote:
>
>> Hi Menaka,
>>
>> Are you going to add this log appender by default to the configuration?
>>
>> thanks,
>> Dimuthu
>>
>> On Mon, Mar 12, 2018 at 11:48 AM, Dakshika Jayathilaka <daksh...@wso2.com
>> > wrote:
>>
>>> Hi Ruwan,
>>>
>>> Do we need to log each success? IMO admin will more interest on failures
>>> or duplicates. IMHO we can add detail log on failures and duplicates and
>>> then log the summary which includes the success count.
>>>
>>> WDYT?
>>>
>>> Regards,
>>>
>>> *Dakshika Jayathilaka*
>>> PMC Member & Committer of Apache Stratos
>>> Associate Technical Lead
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>> 0771100911 <077%20110%200911>
>>>
>>> On Mon, Mar 12, 2018 at 11:35 AM, Ruwan Abeykoon <ruw...@wso2.com>
>>> wrote:
>>>
>>>> Hi Menaka,
>>>> This is nice feature.
>>>> I would suggest adding one line per each user, before adding, and one
>>>> line for each success, failure(with reason).
>>>> Also add a line who performs this operation. Any trackable information
>>>> of the request for audit purposes.
>>>>
>>>> Cheers,
>>>> Ruwan
>>>>
>>>>
>>>> On Mon, Mar 12, 2018 at 11:21 AM, Menaka Jayawardena <men...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Currently, when performing bulk user import operation in Identity
>>>>> Server, users face following issues.
>>>>>
>>>>> 1. To check import failed users, need to filter the carbon log file.
>>>>> 2. In UI, it shows only the last error that occurred when importing
>>>>> users.
>>>>>
>>>>> *Requirement Description.*
>>>>> There should be a user friendly way to view the import failed users.
>>>>>
>>>>> As a solution for this, we will provide a new log appender which will
>>>>> log the messages to a separate log file specific for bulk user import. 
>>>>> This
>>>>> will help users to easily view the status of the imported users and all 
>>>>> the
>>>>> error logs.
>>>>>
>>>>> Also currently, as the operation summery,  we only have
>>>>>
>>>>> "Success count: " + successCount + ", Fail count: " + failCount + ",
>>>>> Duplicate count: " + duplicateCount
>>>>>
>>>>> Instead, it would be much effective if we could list the failed and
>>>>> duplicate user names as well.
>>>>>
>>>>> "Success count: " + successCount + ", Fail count: " + failCount + ",
>>>>> Duplicate count: " + duplicateCount
>>>>> "Failed Users : " + [Failed Users List] + "Duplicate Users : " +
>>>>> [Duplicate Users List]
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks and Regards,
>>>>> Menaka
>>>>>
>>>>>
>>>>> --
>>>>> *Menaka Jayawardena*
>>>>> *Software Engineer - WSO2 Inc*
>>>>> *Tel : 071 350 5470 <071%20350%205470>*
>>>>> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
>>>>> <https://lk.linkedin.com/in/menakajayawardena>*
>>>>> *Blog: https://menakamadushanka.wordpress.com/
>>>>> <https://menakamadushanka.wordpress.com/>*
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Ruwan Abeykoon*
>>>> *Associate Director/Architect**,*
>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>>> *lean.enterprise.middleware.*
>>>>
>>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Director, Rapid Response Team
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile: +94773661935 <+94%2077%20366%201935>
>> Blog: http://muthulee.blogspot.com
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> *Menaka Jayawardena*
> *Software Engineer - WSO2 Inc*
> *Tel : 071 350 5470*
> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
> <https://lk.linkedin.com/in/menakajayawardena>*
> *Blog: https://menakamadushanka.wordpress.com/
> <https://menakamadushanka.wordpress.com/>*
>
>


-- 
*Menaka Jayawardena*
*Software Engineer - WSO2 Inc*
*Tel : 071 350 5470*
*LinkedIn: https://lk.linkedin.com/in/menakajayawardena
<https://lk.linkedin.com/in/menakajayawardena>*
*Blog: https://menakamadushanka.wordpress.com/
<https://menakamadushanka.wordpress.com/>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Using REST APIs with Carbon console.

[Menaka Jayawardena]

Hi all,

I'm working on implementing the Retryable Outbound Provisioning for
Identity Server. I have completed the backend implementation and now
working on developing the UI.

As per our initial discussion, the new UI was planned to be added to the IS
carbon console. But when looking into this, I faced the following blocker.

The backend services of the feature are exposed as REST APIs which need
authorization header to be set.
Authorization : Bearer Base64Encoded(username:password)

But in carbon ui, we do not use rest APIs and we also could not authorize
the rest request. So without developing a SOAP service, we could not use
the existing rest API from the carbon ui.

I also looked at the IS dashboard. But there also, we have used only SOAP
APIs.

Is there a method to use this without writing a WSDL for current identity
server version?

Thanks and Regards,
Menaka

-- 
*Menaka Jayawardena*
*Software Engineer - WSO2 Inc*
*Tel : 071 350 5470*
*LinkedIn: https://lk.linkedin.com/in/menakajayawardena
<https://lk.linkedin.com/in/menakajayawardena>*
*Blog: https://menakamadushanka.wordpress.com/
<https://menakamadushanka.wordpress.com/>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] UX design for Retryable Outbound Provisioning Feature.

[Menaka Jayawardena]

Hi Imesh,

Thank you very much for the suggestions. Please find my comments inline.

Hi Menaka,
>>>
>>> Please find the bellow suggestions.
>>>
>>> IMHO, the filtration controls should resemble a visual connection to the
>>> listing.
>>>
>>  I have followed the default UX design in Management Console for this
otherwise it would break the consistancy.

>
>>> Retry and delete actions should get a more prominence since they are the
>>> primary actions of this page
>>>
>> +1 for this.

If we could filter the data on the selection of each filtration criteria,
>>> IMO it's better to remove the "filter" button. For and example if we could
>>> update the listing according to the selected criteria, the action is not
>>> needed.
>>>
>>  Yes. This could be done.

When Deleting / Retrying without selecting a record, IMO it's better to
>>> disable the buttons until the user select at-least one record. WDYT?
>>>
>>  +1.

> --
>>> *Thanks and Best Regards,*
>>> Imesh Ashandimal Chandrasiri
>>> *Software Engineer*
>>> WSO2, Inc.
>>> lean . enterprise . middleware
>>> *E:* ime...@wso2.com | *P:* 0716519187 <071%20651%209187>
>>>
>>> --
> *Menaka Jayawardena*
> *Software Engineer - WSO2 Inc*
> *Tel : 071 350 5470*
> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
> <https://lk.linkedin.com/in/menakajayawardena>*
> *Blog: https://menakamadushanka.wordpress.com/
> <https://menakamadushanka.wordpress.com/>*
>
>


-- 
*Menaka Jayawardena*
*Software Engineer - WSO2 Inc*
*Tel : 071 350 5470*
*LinkedIn: https://lk.linkedin.com/in/menakajayawardena
<https://lk.linkedin.com/in/menakajayawardena>*
*Blog: https://menakamadushanka.wordpress.com/
<https://menakamadushanka.wordpress.com/>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Sharing common SPA components within and between product(s)

[Menaka Jayawardena]

;>> res/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store
>>> [3]: https://github.com/wso2/carbon-apimgt/tree/master/featu
>>> res/apimgt/org.wso2.carbon.apimgt.admin.feature/src/main/resources/admin
>>> [4]: https://github.com/wso2/carbon-apimgt/blob/master/featu
>>> res/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main
>>> /resources/publisher/source/src/app/data/User.js
>>> [5]: https://www.npmjs.com/package/@wso2-dashboards/widget
>>>
>>> --
>>> *Kasun Thennakoon*
>>> Software Engineer
>>> WSO2, Inc.
>>> Mobile:+94 711661919
>>>
>>
>>
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>
>
>
> --
> *Kasun Thennakoon*
> Software Engineer
> WSO2, Inc.
> Mobile:+94 711661919
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Menaka Jayawardena*
*Software Engineer - WSO2 Inc*
*Tel : 071 350 5470*
*LinkedIn: https://lk.linkedin.com/in/menakajayawardena
<https://lk.linkedin.com/in/menakajayawardena>*
*Blog: https://menakamadushanka.wordpress.com/
<https://menakamadushanka.wordpress.com/>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Option for the customer to change the app context path in React based web apps

[Menaka Jayawardena]

+1 for the approach.

On Sat, Oct 14, 2017 at 8:57 AM Chanaka Jayasena  wrote:

> +1. This will be very helpful to solve the run-time theming feature with
> APIM. Also we can use the client side context path to populate the basePath
> for react routing. Not sure this is possible yet.
>
> We have a msf4j service to read the deployment.yaml and get the available
> multiple enviorments ( qa, prod etc ..). We can use the mentioned feature
> to get these configs and remove this service.
>
>
> thanks,
> Chanaka
>
> On Fri, Oct 13, 2017 at 4:37 PM, Thusitha Kalugamage 
> wrote:
>
>> +1 for the initiative,
>> Hoping this will be the solution for resolving customized styling when a
>> customer wants their styling introduced as a .css file [1].
>> Also this will ensure platform-wide structuring consistency for SPAs.
>>
>> [1] https://stackoverflow.com/questions/28386125/dynamically
>> -load-a-stylesheet-with-react
>>
>> Regards,
>>
>> On Thu, Oct 12, 2017 at 10:34 PM, SajithAR Ariyarathna > > wrote:
>>
>>> Hi All,
>>>
>>> *What is app context path?*
>>>
>>> In http://localhost:8080/store/apis/1234 URL, the app context path is
>>> /store. Customer might want to deploy the Store app in /my-store
>>> context path (in that case the URL will be http://localhost:8080/my-st
>>> ore/apis/1234).
>>>
>>>
>>> Currently in React based web apps, the app context path is hard-coded in
>>> the index.html file (see [1], [2]). This makes harder to change the app
>>> context path for a deployment. One approach that has been suggested to
>>> avoid hard-cording the app context path in the index.html is to use
>>> relative URLs for stylesheets and scripts. However the browser resolves
>>> these relative URLs into absolute URLs by prepending the current page
>>> URL. Therefore we cannot use relative URLs for stylesheets and scripts.
>>>
>>> e.g. If the current page is http://localhost:8080/store/
>>> then the absolute URL will be  http://localhost:8080/stor
>>> e/public/themes/default/css/styles.css. If the current page is
>>> http://localhost:8080/store/apis/12345 then the absolute URL will be
>>> http://localhost:8080/store/apis/12345/public/themes/
>>> default/css/styles.css which is incorrect.
>>>
>>>
>>> In order to resolve this, we need to generate proper URLs (with the
>>> context path). However its difficult to find and fix relative URLs inside
>>> the index.html. (Carbon UI Server has to parse the index.html file, then
>>> find necessary tags like ,  and prepend the app context
>>> path to their relative URLs and generate the final HTML. This process is
>>> cumbersome & will affect negatively on performance.) We can have a template
>>> file instead of a HTML file. Handlebars is a good candidate for this task
>>> as we have much experience with Handlebars template in web apps. So if we
>>> choose Handlebars then index.html will be index.hbs. e.g.
>>>
>>> 
>>> 
>>> ...
>>> >> href="{{contextPath}}/public/themes/default/css/styles.css"/>
>>> 
>>> 
>>> ...
>>> 
>>> 
>>>
>>> This approach opens-up other useful features. For example, if someone
>>> needs the app context path in the client-side JS, they can send it as a
>>> variable to the client-side. e.g.
>>>
>>> 
>>> ...
>>>