Re: [Dev] Problems in the web console after upgrade WSO2EI 6.3.0 to 6.4.0

2018-10-17 Thread Cyril Rognon 
Hi Bernard,

since the databases are the exect same between 6.3.0 and 6.4.0 I believe
your issue is related to userstore and registry mounting configuration as
stadted in point 5 of the documentaiton of this migration :
https://docs.wso2.com/display/EI640/Upgrading+from+WSO2+EI+6.3.0#UpgradingfromWSO2EI6.3.0-MigratingconfigurationsoftheESBprofile


5 : Check for any other configurations that were done for WSO2 EI 6.3.0
based on your solution and update the configurations in WSO2 EI 6.4.0
accordingly. For example, configurations related to external user stores,
caching, mounting, transports, etc

I reckon you might already have checked this one. But since roles and
permissions are the issue here.. I only see the userstore and reg mounting.

Thanks
Cyril

Le mer. 17 oct. 2018 à 15:41, Bernard Paris  a
écrit :

> Hi,
>
> after upgrading from WSO2EI 6.3.0 to 6.4.0 re-using all same databases,
> starting the server 6.4.0 is ok,  the only error in the logs at startup is
> DefaultCryptoProviderComponent} -  'CryptoService.Secret' property has not
> been set. ...
>
> Calling services (APIs)  from remote clients works ok.  I have troubles
> when I go into the carbon web console :
>
> I can list all the users, but when I try to view their roles
>
> *Error while loading roles of archibus. Error: Error occurred while
> getting hybrid roles from filter : %*
> or
> Error while loading roles. Error: Error occurred while getting hybrid
> roles from filter : %
>
>
> When I try to list roles
>
> *Error while listing roles. Error: Cannot change transaction isolation
> level in the middle of a transac*tion.
>
>
> By the way,  I can browse the registry governance  tree but when I try to
> display the content an  element, let's say an endpoint ;
>
> *Unable to determine resource permissions.*
>
>
> I have same issue on two separated wso2ei-6.4.0 instances  which are only
> sharing commonly the users DB, all others DBs are completely separated.
> From one of the 2 servers the user DB is readonly.
>
> What are to do to recover whole web console features ?
>
> Thanks for your help,
> Bernard
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] WSO2 Identity Server 5.4.1 Update2 Released !!!

2018-02-15 Thread Cyril Rognon 
Hi team

Thank you for the good job !

Any idea about the release date of apim 2.2.0 to pair with is 5.4.x ?

Thanks
Cyril


Le 15 févr. 2018 10:27 PM, "Dinali Dabarera"  a écrit :

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.4.1 Update2.
You can build the distribution from the source tag,

Runtime: https://github.com/ws 
o2/product-is/releases/tag/v5. 4.1-update2


follow the steps given below.

*Building from the source*

   1. Install Java8 or above
   2. Install Apache Maven 3.x.x(https://maven.apache.org/download.cgi#)
   3. Get the source,
  - For the Runtime: Get a clone from https://github.com/wso2/p
  roduct-is.git and checkout to v5.4.1-update2 tag or you can directly
  download the source for the tag from https://github.com/wso2/p
  
  roduct-is/releases/tag/v5.4.1-
  
  update2
  
   4. Run the one of the below maven commands from product-is directory,
  - *mvn** clean install* (To build the binary and source distributions
  with the tests)
  - *mvn** clean install -Dmaven.test.skip=true* (To build the binary
  and source distributions, without running any of the
unit/integration tests)
   5. You can find the wso2is-5.4.1-update2.zip binary distribution in
   product-is/modules/distribution/target directory.

What's new in WSO2 Identity Server 5.4.1 Update2

New Features & Bug Fixes: A list of new features and bug fixes shipped with
this release can be found here
.
Download

You can download WSO2 Identity Server 5.4.1 Update2 here

.
Contribute to WSO2 Identity ServerMailing Lists

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   -

   Developer List: dev@wso2.org
   -

   Architecture List: architect...@wso2.org
   -

   User Forum: StackOverflow
   

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues .


~ The WSO2 Identity and Access Management Team ~


-- 
*Dinali Rosemin Dabarera*
Software Engineer
WSO2 Lanka (pvt) Ltd.
Web: http://wso2.com/
Email : gdrdabar...@gmail.com
LinkedIn 
Mobile: +94770198933 <+94%2077%20019%208933>



















___
Architecture mailing list
architect...@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API-Proxy for Single Page Application

2017-12-13 Thread Cyril Rognon 
Hi all,

Indeed as Thilinda is saying it is completely distinct from APIM gateway
and it covers login/logout as well as api call.

It could be integrated into Identity Server : when you declare some SP then
it could parameter and deploy the server-side proxy

deploy site(s) and HA will have to be dealt with.

Since you mention login over Oauth I assulme you are considering
OpenIDConnect usage (from the proxy)?

Thanks
Cyril

2017-12-13 8:50 GMT+01:00 Thilina Madumal :

> Hi Youcef,
>
> This is not a replacement for APIM Gateway. APIM Gateway and this are two
> different things.
> This is an implementation of the security pattern no. 17 described in blog
> 1.
>
> [1] https://medium.facilelogin.com/thirty-solution-patterns-with-the-
> wso2-identity-server-16f9fd0c0389
>
> Regards,
> Thilina.
>
> On Tue, Dec 12, 2017 at 12:48 AM, Youcef HILEM 
> wrote:
>
>> Hi Thilina,
>>
>> Could you please explain why APIM Gateway is not suitable?
>> How to integrate this feature in WSO2 APIM?
>> In our distributed architecture, we already have enough components and
>> adding another seems inappropriate.
>>
>> Thanks
>> Youcef HILEM
>>
>>
>>
>> --
>> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development
>> -f3.html
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
>
> --
> *Thilina Madumal*
> *Software Engineer | **WSO2*
> Email: thilina...@wso2.com
> Mobile: *+ <+94%2077%20767%201807>94 774553167*
> Web:  http://wso2.com
>
> 
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API-Proxy for Single Page Application

2017-11-17 Thread Cyril Rognon 
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and
publisher SPAs and it seems that it is using password grant_type and using
"server-side" endpoints provided by apim server /login/token/publisher or
/login/token/store.
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena :

> Can you please explain more about this API-proxy ? is it only for decrypt
> the token?
>
> APIM 3.0.X has SPA's for it's publisher and store apps, have a look at
> security implementation of it. AFAIK, there is a no API proxy in that
> implementation.
>
> On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal 
> wrote:
>
>> Hi Devs,
>>
>> The idea of an API-Proxy for Single Page Applications is quite helpful in
>> mitigating inherent security risks of keeping the access_token in the
>> browser side as plain text.
>>
>> Here the idea is to keep the access_token encrypted and set in a cookie.
>> API-Proxy will mediate all the calls for the third-party APIs by decrypting
>> the access_token value and calling the requested third-party APIs with the
>> decrypted access_token.
>>
>> This is a significantly valuable use-case for the SPAs where there is no
>> attached server-side other than the container which is used to facilitate
>> the initial page download.
>>
>> I'm in the requirement gathering phase. Would appreciate your suggestions
>> on,
>>
>>- what are the nice to have capabilities in API-Proxy
>>- what are the complexities that will arise while implementing this
>>- how to achieve the third-party API call mediation
>>- Is this a valid use-case
>>- or is this a redundant effort
>>- are there any alternatives
>>- and etc.
>>
>> This is an open invitation to shoot whatever pops into your mind in this
>> regards:)
>>
>> Thanks in advance.
>>
>> Cheers,
>> Thilina
>> --
>> *Thilina Madumal*
>> *Software Engineer | **WSO2*
>> Email: thilina...@wso2.com
>> Mobile: *+ <+94%2077%20767%201807>94 774553167*
>> Web:  http://wso2.com
>>
>> 
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-15 Thread Cyril Rognon 
Hi

DB mediator can be handy as you said but it is a bad  practice to query the
DB right from the Esb. It is against the low coupling principles that makes
integration  layer agile and   thin and scalable etc.

DSS is setup in two  minutes and can fulfill your needs   out of the box.

Maybe we should provide a migration tool to turn  DBMediator usage into
Daraservices operation  call.  One could even  generate the dbs Dataservice
definition from the DBMediator.

+1 for deprecating these  mediators.  Setup some tool or complete
documentation to migrate existing usage.

Thanks,
Cyril
Le 9 déc. 2015 13:55, "Malaka Silva"  a écrit :

> In my experience using ​DB mediator we can cover some of the use cases
> using ESB out of the box, which I find very handy.
>
> Also use case of integrating with stored procs can easily covered with
> this.
>
> However there are limits like batch update or getting multiple rows.
>
> ​I guess we can argue both ways. IMO we should keep these mediators since
> it'll become handy for some use cases :)
>
> On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:
>
>>
>>
>> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>>
>>> +1 except  DBReport/DBLookup mediators
>>>
>>> DBReport and DBLookup only offer a very limited set of capabilities.
>> IMO, for any real integration scenario, we can't use them.  :).
>>
>>> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera 
>>> wrote:
>>>
 Is it possible to provide sufficient documentation to help the
 customers who would be migrating in future.

 Thanks,
 Yumani


 On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
 wrote:

> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> It will make a lot of confusion when we have more than one mediators
> to do the same thing. Therefore, better to deprecate this mediator.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always
> recommend to integrate with databases with the use of DSS (using a 
> separate
> DSS or using DSS features inside ESB)
>
> Even though this mediator has been used by some customers, they are
> using that for very limited functionality and we always suggest them to 
> use
> DSS as Kasun mentioned. If users really want to connect to a database, 
> they
> can easily write a simple class mediator.
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> +1 for deprecating these mediators.
>
> With the new DAS integration, we can deprecate BAM mediator since we
> have the PublishEvent mediator.
>
> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri 
> wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always
>> recommend to integrate with databases with the use of DSS (using a 
>> separate
>> DSS or using DSS features inside ESB)
>>
>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>> development happens on these.
>> *- Router* : Same as filter mediator, so no use of having this.
>> *- In, Out * : Rarely used and often not required with the new
>> call/respond mediator approach.
>>
>> Any comments  on these or any other features that we should deprecate
>> from 4.10 release?
>>
>> Thanks,
>> Kasun.
>>
>> --
>> Kasun Indrasiri
>> Software Architect
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> cell: +94 77 556 5206
>> Blog : http://kasunpanorama.blogspot.com/
>>
>
>
>
> --
> Thank you and Best Regards,
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --

[Dev] changing the XSLT Processor of the ESB

2015-11-16 Thread Cyril Rognon 
Hi all,

WSO2 ESB 4.9.0 is using saxon HE 9.6 as the XSLT Processor.

two questions :

if one is having a saxon 9.6 PE or EE edition, one only has to change the
lib in the endorsed directory ?
I I use saxon HE PE or more, would I be able to use xpath 3 or XSLT 3
functionnality provided in the ESB in all mediations or only in the XSLT /
Fast XSL mediator  or somewhere at all ?



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