Re: [Architecture] [IS] Claim verification API
Hi Janak, Shouldn't the [POST] claim-verification/validate and [POST] claim-verification/confirm be a single step (ex: [POST] claim-verification/verify). If additional customization is required, it would be just overriding one method. WDYT? Best Regards, Vidura Nanayakkara On Thu, Feb 14, 2019 at 3:37 PM Janak Amarasena wrote: > Hi All, > > [Update] > > The endpoints of the API was modified and now the following endpoints will > be used. > > 1. [POST] *claim-verification/init-verification *: Endpoint to initiate > the claim verification process. > 2. [POST] *claim-**verification**/**validate *: Endpoint to validate the > claim value. > 3. [POST] *claim-**verification**/**confirm *: Endpoint to confirm the > claim value. This endpoint is optional and will only be used depending on > whether further external validation is required. If not necessary the > validation process can be ended from the /validate endpoint. > 4. [POST] *claim-**verification**/revoke* : Endpoint to cancel the claim > verification process. > > You can find the *swagger doc* related to the API from here[1]. > > The feature will consist of 3 layers. > 1. The API layer - Which exposes the functionality of the service for > external use. > 2. The internal service layer - The actual service which will handle > operations related to confirmation codes, DB transactions. > 3. The Verifiers - Multiple pluggable components that will perform process > initiation(sending notifications) and validation of the claim value. Anyone > will be able to extend a common interface and write a verifier. > > > To give a bit more context; > >- Initially an admin will have to mark which claims need to be >verified, currently, it will be done by adding a claim metadata property. >- When a value for a verifiable claim is added/modified it will not be >stored in the userstore till the value is verified(Which will be done >through the provided API). The verification process will be triggered >depending on the Verifier used to verify the claim. The sent claim value >will be stored temporarily in a separate table which will be introduced >with this feature. >- When user details are retrieved, if there are pending claim >verifications available those claims will be also sent by adding a >prefix(configurable) to the claim name. For an example, if there is a >pending verification for "http://wso2.org/claims/emailaddress;, the " >http://wso2.org/claims/emailaddress; claim will be sent with the value >that is already in the userstore and " >http://wso2.org/claims/pending-emailaddress; claim will also be sent >with the changed emailaddress which is still pending verification. The >prefix "pending" will be configurable by an admin and will be a >reserved prefix which cannot be used for claim naming. Service providers >will have the ability to configure whether they want to receive claims that >are having pending verifications. > > > [1] - > https://gist.github.com/janakamarasena/4f37244758e3854d28f1b08f3bd36f6e > > Thank you, > Best Regards, > > Janak > > On Wed, Jan 23, 2019 at 10:39 AM Vihanga Liyanage > wrote: > >> OK, thanks for the clarification, Janak. >> >> On Wed, Jan 23, 2019 at 10:28 AM Janak Amarasena wrote: >> >>> Hi Vihanga, >>> >>> By default, no claims will be required for verification and an admin >>> user will decide which claims needs verification according to their use >>> case. Ideally how this will happen is we will have a property for a claim >>> where the admin user can mark whether that claim needs verification or >>> not through the management console. This part is not addressed in this >>> implementation and I will only be focusing on the API which will be used >>> for the verification process. >>> >>> Best Regards, >>> Janak >>> >>> On Tue, Jan 22, 2019 at 11:36 PM Vihanga Liyanage >>> wrote: >>> >>>> Hi Janak, >>>> >>>> AFAIU, We don't need to verify all claim changes for a particular user. >>>> For example, we can consider the address of the user. Are we planning to >>>> filter out these claims or add a default verification to all claim changes? >>>> >>>> Regards, >>>> Vihanga. >>>> >>>> On Mon, Jan 21, 2019 at 7:41 PM Janak Amarasena wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am currently working on creating a claim verification API which will >>>>> be used to verify user cl
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
Hi Jayanga and Ruwan, > Can we look into a way this can be triggered selectively with some > command-line option or an offline command? Reason to keep this logic from > slowing down the startup in production run. +1 for having a separate command-line option to apply the temporary patch. The reason is applying a temporary log patch to collect logs is a special case scenario and is not worth checking the files list in the [product_home]/lib to check whether there are any changes to the files. If the client can put the effort to apply a log patch and collect the logs certainly the client can start the server with an additional parameter. WDYT? Best Regards, Vidura Nanayakkara On Wed, May 17, 2017 at 6:01 PM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Ruwan, > > Thanks for the comments. > > In every server startup, it checks the files list in the > [product_home]/lib to check whether there are any changes to the files. > Yes, we could save some 'time' in the server startup if we provide a > separate tool. But there is a possibility that someone would miss running > that script and expect the new changes. Anyway, I'll check on the > possibilities of minimizing startup time taken. > > Regarding the checkpointing thing, the suggested approach keep the > original bundles.info file as a backup and always update it with the > bundles given in the [product_home]/lib. And we haven planned on keeping > the historical changes. Hence it will always be from original state to > latest state change. > > Thanks, > Jayanga. > > > *Jayanga Dissanayake* > Associate Technical Lead > WSO2 Inc. - http://wso2.com/ > lean . enterprise . middleware > email: jaya...@wso2.com > mobile: +94772207259 <+94%2077%20220%207259> > <http://wso2.com/signature> > > On Wed, May 17, 2017 at 10:17 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote: > >> + 1 on the idea of the four steps mentioned. >> Can we look into a way this can be triggered selectively with some >> command-line option or an offline command? Reason to keep this logic from >> slowing down the startup in production run. >> >> In addition to that, in future, we could able to enhance the same logic >> to allow similar behavior like "windows System Restore Point" or "OSX time >> machine" to revert to known point of WUM, by version controlling the >> bundle-info and the respective jars/configs. >> >> Cheers, >> Ruwan >> >> On Wed, May 17, 2017 at 9:21 AM, Jayanga Dissanayake <jaya...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> Existing OSGi deployment logic [1] keep updating the bundles.info file >>> as and when a bundle is added/removed from the [product_home]/lib directory. >>> >>> 1. It first read the bundles.info file of the current runtime >>> 2. Then take the list of bundles coming from "plugins" directory. >>> 3. Adds the bundles in the [product_home]/lib directory to the previous >>> list >>> 4. Get distinct bundles based on the bundle symbolic name and version. >>> (ignores bundles with same symbolic name and version already in the list, >>> hence bundles in the plugins directory get the priority) >>> 5. Update the bundles.info file >>> >>> The above-mentioned approach assumes all basic bundles for the runtime >>> coming from the "plugins" directory and adds the external bundles on top of >>> it. >>> >>> Recently we were looking into the C5 update/patching model and there was >>> a concern on how we could add a temporary log patches, etc. to identify an >>> issue. (in a case where all other possibilities failed). >>> >>> The most convenient to the client is to just add the given log patch to >>> the pack, restart, collect the relevant logs, and finally revert the log >>> patch. Any additional steps would be an overhead as the client is already >>> undergoing a severe issue and client is trying to help us to identify the >>> issue by applying the log patch. Hence this should be modeled in a >>> convenient way to the users. >>> >>> There is a possibility to let the clients add the log patch into the >>> [product_home]/lib directory and remove it once done. But with the current >>> OSGi bundle deployment logic, we can't do that as it always gives the >>> priority to the bundles in the plugins directory. If we put a bundle with >>> the same bundle-symbolic-name and version into the plugins directory it >>> will be ignored. >>> >>> To achieve this behavior we have to modify the
Re: [Architecture] [UUF] Extensible Authorization for UUF
Hi Imesh, Thanks Vidura! Would you mind explaining why each product has to implement > it's own authorizer? At the moment, AFAIK there is no common permission model for WSO2 products. For WSO2 Identity Server, we have [1] and there is currently a discussion going on regarding the permission model for WSO2 Message Broker 4 in [2]. If we are to decide on a common permission model for WSO2 products then we can provide a default Authorizer that would be packaged with Carbon UUF. Even in this case we should not use the implemented default Authorizer if it is not explicitly specified in the 'app.yaml' configuration. The reason for this is that Carbon UUF is an UI framework and should be able to be reused by any other product (should be loosely coupled). WDYT? Also, should we have a common permission model across the platform? [1] https://github.com/wso2/carbon-identity-mgt [2] Architecture mail thread "C5 based permission model for MB-4" Best Regards, Vidura Nanayakkara On Wed, May 17, 2017 at 4:30 PM, Imesh Gunaratne <im...@wso2.com> wrote: > > > On Wed, May 17, 2017 at 11:57 AM, Vidura Nanayakkara <vidu...@wso2.com> > wrote: > > >> Since we are not aware of the 'Authorizer' implementations that can be in >> a product (persisting and retrieving permissions logic) we cannot provide a >> default implementation to the 'Authorizer'. >> > > Thanks Vidura! Would you mind explaining why each product has to implement > it's own authorizer? > > Thanks > Imesh > > >> This has been documented in the 'Authorizer' interface [1]. >> >> [1] https://github.com/wso2/carbon-uuf/blob/3fbf10907747806d >> 6311acef2095e5a8b623e339/components/uuf-core/src/main/ >> java/org/wso2/carbon/uuf/spi/auth/Authorizer.java >> >> Best Regards, >> Vidura Nanayakkara >> >> On Wed, May 17, 2017 at 10:27 AM, Chandana Napagoda <chand...@wso2.com> >> wrote: >> >>> Hi Imesh, >>> >>> I think during the offline meeting, we have already discussed about the >>> default implementation. >>> >>> @ViduraN, Can you please elaborate it in here? >>> >>> Regards, >>> Chandana >>> >>> On Wed, May 17, 2017 at 10:08 AM, Imesh Gunaratne <im...@wso2.com> >>> wrote: >>> >>>> As we discussed offline I think it would be better to provide a default >>>> implementation for $subject while providing the extension point. >>>> >>>> Thanks >>>> >>>> On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna < >>>> sajit...@wso2.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We are in the process of introducing an extensible authorizer for >>>>> Carbon UUF. >>>>> >>>>> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au >>>>> th.User interface [1]. When creating an user session, implementation >>>>> of the User interface (e.g. CaasUser [2]) should be passed. The main >>>>> drawback of this approach is, the logic in the hasPermission() method >>>>> has to be serializable. Usually this is difficult to achieve because in >>>>> order to evaluate permissions one might need to access some user >>>>> management >>>>> services (e.g. Realm Service) which cannot be serialized. Hence moving the >>>>> hasPermission() method out of the User class and allowing to plug-in >>>>> a custom authorizer would be a better approach. >>>>> >>>>> WDYT? >>>>> >>>>> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo >>>>> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/Us >>>>> er.java#L28 >>>>> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl >>>>> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl >>>>> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle >>>>> /CaasUser.java >>>>> >>>>> Thanks. >>>>> -- >>>>> Sajith Janaprasad Ariyarathna >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >>>>> <https://wso2.com/signature> >>>>> >>>> >>>> >>>> >>>> -- >>>> *Imesh Gunaratne* >>>> WSO2 Inc: http://wso2.com >>>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>>> W: https://medium.com/@imesh TW: @imesh >>>> lean. enterprise. mi
Re: [Architecture] [UUF] Extensible Authorization for UUF
Hi Ruwan,
> I guess the following values defines the correlation between component and
> the authorizer.
@Component(name = "some.component.exposing.Authorizer,
> ...
authorizer: "some.component.exposing.Authorizer"
>
>
No, As a convention, we have the fully qualified class name as the OSGi
component name. The OSGi component name has nothing to do when it comes to
loading an Authorizer.
When loading an Authorizer, Carbon UUF uses the fully qualified class name
specified in the app.yaml configuration. In OSGi mode, Carbon UUF locates
the Authorizer instance from activated bundles. In the non-OSGi mode,
Carbon UUF creates an instance of the given class name in the
configuration. You may refer to [1] on how Carbon UUF plugs in an
Authorizer in OSGi mode and non-OSGI mode.
However, in the OSGi mode, you have to specify service class as highlighted
in bold below:
@Component(name = "some.component.exposing.Authorizer",
*service = Authorizer.**class**,*
immediate = true
)
[1]
https://github.com/wso2/carbon-uuf/blob/master/components/uuf-core/src/main/java/org/wso2/carbon/uuf/internal/deployment/OsgiPluginProvider.java
Best Regards,
Vidura Nanayakkara
On Fri, May 12, 2017 at 5:43 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
> Hi Vidura,
> Thanks for the information,
>
> I guess the following values defines the correlation between component and
> the authorizer.
>
> @Component(name = "some.component.exposing.Authorizer,
> ...
> authorizer: "some.component.exposing.Authorizer"
>
> Cheers,
> Ruwan
>
> On Fri, May 12, 2017 at 5:34 PM, Vidura Nanayakkara <vidu...@wso2.com>
> wrote:
>
>> Hi Ruwan,
>>
>> This supports OSGI mode as well. In that case, you have to add the
>> @Component annotation to the implemented class.
>>
>> e.g:
>>
>> @Component(name = "org.wso2.carbon.uuf.sample.si
>> mpleauth.bundle.api.auth.CaasAuthorizer",
>>
>> service = Authorizer.class,
>> immediate = true
>> )
>> public class CaasAuthorizer implements Authorizer {
>>
>> @Override
>> public boolean hasPermission(User user, Permission permission) {
>> *// Some logic here.*
>> }
>> }
>>
>>
>> Best Regards,
>> Vidura Nanayakkara
>>
>> On Fri, May 12, 2017 at 5:24 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>>
>>> Hi All,
>>> >>
>>> # Authorizer for this app
>>> authorizer: "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasA
>>> uthorizer"
>>>
>>>
>>> Does this means UUF uses reflection to instantiate the class given by
>>> the "authorizer" property? If this is the case, could you make it using
>>> OSGI service instead.
>>>
>>> Cheers,
>>> Ruwan
>>>
>>> On Fri, May 12, 2017 at 5:17 PM, Vidura Nanayakkara <vidu...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> The following changes will be made to the UUF framework in order to
>>>> archive the above.
>>>>
>>>>- You now have to implement the `Authorizer` interface in order to
>>>>plug in any type of `Authorizer` you want. `Authorizer` interface will
>>>> have
>>>>the following methods:
>>>>
>>>> boolean hasPermission(User user, Permission permission);
>>>>
>>>>
>>>>- In order to plug in the `Authorizer`, the `Authorizer`
>>>>implementation needs to be specified in the `app.yaml` configuration of
>>>> the
>>>>particular UUF app.
>>>>
>>>> ...
>>>>
>>>> # Authorizer for this app
>>>> authorizer:
>>>> "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasAuthorizer"
>>>> ...
>>>>
>>>> Please note that if you do not specify this value, the app will not have
>>>> an `Authorizer` and will return `false` every time the `hasPermission()`
>>>> method is called.
>>>>
>>>>
>>>>- Instead of the `User` interface, we now have introduced a
>>>>concrete `User` class.
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 3, 2017 at 10:34 PM, Rasika Perera <rasi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Sajith,
>>>>>
>>>>> I am +1 to allow custom authorizers. But not bit convinced with the
>>>>> reason provided.
>>
Re: [Architecture] [UUF] Extensible Authorization for UUF
Hi Ruwan,
This supports OSGI mode as well. In that case, you have to add the
@Component annotation to the implemented class.
e.g:
@Component(name = "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.
CaasAuthorizer",
service = Authorizer.class,
immediate = true
)
public class CaasAuthorizer implements Authorizer {
@Override
public boolean hasPermission(User user, Permission permission) {
*// Some logic here.*
}
}
Best Regards,
Vidura Nanayakkara
On Fri, May 12, 2017 at 5:24 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
> Hi All,
> >>
> # Authorizer for this app
> authorizer: "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasA
> uthorizer"
>
>
> Does this means UUF uses reflection to instantiate the class given by the
> "authorizer" property? If this is the case, could you make it using OSGI
> service instead.
>
> Cheers,
> Ruwan
>
> On Fri, May 12, 2017 at 5:17 PM, Vidura Nanayakkara <vidu...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> The following changes will be made to the UUF framework in order to
>> archive the above.
>>
>>- You now have to implement the `Authorizer` interface in order to
>>plug in any type of `Authorizer` you want. `Authorizer` interface will
>> have
>>the following methods:
>>
>> boolean hasPermission(User user, Permission permission);
>>
>>
>>- In order to plug in the `Authorizer`, the `Authorizer`
>>implementation needs to be specified in the `app.yaml` configuration of
>> the
>>particular UUF app.
>>
>> ...
>>
>> # Authorizer for this app
>> authorizer:
>> "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasAuthorizer"
>> ...
>>
>> Please note that if you do not specify this value, the app will not have an
>> `Authorizer` and will return `false` every time the `hasPermission()` method
>> is called.
>>
>>
>>- Instead of the `User` interface, we now have introduced a
>>concrete `User` class.
>>
>>
>>
>>
>> On Wed, May 3, 2017 at 10:34 PM, Rasika Perera <rasi...@wso2.com> wrote:
>>
>>> Hi Sajith,
>>>
>>> I am +1 to allow custom authorizers. But not bit convinced with the
>>> reason provided.
>>>
>>> Java allows non-serializable properties on the objects with "transient"
>>> keyword. At the time of deserialize these properties will be in default
>>> values (i.e. objects will be null). Then you can override "readResolve()"
>>> method to fetch & assign the current state of the system for those
>>> properties.
>>>
>>> Best Regards,
>>> Rasika
>>>
>>> On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <sajit...@wso2.com
>>> > wrote:
>>>
>>>> Hi All,
>>>>
>>>> We are in the process of introducing an extensible authorizer for
>>>> Carbon UUF.
>>>>
>>>> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au
>>>> th.User interface [1]. When creating an user session, implementation
>>>> of the User interface (e.g. CaasUser [2]) should be passed. The main
>>>> drawback of this approach is, the logic in the hasPermission() method
>>>> has to be serializable. Usually this is difficult to achieve because in
>>>> order to evaluate permissions one might need to access some user management
>>>> services (e.g. Realm Service) which cannot be serialized. Hence moving the
>>>> hasPermission() method out of the User class and allowing to plug-in a
>>>> custom authorizer would be a better approach.
>>>>
>>>> WDYT?
>>>>
>>>> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo
>>>> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/User.java#L28
>>>> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl
>>>> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl
>>>> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle
>>>> /CaasUser.java
>>>>
>>>> Thanks.
>>>> --
>>>> Sajith Janaprasad Ariyarathna
>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/
>>>> <https://wso2.com/signature>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/
Re: [Architecture] [UUF] Extensible Authorization for UUF
Hi All, The following changes will be made to the UUF framework in order to archive the above. - You now have to implement the `Authorizer` interface in order to plug in any type of `Authorizer` you want. `Authorizer` interface will have the following methods: boolean hasPermission(User user, Permission permission); - In order to plug in the `Authorizer`, the `Authorizer` implementation needs to be specified in the `app.yaml` configuration of the particular UUF app. ... # Authorizer for this app authorizer: "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasAuthorizer" ... Please note that if you do not specify this value, the app will not have an `Authorizer` and will return `false` every time the `hasPermission()` method is called. - Instead of the `User` interface, we now have introduced a concrete `User` class. On Wed, May 3, 2017 at 10:34 PM, Rasika Perera <rasi...@wso2.com> wrote: > Hi Sajith, > > I am +1 to allow custom authorizers. But not bit convinced with the reason > provided. > > Java allows non-serializable properties on the objects with "transient" > keyword. At the time of deserialize these properties will be in default > values (i.e. objects will be null). Then you can override "readResolve()" > method to fetch & assign the current state of the system for those > properties. > > Best Regards, > Rasika > > On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <sajit...@wso2.com> > wrote: > >> Hi All, >> >> We are in the process of introducing an extensible authorizer for Carbon >> UUF. >> >> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au >> th.User interface [1]. When creating an user session, implementation of >> the User interface (e.g. CaasUser [2]) should be passed. The main >> drawback of this approach is, the logic in the hasPermission() method >> has to be serializable. Usually this is difficult to achieve because in >> order to evaluate permissions one might need to access some user management >> services (e.g. Realm Service) which cannot be serialized. Hence moving the >> hasPermission() method out of the User class and allowing to plug-in a >> custom authorizer would be a better approach. >> >> WDYT? >> >> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo >> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/User.java#L28 >> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl >> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl >> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle >> /CaasUser.java >> >> Thanks. >> -- >> Sajith Janaprasad Ariyarathna >> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >> <https://wso2.com/signature> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With Regards, > > *Rasika Perera* > Senior Software Engineer > LinkedIn: http://lk.linkedin.com/in/rasika90 > > <http://wso2.com/signature> > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [UUF] Extensible Session Management for UUF
Hi All, The `SessionManager` interface and `SessionManagerFactory` interface methods would be as follows: *SessionManager* This class is responsible for managing the user sessions for a single UUF app. - Session createSession(User user, HttpRequest request, HttpResponse response) throws SessionManagerException; - Optional getSession(HttpRequest request, HttpResponse response) throws SessionManagerException; - boolean destroySession(HttpRequest request, HttpResponse response) throws SessionManagerException; - int getCount(); *SessionManagerFactory* This class is responsible for providing session managers for UUF apps. - SessionManager getSessionManager(String appName, Configuration configuration) throws SessionManagerException; On Tue, May 2, 2017 at 5:57 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi All, > > According to [1], the following points will be amended. > > In order to plug in a custom session manager, one need to implement the > given `SessionManager` and the `SessionManagerFactory` interface. That > implementation needs to be specified in the `app.yaml` configuration of the > particular UUF app. > > Example app.yaml configuration: > > *# Session manager configuration for this app* > *sessionManagement:* > *# Session manager factory for this app* > *factoryClassName: "..."* > *# Session timeout in seconds for this app* > *timeout: 600* > > > [1] Updated Invitation: UUF Pluggable Session Manager and Authenticator > Review @ Tue May 2, 2017 2:30pm - 3:30pm (IST) (WSO2 Engineering Group) > > > On Tue, May 2, 2017 at 12:53 PM, Dilan Udara Ariyaratne <dil...@wso2.com> > wrote: > >> Hi Sajith, >> >> My apologies. Did not see the fact that SessionManager is already >> extending SessionHandler, >> so with your explanation on their difference, it seems fine to me. >> >> Thanks, >> Dilan. >> >> >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Tue, May 2, 2017 at 12:18 PM, SajithAR Ariyarathna <sajit...@wso2.com> >> wrote: >> >>> Hi Dilan, >>> >>> The purpose of the SessionHandler and SessionManager is different. >>> >>> SessionManager is an extension point (a plugin for UUF) for webapp >>> developers. SessionHandler is meant to be passed for other plugins (e.g. >>> Authenticator) as a way do session related operations (e.g. create a new >>> session when login). If we pass the SessionManager instead, it will over >>> expose the session management operations (e.g. close() method). So to >>> encapsulate properly we decided to go with two interfaces, SessionHandler >>> and SessionManager. >>> >>> Thanks. >>> >>> On Tue, May 2, 2017 at 11:49 AM, Dilan Udara Ariyaratne <dil...@wso2.com >>> > wrote: >>> >>>> Hi Imesh and @Vidura, >>>> >>>> I wonder if both SessionHandler and SessionManager interfaces could be >>>> merged together to have one interface >>>> that could derive all management level functionalities of a session ? >>>> >>>> I think that current SessionManager, i.e. org.wso2.carbon.uuf.spi.auth. >>>> SessionManager is bit meaningless without capabilities like >>>> createSession(), getSession() and destroySession() that >>>> org.wso2.carbon.uuf.api.auth.SessionHandler provides. >>>> >>>> WDYT? >>>> >>>> Thanks, >>>> Dilan. >>>> >>>> *Dilan U. Ariyaratne* >>>> Senior Software Engineer >>>> WSO2 Inc. <http://wso2.com/> >>>> Mobile: +94766405580 <%2B94766405580> >>>> lean . enterprise . middleware >>>> >>>> >>>> On Tue, May 2, 2017 at 11:02 AM, Imesh Gunaratne <im...@wso2.com> >>>> wrote: >>>> >>>>> On Tue, May 2, 2017 at 10:44 AM, Dilan Udara Ariyaratne < >>>>> dil...@wso2.com> wrote: >>>>> >>>>>> >>>>>> In the meantime, could you elaborate on the method level details of >>>>>> the Session manager interface, too? >>>>>> >>>>> >>>>> SessionManager: >>>>> https://github.com/wso2/carbon-uuf/pull/241/files#diff-50f8 >>>>> 2419222617b7f14b6d08d45984ac >>>>> >>>>> SessionHandler: >>>>> h
Re: [Architecture] [UUF] Extensible Session Management for UUF
Hi All, According to [1], the following points will be amended. In order to plug in a custom session manager, one need to implement the given `SessionManager` and the `SessionManagerFactory` interface. That implementation needs to be specified in the `app.yaml` configuration of the particular UUF app. Example app.yaml configuration: *# Session manager configuration for this app* *sessionManagement:* *# Session manager factory for this app* *factoryClassName: "..."* *# Session timeout in seconds for this app* *timeout: 600* [1] Updated Invitation: UUF Pluggable Session Manager and Authenticator Review @ Tue May 2, 2017 2:30pm - 3:30pm (IST) (WSO2 Engineering Group) On Tue, May 2, 2017 at 12:53 PM, Dilan Udara Ariyaratne <dil...@wso2.com> wrote: > Hi Sajith, > > My apologies. Did not see the fact that SessionManager is already > extending SessionHandler, > so with your explanation on their difference, it seems fine to me. > > Thanks, > Dilan. > > > > *Dilan U. Ariyaratne* > Senior Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94766405580 <%2B94766405580> > lean . enterprise . middleware > > > On Tue, May 2, 2017 at 12:18 PM, SajithAR Ariyarathna <sajit...@wso2.com> > wrote: > >> Hi Dilan, >> >> The purpose of the SessionHandler and SessionManager is different. >> >> SessionManager is an extension point (a plugin for UUF) for webapp >> developers. SessionHandler is meant to be passed for other plugins (e.g. >> Authenticator) as a way do session related operations (e.g. create a new >> session when login). If we pass the SessionManager instead, it will over >> expose the session management operations (e.g. close() method). So to >> encapsulate properly we decided to go with two interfaces, SessionHandler >> and SessionManager. >> >> Thanks. >> >> On Tue, May 2, 2017 at 11:49 AM, Dilan Udara Ariyaratne <dil...@wso2.com> >> wrote: >> >>> Hi Imesh and @Vidura, >>> >>> I wonder if both SessionHandler and SessionManager interfaces could be >>> merged together to have one interface >>> that could derive all management level functionalities of a session ? >>> >>> I think that current SessionManager, i.e. >>> org.wso2.carbon.uuf.spi.auth.SessionManager >>> is bit meaningless without capabilities like >>> createSession(), getSession() and destroySession() that >>> org.wso2.carbon.uuf.api.auth.SessionHandler provides. >>> >>> WDYT? >>> >>> Thanks, >>> Dilan. >>> >>> *Dilan U. Ariyaratne* >>> Senior Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> Mobile: +94766405580 <%2B94766405580> >>> lean . enterprise . middleware >>> >>> >>> On Tue, May 2, 2017 at 11:02 AM, Imesh Gunaratne <im...@wso2.com> wrote: >>> >>>> On Tue, May 2, 2017 at 10:44 AM, Dilan Udara Ariyaratne < >>>> dil...@wso2.com> wrote: >>>> >>>>> >>>>> In the meantime, could you elaborate on the method level details of >>>>> the Session manager interface, too? >>>>> >>>> >>>> SessionManager: >>>> https://github.com/wso2/carbon-uuf/pull/241/files#diff-50f8 >>>> 2419222617b7f14b6d08d45984ac >>>> >>>> SessionHandler: >>>> https://github.com/wso2/carbon-uuf/pull/241/files#diff-39f1b >>>> 4c291c422e721e8c56d191c75e3 >>>> >>>> Thanks >>>> >>>>> >>>>> Cheers, >>>>> Dilan. >>>>> >>>>> *Dilan U. Ariyaratne* >>>>> Senior Software Engineer >>>>> WSO2 Inc. <http://wso2.com/> >>>>> Mobile: +94766405580 <%2B94766405580> >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> On Mon, May 1, 2017 at 10:39 PM, Shazni Nazeer <sha...@wso2.com> >>>>> wrote: >>>>> >>>>>> It is beneficial to have this in the UUF. >>>>>> >>>>>> Many frameworks (in particular web frameworks such as Django, CakePHP >>>>>> and Ruby on Rails) support this kind of pluggable Session Management >>>>>> capabilities. >>>>>> >>>>>> On Fri, Apr 28, 2017 at 3:46 PM, Vidura Nanayakkara <vidu...@wso2.com >>>>>> > wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >
[Architecture] [UUF] Extensible Session Management for UUF
Hi All, We are in the process of introducing extensible session management mechanism for Carbon UUF. Previously in Carbon UUF, the session management was not extensible and was tightly coupled to the Carbon UUF framework. The purpose of introducing an extensible session management mechanism is to give the ability for the web app developers to plug in any session management implementation of choice. For instance, this can be a JDBC persistent session management or a token based session management implementation. In order to plug in a custom session manager, one need to implement the given `SessionManager` interface. That implementation needs to be specified in the `app.yaml` configuration of the particular UUF app. Example app.yaml configuration: *...* # Session manager for this app sessionManager: *"org.wso2.carbon.uuf.api.auth.InMemorySessionManager"* *...* *WDYT?* Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 <+94%2071%20791%209277> Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Archtecture] How to initialize securevault service inside Configuration Provider in non-OSGi mode.
Hi Danesh, IMO, option 2 can be used in OSGi mode. However, in non-OSGi mode, we may use the secure vault only rather than using the config provider and the secure vault. Therefore having a deployment.yaml file including the secure vault yaml configuration sounds a bit odd. Furthermore in this case how are we extracting the secure vault configuration out of the deployment yaml. *Suggestion: *IMO we should proceed with option 2 in OSGi mode and option 1 in non-OSGi mode. So in non-OSGi mode how the user initializes secure vault would be like: Example 1: Path secureVaultconfigPath = ; SecureVaultFactory secureVaultFactory = new SecureVaultFactory(); SecureVault secureVault = secureVaultFactory.getSecureVault(secureVaultconfigPath); or Example 2: Path secureVaultconfigPath = ; SecureVaultConfiguration securevaultconfiguration = SecureVaultConfigProvider.createSecureVaultConfiguration(secureVaultconfigPath); SecureVaultFactory secureVaultFactory = new SecureVaultFactory(); SecureVault secureVault = secureVaultFactory.getSecureVault(securevaultconfiguration); In the OSGi mode we can use Example 2 when initializing securevault inside the config provider. WDYT? On Fri, Mar 31, 2017 at 11:02 AM, Danesh Kuruppu <dan...@wso2.com> wrote: > Hi all, > > In the current non-OSGi securevault implementation, we need to pass > securevault configuration file path when initializing the securevault > service instance. like below, > >> Path *configPath* = ;SecureVaultFactory >> secureVaultFactory = new SecureVaultFactory();SecureVault secureVault = >> secureVaultFactory.getSecureVault(*configPath*); >> >> > Since Configuration Provider directly depends on securevault, we need to > initialize securevault instance because initializing the Configuration > Provider. Below are few options we can follow when initializing Config > Provider non-OSGi mode > > Option 01: Force user to create securevault instance before creating > Configuration Provider instance. We will provide method in provider factory > to get ConfigProvider by passing deployment config file path and > securevault instance. like below, > > Path *secureVaultconfigPath* = path>;SecureVaultFactory secureVaultFactory = new > SecureVaultFactory();SecureVault *secureVault* = > secureVaultFactory.getSecureVault(*secureVaultconfigPath*); >> >> Path *deploymentConfigPath* = ; >> ConfigProviderFactory configProviderFactory = new ConfigProviderFactory(); >> ConfigProvider configProvider = >> configProviderFactory.getConfigProvider(*deploymentConfigPath*, >> *secureVault*); >> >> > Option 02: Allow user to pass deployment.yaml(can be any file name) file > path only and we create the securevault instance. in order to do that, we > should know the securevault config file path. Shall we add securevault > configuration also to the deployment.yaml file(can be any file name. we > keep same file to hold both server configs and securevault configs) and > pass the same file to initialize securevault when initializing > configuration provider. So configuration file will looks like, > ... > > wso2.securevault: > secretRepository: > type: org.wso2.carbon.secvault.repository.DefaultSecretRepository > parameters: > privateKeyAlias: wso2carbon > keystoreLocation: resources/security/wso2carbon.jks > secretPropertiesFile: conf/secrets.properties > masterKeyReader: > type: org.wso2.carbon.secvault.reader.DefaultMasterKeyReader > parameters: > masterKeyReaderFile: conf/master-keys.yaml > > ... > > So when initializing the securevault, provider will read the same config > file and get configurations under wso2.securevault. > > Please share your thoughts / suggestions. > > Thanks > -- > > *Danesh Kuruppu* > Senior Software Engineer | WSO2 > > Email: dan...@wso2.com > Mobile: +94 (77) 1690552 <+94%2077%20169%200552> > Web: WSO2 Inc <https://wso2.com/signature> > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi All,
Let me do certain clarifications regarding this email. Apologies since the
actual message is not conveyed.
We need to do the OSGi / non-OSGi check only once. However, if we follow
the previous secure-vault.yaml structure (without the secrets.properties
path and the master-keys.yaml path) we have to get these files through the
implementation which means that for OSGi mode we will look for these files
in the carbon config home and in the non-OSGi mode we will look for these
files in the resources. If we are to provide the locations of these files
without limiting to the carbon config home or resource path we have to
provide the ability state the relevant paths. There are 3 ways we can do
this.
1. Let the user override a method to get the master keys YAML path and
the secrets properties path - This is not a convenient approach for the user
2. Provide these locations through environment variables.
3. Set these path values in secure-vault.yaml
The suggested approach was 3, since according to the discussions we had in
[1]
<http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>,
we decide to get the secure-vault.yaml location from carbon config home in
OSGi mode (we are not talking about different runtimes yet) and from system
property, environment variable or class path in non-OSGi mode. If we
specify the paths of master-keys.yaml and secrets.properties in
secure-vault.yaml we only need to specify the path of the
secure-vault.yaml as per the discussions we had in [1]
<http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>
.
Myself, Jayanga and Niranjan had a discussion regarding this matter
yesterday. Here are the points we discussed during the discussion.
- Obtaining the secure-vault.yaml path in OSGi mode will be carbon
config home by default (as discussed in [1]
<http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>)
You can change this path via a system property or an environment variable.
In non-OSGi mode the secure-vault.yaml would be provided via the
implementation (SecureVaultInitializer.getInstance.initialise(Path
secureVaultYaml)).
- Obtaining the paths of the master-keys.yaml and the secret.properties
will be by default taken from the secure-vault.yaml configuration file. If
this is not specified in the secure-vault.yaml then it will refer to the
relevant configuration location (OSGi / non-OSGi).
The reason for specifying these path values in secure-vault.yaml is since
master-keys.yaml file and the secret.properties file will be taken from any
outside location (rather than classpath) in non-OSGi mode.
WDYT?
On Fri, Mar 17, 2017 at 11:41 AM, Lakshman Udayakantha <lakshm...@wso2.com>
wrote:
> Adding these files to parameter section makes no difference because
> parameter section includes implementation specific data. So I think it is
> ok to keep them in parameter section as well. It is up to the
> implementation.
>
> On Fri, Mar 17, 2017 at 10:42 AM, Vidura Nanayakkara <vidu...@wso2.com>
> wrote:
>
>> Hi Kishanthan,
>>
>> When we have the master-keys.yaml and secrets.properties yaml file path
>> in secure-vault.yaml configuration the end user do not need to override a
>> method to explain how the paths are taken but rather handled within the
>> secure vauilt implementation itself. So if the paths are specified as a
>> relative path, we can locate the files using the relevant configuration
>> file location (OSGi / non-OSGi) and if we specify the absolute path, we can
>> locate the file straight away from the specified location.
>>
>>
>> On Fri, Mar 17, 2017 at 10:28 AM, Vidura Nanayakkara <vidu...@wso2.com>
>> wrote:
>>
>>> Hi Niranjan,
>>>
>>> Ideally, the OSGi / non-OSGi check should happen at the secure vault
>>> initialization phase. The rest of the execution should happen accordingly
>>> without checking for OSGi / non-OSGi. However, if we delegate providing
>>> other file paths (secret.properties, master-key.yaml) to relevant
>>> implementation classes we need to get the file location accordingly (OSGi /
>>> non-OSGi). This will require an OSGi / non-OSGi check (even if we set the
>>> OSGi / non-OSGi config path during initialization how would the end
>>> developer know when overriding a specific method?)
>>>
>>> Example:
>>>
>>> @Override
>>> public Path getMasterKeyYAMLPath() throws SecureVaultException {
>>> Path m
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi Kishanthan,
When we have the master-keys.yaml and secrets.properties yaml file path in
secure-vault.yaml configuration the end user do not need to override a
method to explain how the paths are taken but rather handled within the
secure vauilt implementation itself. So if the paths are specified as a
relative path, we can locate the files using the relevant configuration
file location (OSGi / non-OSGi) and if we specify the absolute path, we can
locate the file straight away from the specified location.
On Fri, Mar 17, 2017 at 10:28 AM, Vidura Nanayakkara <vidu...@wso2.com>
wrote:
> Hi Niranjan,
>
> Ideally, the OSGi / non-OSGi check should happen at the secure vault
> initialization phase. The rest of the execution should happen accordingly
> without checking for OSGi / non-OSGi. However, if we delegate providing
> other file paths (secret.properties, master-key.yaml) to relevant
> implementation classes we need to get the file location accordingly (OSGi /
> non-OSGi). This will require an OSGi / non-OSGi check (even if we set the
> OSGi / non-OSGi config path during initialization how would the end
> developer know when overriding a specific method?)
>
> Example:
>
> @Override
> public Path getMasterKeyYAMLPath() throws SecureVaultException {
> Path masterKeysFilePath;
> if (SecureVaultUtils.isOSGIEnv()) {
> Path carbonHomePath = Utils.getCarbonHome();
> masterKeysFilePath = Paths.get(carbonHomePath.toString(),
> MASTER_KEYS_FILE_NAME);
> } else {
> Optional resourcePath = SecureVaultUtils
> .getResourcePath("securevault", "conf",
> MASTER_KEYS_FILE_NAME);
> if (!resourcePath.isPresent()) {
> throw new SecureVaultException(MASTER_KEYS_FILE_NAME +
> "not found");
> }
> masterKeysFilePath = resourcePath.get();
> }
> return masterKeysFilePath;
> }
>
>
> We do not need to do an OSGi / non-OSGi check if we include the
> secrets.properties and master-keys.yaml in the secure-vault.yaml as stated
> above since we can keep the relevant paths in memory accordingly during the
> secure vault initialization phase. Furthermore, is it really required to
> delegate providing other file paths to the relevant implementation when we
> can handle this from the secure-vault.yaml itself?
>
> My suggestion is to specify the locations in the secure-vault.yaml. This
> way if we specify a relative path, we can get the path according to the
> OSGi / non-OSGi mode (predefined configuration locations). If we specify an
> absolute path we can take the path as it is to locate the files.
>
> WDYT?
>
> On Fri, Mar 17, 2017 at 10:18 AM, Niranjan Karunanandham <
> niran...@wso2.com> wrote:
>
>> Hi Jayanga,
>>
>>
>> On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake <jaya...@wso2.com>
>> wrote:
>>
>>> Hi Niranjan,
>>>
>>> You are correct we should follow the same way as msf4j to detect
>>> whether it is OSGi mode or not.
>>> The properties suggested are to avoid the OSGi mode check in several
>>> places. With the suggested properties, secure-vault.yaml will have all the
>>> information it needs for the initialization. Hence it could check the mode
>>> at one place and initialize the secure vault accordingly.
>>>
>> Is it possible to move the parts where we need to check if it is an OSGi
>> mode or not to a generic place that is at the start and these values are
>> based to the implementation later? So that the implementation layer does
>> not need to know whether it is a OSGi or non-OSGi.
>>
>>
>>>
>>> Thanks,
>>> Jayanga.
>>>
>>> *Jayanga Dissanayake*
>>> Associate Technical Lead
>>> WSO2 Inc. - http://wso2.com/
>>> lean . enterprise . middleware
>>> email: jaya...@wso2.com
>>> mobile: +94772207259 <+94%2077%20220%207259>
>>> <http://wso2.com/signature>
>>>
>>> On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
>>>> Hi Vidura,
>>>>
>>>> We can identify whether it is in OSGi mode or non-OSGi mode by checking
>>>> if the bundleContext is set. If it is not set, then it is in non-OSGi mode.
>>>> This is the way we have done for msf4j. Any reason for this new approach?
>>>>
>>>> Regards,
>>>> Nira
>>>>
>>>> On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayakantha <
>>>> lakshm...@wso2.com> wrote:
>>&
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi Niranjan,
Ideally, the OSGi / non-OSGi check should happen at the secure vault
initialization phase. The rest of the execution should happen accordingly
without checking for OSGi / non-OSGi. However, if we delegate providing
other file paths (secret.properties, master-key.yaml) to relevant
implementation classes we need to get the file location accordingly (OSGi /
non-OSGi). This will require an OSGi / non-OSGi check (even if we set the
OSGi / non-OSGi config path during initialization how would the end
developer know when overriding a specific method?)
Example:
@Override
public Path getMasterKeyYAMLPath() throws SecureVaultException {
Path masterKeysFilePath;
if (SecureVaultUtils.isOSGIEnv()) {
Path carbonHomePath = Utils.getCarbonHome();
masterKeysFilePath = Paths.get(carbonHomePath.toString(),
MASTER_KEYS_FILE_NAME);
} else {
Optional resourcePath = SecureVaultUtils
.getResourcePath("securevault", "conf",
MASTER_KEYS_FILE_NAME);
if (!resourcePath.isPresent()) {
throw new SecureVaultException(MASTER_KEYS_FILE_NAME + "not
found");
}
masterKeysFilePath = resourcePath.get();
}
return masterKeysFilePath;
}
We do not need to do an OSGi / non-OSGi check if we include the
secrets.properties and master-keys.yaml in the secure-vault.yaml as stated
above since we can keep the relevant paths in memory accordingly during the
secure vault initialization phase. Furthermore, is it really required to
delegate providing other file paths to the relevant implementation when we
can handle this from the secure-vault.yaml itself?
My suggestion is to specify the locations in the secure-vault.yaml. This
way if we specify a relative path, we can get the path according to the
OSGi / non-OSGi mode (predefined configuration locations). If we specify an
absolute path we can take the path as it is to locate the files.
WDYT?
On Fri, Mar 17, 2017 at 10:18 AM, Niranjan Karunanandham <niran...@wso2.com>
wrote:
> Hi Jayanga,
>
>
> On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake <jaya...@wso2.com>
> wrote:
>
>> Hi Niranjan,
>>
>> You are correct we should follow the same way as msf4j to detect whether
>> it is OSGi mode or not.
>> The properties suggested are to avoid the OSGi mode check in several
>> places. With the suggested properties, secure-vault.yaml will have all the
>> information it needs for the initialization. Hence it could check the mode
>> at one place and initialize the secure vault accordingly.
>>
> Is it possible to move the parts where we need to check if it is an OSGi
> mode or not to a generic place that is at the start and these values are
> based to the implementation later? So that the implementation layer does
> not need to know whether it is a OSGi or non-OSGi.
>
>
>>
>> Thanks,
>> Jayanga.
>>
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> <http://wso2.com/signature>
>>
>> On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Vidura,
>>>
>>> We can identify whether it is in OSGi mode or non-OSGi mode by checking
>>> if the bundleContext is set. If it is not set, then it is in non-OSGi mode.
>>> This is the way we have done for msf4j. Any reason for this new approach?
>>>
>>> Regards,
>>> Nira
>>>
>>> On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayakantha <
>>> lakshm...@wso2.com> wrote:
>>>
>>>> Hi Vidura,
>>>>
>>>> On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara <vidu...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> An example for a secure vault YAML configuration file is as shown
>>>>> below according to the current implementation.
>>>>>
>>>>> secretRepository:
>>>>> type: org.wso2.carbon.kernel.securevault.repository.DefaultSecretR
>>>>> epository
>>>>> parameters:
>>>>> privateKeyAlias: wso2carbon
>>>>> keystoreLocation: resources/security/wso2carbon.jks
>>>>> masterKeyReader:
>>>>> type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyRe
>>>>> ader
>>>>>
>>>>> However, according to the discussion made in [1]
>>>>> <ht
[Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi All, An example for a secure vault YAML configuration file is as shown below according to the current implementation. secretRepository: type: org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository parameters: privateKeyAlias: wso2carbon keystoreLocation: resources/security/wso2carbon.jks masterKeyReader: type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader However, according to the discussion made in [1] <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> , we decided to move Carbon Secure Vault out of Carbon Kernel for the specified reasons in [1] <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>. According to this change, in OSGi mode the Secret repository and the master key reader will be an implementation of the specified classes ( org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository and org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader) and will be registered via the Secure Vault Component while in standalone mode the secret repository and master key reader will be instances of the specified classes and will be created using the class.forName() method. According to this implementation, it was decided to delegate providing other file paths (secret.properties, master-key.yaml) to relevant implementation classes because other file paths (secret.properties, master-key.yaml) are bound to the relevant implementation. However, with this approach, we are forced to check whether the code is being executed in OSGi mode or non-OSGi mode in order to provide the correct location of the file paths (secret.properties, master-key.yaml). *Suggestion:* secretRepository: type: org.wso2.carbon.secvault.securevault.repository.DefaultSecretRepository parameters: privateKeyAlias: wso2carbon keystoreLocation: securevault/resources/security/wso2carbon.jks secretProperties: securevault/resources/security/secrets.properties masterKeyReader: type: org.wso2.carbon.secvault.securevault.utils.DefaultHardCodedMasterKeyReader parameters: masterKeyFile: securevault/resources/security/master-keys.yaml If we could add the highlighted properties to the secure vault YAML configuration file specifying the location of the master-keys.yaml and secrets.properties, we only need to check whether the code is being executed in OSGi mode or non-OSGi mode once at the time of secure vault initialisation. WDYT? [1] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel) <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi All, We can create a tempory branch out from the master in Carbon Kernel [1] <https://github.com/wso2/carbon-kernel>, merge Lakshman's PR to that branch and then move it to the Carbon SecVault [2] <https://github.com/wso2/carbon-secvault> (not the master branch - we need to create another new branch here). This way we can we can preserve the commit history. I will create my pull request to the new branch in Carbon Sec Vault. [1] Carbon Kernel <https://github.com/wso2/carbon-kernel> [2] Carbon Secure Vault <https://github.com/wso2/carbon-secvault> On Fri, Mar 10, 2017 at 7:11 PM, Niranjan Karunanandham <niran...@wso2.com> wrote: > Hi all, > > On Fri, Mar 10, 2017 at 6:55 PM, Lakshman Udayakantha <lakshm...@wso2.com> > wrote: > >> Hi Imesh, >> >> On Fri, Mar 10, 2017 at 3:54 PM, Imesh Gunaratne <im...@wso2.com> wrote: >> >>> Hi Vidura, >>> >>> I think it would be better if we can first move the secure vault code >>> from carbon-kernel repository to the new repository with commit history and >>> then apply the changes you have done. Otherwise, we will loose all history. >>> >> +1 to preserve history. >> >>> >>> I had a chat with Lakshman on this and it seems like he has extracted >>> all secure-vault related code into a new component and sent a PR [1] but it >>> has not been merged. >>> >>> IMO we would need to do following: >>> >>>- First, fix conflicts and merge [1]. This would bring all secure >>>vault related code to a new component/folder. >>> >>> I have solved the conflicts and updated the PR. >> > I am -1 for merging this in kernel master branch because this PR is not > complete and there were couple of changes requested for this. Lakshman had > moved the PR to the new repo as suggested during the code review and it has > been merged in a separate branch [1]. AFAIR we discussed that Vidura could > continue making the fixes as suggested in the review and send the PR to the > branch. Once it is in a done done state, we can move it to the master > branch (this is because once a PR is merged to master branch it will be > released since CI/CD is configured). > > @Imesh: +1 if we can preseve the commits from the kernel and move it to > Carbon-secvault. (if we need to merge the PR then we can merge it in a > separate branch. Currently the PR to kernel is sent to the master branch) > > @Vidura: If the commits can be preserved then please coordinate with > Lakshman. > > >> Thanks, >> Lakshman. >> >>> >>>- Then move above folder to [2] using a PR-X >>>- Once the PR-X is merged, apply your changes on top of it. >>> >>> [1] https://github.com/wso2/carbon-kernel/pull/1266 >>> [2] https://github.com/wso2/carbon-secvault >>> >>> Thanks >>> >>> On Mon, Mar 6, 2017 at 12:15 PM, Niranjan Karunanandham < >>> niran...@wso2.com> wrote: >>> >>>> Hi Vidura, >>>> >>>> On Mon, Mar 6, 2017 at 11:52 AM, Imesh Gunaratne <im...@wso2.com> >>>> wrote: >>>> >>>>> On Fri, Mar 3, 2017 at 12:00 PM, Thusitha Thilina Dayaratne < >>>>> thusit...@wso2.com> wrote: >>>>> >>>>>> Rather than having a separate repo for utils I'll look into the >>>>>> possibility of moving that to a separate component (same level as core) >>>>>> without having cyclic dependencies. If that is possible then we can pack >>>>>> that as a new feature or core feature itself. Otherwise lets move that >>>>>> to a >>>>>> separate repo. >>>>>> >>>>>> Thusitha has done this change in the following PR: >>>>> https://github.com/wso2/carbon-kernel/pull/1318 >>>>> >>>> Once this PR is merged, we need to add the support to provide an API >>>> which can return the current config folder for a particular runtime. >>>> >>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> *Imesh Gunaratne* >>>>> Software Architect >>>>> WSO2 Inc: http://wso2.com >>>>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>>>> W: https://medium.com/@imesh TW: @imesh >>>>> lean. enterprise. middleware >>>>> >>>>> >>>> Regards, >>>> Nira >>>> >>>> --
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi Imesh, *I think it would be better if we can first move the secure vault code from carbon-kernel repository to the new repository with commit history and then apply the changes you have done. Otherwise, we will loose all history.* +1. We should move the secure vault out of carbon kernel preserving the commit history On Fri, Mar 10, 2017 at 3:54 PM, Imesh Gunaratne <im...@wso2.com> wrote: > Hi Vidura, > > I think it would be better if we can first move the secure vault code from > carbon-kernel repository to the new repository with commit history and then > apply the changes you have done. Otherwise, we will loose all history. > > I had a chat with Lakshman on this and it seems like he has extracted all > secure-vault related code into a new component and sent a PR [1] but it has > not been merged. > > IMO we would need to do following: > >- First, fix conflicts and merge [1]. This would bring all secure >vault related code to a new component/folder. >- Then move above folder to [2] using a PR-X >- Once the PR-X is merged, apply your changes on top of it. > > [1] https://github.com/wso2/carbon-kernel/pull/1266 > [2] https://github.com/wso2/carbon-secvault > > Thanks > > On Mon, Mar 6, 2017 at 12:15 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Vidura, >> >> On Mon, Mar 6, 2017 at 11:52 AM, Imesh Gunaratne <im...@wso2.com> wrote: >> >>> On Fri, Mar 3, 2017 at 12:00 PM, Thusitha Thilina Dayaratne < >>> thusit...@wso2.com> wrote: >>> >>>> Rather than having a separate repo for utils I'll look into the >>>> possibility of moving that to a separate component (same level as core) >>>> without having cyclic dependencies. If that is possible then we can pack >>>> that as a new feature or core feature itself. Otherwise lets move that to a >>>> separate repo. >>>> >>>> Thusitha has done this change in the following PR: >>> https://github.com/wso2/carbon-kernel/pull/1318 >>> >> Once this PR is merged, we need to add the support to provide an API >> which can return the current config folder for a particular runtime. >> >> >>> >>> >>> Thanks >>> >>> -- >>> *Imesh Gunaratne* >>> Software Architect >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>> W: https://medium.com/@imesh TW: @imesh >>> lean. enterprise. middleware >>> >>> >> Regards, >> Nira >> >> -- >> >> >> *Niranjan Karunanandham* >> Associate Technical Lead - WSO2 Inc. >> WSO2 Inc.: http://www.wso2.com >> >> > > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi Niranjan, Thanks for pointing this out. +1 for having importFeatureDef to Carbon-secvault in the carbon config feature. On Fri, Mar 3, 2017 at 10:16 AM, Niranjan Karunanandham <niran...@wso2.com> wrote: > Hi Vidura, > > On Thu, Mar 2, 2017 at 6:35 PM, Vidura Nanayakkara <vidu...@wso2.com> > wrote: > >> Hi, >> >> I am in the process of moving Carbon Configuration and Secure Vault from >> Carbon Kernel [7] <https://github.com/wso2/carbon-config> repository. >> Both these components will support OSGi mode as well as non-OSGi mode. >> Following >> are the reasons behind moving these into new repositories. >> >> Reasons for moving carbon configuration to a new repo: >> >>- The package is intended to provide configuration support for both >>OSGi and non-OSGi components and is to be used by MSF4J (OSGI and >>standalone mode), DAS etc. Therefore "org.wso2.carbon.configuration" >>should be a separate independent module (not inheriting the carbon >> kernel's >>parent pom) >>- Having the package within carbon kernel could lead into problems as >>having to release carbon kernel each time a change is made to >>"org.wso2.carbon.configuration" >> >> Reasons for moving carbon sec-vault to a new repo: >> >>- Carbon secure vault is to be used by the Carbon Kernal. However, >>the secure vault is provided via the carbon configuration module. >> Therefore >>we decided that it would be best if secure vault is released as a separate >>repository while carbon configuration module having a tight dependency to >>the secure vault (Since as for the above point, we have to make >>"org.wso2.carbon.configuration" a separate repository) >>- If we merge secure vault configuration with deployement.yaml and if >>there are cipher texts in deployment YAML, secure vault component has to >>depend on config component because secure vault configs reside in >>deployment YAML and config component has to depend on secure vault since >> we >>need to unciper the cipperd values in deployment YAML, that leads to >> cyclic >>dependency. >> >> According to the new structure, >> >> Carbon configuration will be in repo [5] >> <https://github.com/wso2/carbon-config> and Carbon Secure Vault will be >> in repo [6] <https://github.com/wso2/carbon-secvault>. This change will >> not have any major impact on any of the current implementations. The only >> change you have to make is to use the new maven dependencies and import any >> class used from the right package. New maven dependency information >> would be as follows for the components: >> >> *Carbon configuration* >> >> >> org.wso2.carbon >> org.wso2.carbon.configuration >> 1.0.0-SNAPSHOT >> >> >> *Carbon Secure Vault* >> >> >> org.wso2.carbon >> org.wso2.carbon.securevault >> 1.0.0-SNAPSHOT >> >> >> Both Carbon configuration and Carbon Secure Vault will have carbon >> features implemented that will be installed in the Carbon Kernel. New >> maven dependency information for the features of the above will be as >> follows: >> >> *Carbon configuration Feature* >> >> >> org.wso2.carbon >> org.wso2.carbon.configuration.feature >> 1.0.0-SNAPSHOT >> >> >> *Carbon Secure Vault Feature* >> >> >> org.wso2.carbon >> org.wso2.carbon.securevault.feature >> 1.0.0-SNAPSHOT >> >> >> Furthermore, maven configuration plugin [4] will be also moved to the >> Carbon Config [5] <https://github.com/wso2/carbon-config> repo. Carbon >> configuration maven plugin dependency information would be as mentioned >> below: >> >> >> org.wso2.carbon >> org.wso2.carbon.configuration.maven.plugin >> 1.0.0-SNAPSHOT >> >> >> IMO in the carbon-config feature, we need to have an importFeatureDef to > Carbon-secvault since it requires secure vault feature. Therefore from the > carbon-kernel and other products needs to only install carbon-config > feature which will inturn bring in the Secure vault feature. > > > >> [1] Carbon Kernel Issue >> <https://github.com/wso2/carbon-kernel/issues/1312> >> [2] Carbon Sec-Vault Issue >> <https://github.com/wso2/carbon-secvault/issues/2> >> [3] Carbon Config Issue <https://github.com/wso2/carbon-config/issues/1> >> [4] [Architec
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi all, Myself, Lakshman and Kishanthan had a discussion related to the above matter and came to a conclusion that we need to have a separate repo for kernel-utils. Moving kernel utilities out of carbon kernel was previously discussed in order to provide Balerina and MSF4J standalone mode with the kernel utilities rather than having a dependency to the carbon core. We can use this kernel-utils repo to get the secure vault YAML configuration from the runtime. This way Carbon Secure Vault will have a dependency to the kernel-utils rather than having a dependency to the Carbon Core. WDYT? On Thu, Mar 2, 2017 at 6:43 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi all, > > Considering the Carbon Secure Vault's OSGi and Non-OSGi implementations we > are planning to: > >- Get the secure vault YAML configuration from the runtime in the OSGi >mode: This is because we can have multiple runtimes and each runtime can >have different configurations. >- Get the secure vault YAML configuration from system property (1st >priority) or classpath (2nd priority) in the non-OSGi mode >- Delegate providing other file paths (secret.properties, >master-key.yaml) to relevant implementation classes because other file >paths (secret.properties, master-key.yaml) are bound to the relevant >implementation. > > Considering the Carbon Secure Vault's OSGi implementation, I don't > currently have a way to get the secure vault YAML configuration from the > runtime (we cannot have carbon kernel as a dependency to carbon secvault > [6] since carbon configuration [5] will be dependent on carbon secvault [6] > and carbon kernel [7] will depend on carbon configuration [5] (this will > result in a cyclic dependency)). > > Therefore your input regarding how to get the secure vault YAML from > runtime in OSGi mode is appreciated. > > On Thu, Mar 2, 2017 at 6:35 PM, Vidura Nanayakkara <vidu...@wso2.com> > wrote: > >> Hi, >> >> I am in the process of moving Carbon Configuration and Secure Vault from >> Carbon Kernel [7] <https://github.com/wso2/carbon-config> repository. >> Both these components will support OSGi mode as well as non-OSGi mode. >> Following >> are the reasons behind moving these into new repositories. >> >> Reasons for moving carbon configuration to a new repo: >> >>- The package is intended to provide configuration support for both >>OSGi and non-OSGi components and is to be used by MSF4J (OSGI and >>standalone mode), DAS etc. Therefore "org.wso2.carbon.configuration" >>should be a separate independent module (not inheriting the carbon >> kernel's >>parent pom) >>- Having the package within carbon kernel could lead into problems as >>having to release carbon kernel each time a change is made to >>"org.wso2.carbon.configuration" >> >> Reasons for moving carbon sec-vault to a new repo: >> >>- Carbon secure vault is to be used by the Carbon Kernal. However, >>the secure vault is provided via the carbon configuration module. >> Therefore >>we decided that it would be best if secure vault is released as a separate >>repository while carbon configuration module having a tight dependency to >>the secure vault (Since as for the above point, we have to make >>"org.wso2.carbon.configuration" a separate repository) >>- If we merge secure vault configuration with deployement.yaml and if >>there are cipher texts in deployment YAML, secure vault component has to >>depend on config component because secure vault configs reside in >>deployment YAML and config component has to depend on secure vault since >> we >>need to unciper the cipperd values in deployment YAML, that leads to >> cyclic >>dependency. >> >> According to the new structure, >> >> Carbon configuration will be in repo [5] >> <https://github.com/wso2/carbon-config> and Carbon Secure Vault will be >> in repo [6] <https://github.com/wso2/carbon-secvault>. This change will >> not have any major impact on any of the current implementations. The only >> change you have to make is to use the new maven dependencies and import any >> class used from the right package. New maven dependency information >> would be as follows for the components: >> >> *Carbon configuration* >> >> >> org.wso2.carbon >> org.wso2.carbon.configuration >> 1.0.0-SNAPSHOT >> >> >> *Carbon Secure Vault* >> >> >> org.wso2.carbon >> org.wso2.carbon.securevault >&g
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi all, Considering the Carbon Secure Vault's OSGi and Non-OSGi implementations we are planning to: - Get the secure vault YAML configuration from the runtime in the OSGi mode: This is because we can have multiple runtimes and each runtime can have different configurations. - Get the secure vault YAML configuration from system property (1st priority) or classpath (2nd priority) in the non-OSGi mode - Delegate providing other file paths (secret.properties, master-key.yaml) to relevant implementation classes because other file paths (secret.properties, master-key.yaml) are bound to the relevant implementation. Considering the Carbon Secure Vault's OSGi implementation, I don't currently have a way to get the secure vault YAML configuration from the runtime (we cannot have carbon kernel as a dependency to carbon secvault [6] since carbon configuration [5] will be dependent on carbon secvault [6] and carbon kernel [7] will depend on carbon configuration [5] (this will result in a cyclic dependency)). Therefore your input regarding how to get the secure vault YAML from runtime in OSGi mode is appreciated. On Thu, Mar 2, 2017 at 6:35 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi, > > I am in the process of moving Carbon Configuration and Secure Vault from > Carbon Kernel [7] <https://github.com/wso2/carbon-config> repository. > Both these components will support OSGi mode as well as non-OSGi mode. > Following > are the reasons behind moving these into new repositories. > > Reasons for moving carbon configuration to a new repo: > >- The package is intended to provide configuration support for both >OSGi and non-OSGi components and is to be used by MSF4J (OSGI and >standalone mode), DAS etc. Therefore "org.wso2.carbon.configuration" >should be a separate independent module (not inheriting the carbon kernel's >parent pom) >- Having the package within carbon kernel could lead into problems as >having to release carbon kernel each time a change is made to >"org.wso2.carbon.configuration" > > Reasons for moving carbon sec-vault to a new repo: > >- Carbon secure vault is to be used by the Carbon Kernal. However, the >secure vault is provided via the carbon configuration module. Therefore we >decided that it would be best if secure vault is released as a separate >repository while carbon configuration module having a tight dependency to >the secure vault (Since as for the above point, we have to make >"org.wso2.carbon.configuration" a separate repository) >- If we merge secure vault configuration with deployement.yaml and if >there are cipher texts in deployment YAML, secure vault component has to >depend on config component because secure vault configs reside in >deployment YAML and config component has to depend on secure vault since we >need to unciper the cipperd values in deployment YAML, that leads to cyclic >dependency. > > According to the new structure, > > Carbon configuration will be in repo [5] > <https://github.com/wso2/carbon-config> and Carbon Secure Vault will be > in repo [6] <https://github.com/wso2/carbon-secvault>. This change will > not have any major impact on any of the current implementations. The only > change you have to make is to use the new maven dependencies and import any > class used from the right package. New maven dependency information would > be as follows for the components: > > *Carbon configuration* > > > org.wso2.carbon > org.wso2.carbon.configuration > 1.0.0-SNAPSHOT > > > *Carbon Secure Vault* > > > org.wso2.carbon > org.wso2.carbon.securevault > 1.0.0-SNAPSHOT > > > Both Carbon configuration and Carbon Secure Vault will have carbon > features implemented that will be installed in the Carbon Kernel. New > maven dependency information for the features of the above will be as > follows: > > *Carbon configuration Feature* > > > org.wso2.carbon > org.wso2.carbon.configuration.feature > 1.0.0-SNAPSHOT > > > *Carbon Secure Vault Feature* > > > org.wso2.carbon > org.wso2.carbon.securevault.feature > 1.0.0-SNAPSHOT > > > Furthermore, maven configuration plugin [4] will be also moved to the > Carbon Config [5] <https://github.com/wso2/carbon-config> repo. Carbon > configuration maven plugin dependency information would be as mentioned > below: > > > org.wso2.carbon > org.wso2.carbon.configuration.maven.plugin > 1.0.0-SNAPSHOT > > > [1] Carbon Kernel Issue > <https://github.com/wso2/carbon-kernel/issues/1312> > [2] Carbon Sec-Vault Issue > <
[Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi, I am in the process of moving Carbon Configuration and Secure Vault from Carbon Kernel [7] <https://github.com/wso2/carbon-config> repository. Both these components will support OSGi mode as well as non-OSGi mode. Following are the reasons behind moving these into new repositories. Reasons for moving carbon configuration to a new repo: - The package is intended to provide configuration support for both OSGi and non-OSGi components and is to be used by MSF4J (OSGI and standalone mode), DAS etc. Therefore "org.wso2.carbon.configuration" should be a separate independent module (not inheriting the carbon kernel's parent pom) - Having the package within carbon kernel could lead into problems as having to release carbon kernel each time a change is made to "org.wso2.carbon.configuration" Reasons for moving carbon sec-vault to a new repo: - Carbon secure vault is to be used by the Carbon Kernal. However, the secure vault is provided via the carbon configuration module. Therefore we decided that it would be best if secure vault is released as a separate repository while carbon configuration module having a tight dependency to the secure vault (Since as for the above point, we have to make "org.wso2.carbon.configuration" a separate repository) - If we merge secure vault configuration with deployement.yaml and if there are cipher texts in deployment YAML, secure vault component has to depend on config component because secure vault configs reside in deployment YAML and config component has to depend on secure vault since we need to unciper the cipperd values in deployment YAML, that leads to cyclic dependency. According to the new structure, Carbon configuration will be in repo [5] <https://github.com/wso2/carbon-config> and Carbon Secure Vault will be in repo [6] <https://github.com/wso2/carbon-secvault>. This change will not have any major impact on any of the current implementations. The only change you have to make is to use the new maven dependencies and import any class used from the right package. New maven dependency information would be as follows for the components: *Carbon configuration* org.wso2.carbon org.wso2.carbon.configuration 1.0.0-SNAPSHOT *Carbon Secure Vault* org.wso2.carbon org.wso2.carbon.securevault 1.0.0-SNAPSHOT Both Carbon configuration and Carbon Secure Vault will have carbon features implemented that will be installed in the Carbon Kernel. New maven dependency information for the features of the above will be as follows: *Carbon configuration Feature* org.wso2.carbon org.wso2.carbon.configuration.feature 1.0.0-SNAPSHOT *Carbon Secure Vault Feature* org.wso2.carbon org.wso2.carbon.securevault.feature 1.0.0-SNAPSHOT Furthermore, maven configuration plugin [4] will be also moved to the Carbon Config [5] <https://github.com/wso2/carbon-config> repo. Carbon configuration maven plugin dependency information would be as mentioned below: org.wso2.carbon org.wso2.carbon.configuration.maven.plugin 1.0.0-SNAPSHOT [1] Carbon Kernel Issue <https://github.com/wso2/carbon-kernel/issues/1312> [2] Carbon Sec-Vault Issue <https://github.com/wso2/carbon-secvault/issues/2> [3] Carbon Config Issue <https://github.com/wso2/carbon-config/issues/1> [4] [Architecture] Carbon C5 - Server Configuration Model [5] Carbon configuration repo <https://github.com/wso2/carbon-config> [6] Carbon Secvault Repo <https://github.com/wso2/carbon-secvault> [7] Carbon Kernel Repo <https://github.com/wso2/carbon-kernel> Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Retrieving Rating value of API in the GET_API resource API
Hi Chamalee,
The response in [1]
<http://softwareengineering.stackexchange.com/questions/305872/many-asynchronous-calls-vs-single-call-to-the-api>
suggests
option 1 in general. It explains few good points that are worth looking at.
Furthermore, in addition to Chamin's response, getAPI call looks to me is
common HTTP call in the application. Therefore we do not need to include
additional information in the response. (You only need to proceed with
option 2 if you need to always get the API rating along with the API (a
single request is much more scalable than multiple requests in this case))
So IMO we should proceed with option 1
[1] Many asynchronous calls vs single call to the API
<http://softwareengineering.stackexchange.com/questions/305872/many-asynchronous-calls-vs-single-call-to-the-api>
On Wed, Mar 1, 2017 at 6:09 PM, Malintha Amarasinghe <malint...@wso2.com>
wrote:
>
>
> On Wed, Mar 1, 2017 at 1:45 PM, Chamalee De Silva <chama...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> I am working on adding REST APIs for the following operations.
>>
>> 1. Rate an API (add rating)
>> 2. Get rating of an API (given the UUID of the API)
>>
>>
>> A separate table is going to be added to store for API_RATINGS like what
>> we had in APIM 2.1.0
>> where it has 1:m mapping with AM_API table.
>>
>> AM_API_RATINGS
>>
>> ID
>>
>> API_ID
>>
>> SUBSCRIBER_ID
>>
>> RATING
>>
>>
>>
>>
>>
>> In current implementation or in the previous version of the API there is
>> no implementation to get the API rating when retrieving the API in Store
>> REST API.
>>
>> We need to get the rating of the API at the same time we do the GET_API
>> call when thinking of the UI perspective to display the API in Store.
>>
>> So there are two options available to get the rating of the API.
>>
>>
>> *Option 1 : *
>> Do the *getAPIRating *call (/apis/{apiId}/rating) right after the getAPI
>> call.
>>
>> If we do this there will be t*wo REST calls* one after the
>> other. But the query execution will be less expensive and less complex.
>>
> +1. Better to keep this outside of the API since this is not really a part
> of the API resource. Adding to Chamin's and Harsha's comments; If we make
> this as part of the API resource, we will always have to change the ETag of
> the API once a user changes the rating of the API (which can happen
> frequently compared to a change that happens to the actual API). This is an
> unnecessary change that would affect client side caching. I think we need
> to be bit careful about this when doing changes to any exising resource in
> general.
>
> Thanks!
> Malintha
>
>>
>>
>>
>>
>> *Option 2 : *
>> Get the rating value of the particular API inside the same
>> query for get_API , add it to the API object as a property and retrieve
>> the rating with *getAPI* call.
>>
>> This will reduce it to one REST call to the server, but in
>> DB level, we are doing a bit complex query
>>
>> e.g. Then the getAPI query will be like this with an inner
>> join operation.
>>
>> *select *
>> *a.id <http://a.id>, a.name
>> <http://a.name>, a.context, . , avg(r.rating)*
>> *from*
>>* AM_API a*
>> * inner join*
>>* AM_RATING r ON a.ID = r.api_id*
>>* GROUP BY a.name <http://a.name>,
>> a.context, ..., ,..,..,*
>>* WHERE a.id <http://a.id> = ? ;*
>>
>> * Option 3 : *
>>
>> To reduce the complexity of the query described in option 2, we
>> can do execute two queries on the database.
>>
>> - First one to get the API from the AM_API table
>> - Second query to get the average rating of that particular
>> API.
>>
>> Then after adding the rating value as a property of the API
>> object and retrieve with the *getAPI* call.
>>
>>
>>
>>
>> From these two options what is the best way to implement ?
>>
>> Assume if we select option 3, then, should we still have option 1 to be
>> used independently ?
>>
>> Appreciate your feedback on this.
>>
>>
>>
>> Thanks
>> Chamalee
>>
>>
>>
>>
>>
&g
Re: [Architecture] [C5, MSF4J] Carbon C5 - Server Configuration Model
Hi all,
Considering the same example as stated above,
@Element(description = "Listener configurations") private
List listenerConfigurations = Arrays.asList(new
HttpListenerConfiguration(), new HttpsListenerConfiguration());
What should be the case when `ListenerConfiguration` class do not have the
`@Configuration` annotation?
Should a warning or an exception be thrown when preparing the configuration
file?
On Wed, Feb 22, 2017 at 11:16 AM, Vidura Nanayakkara <vidu...@wso2.com>
wrote:
>
> Hi all,
>
> There are few points that are needed to be clarified in this email.
>
> First of all having
>
> @Element(description = "Listener configurations") private
> List listenerConfigurations = Arrays.asList(new
> HttpListenerConfiguration(), new HttpsListenerConfiguration());
>
> Will produce the below configuration
>
> listenerConfiguration:
> -{}
> -{}
>
> assuming that *ListenerConfiguration* class has the *@Configuration*
> annotation present. So the intended behaviour stated in "[Architecture]
> Carbon C5 - Server Configuration Model" architecture mail thread is not
> working as intended and needs to be fixed.
>
> So the actual point that needs to be clarified is whether to consider the
> reference type or the instance type when preparing the configuration file.
>
> As mentioned by Danesh and Imesh and as per offline discussion with
> Kishanthan we will be looking at the reference type when preparing the
> configuration.
>
> Thanks,
> Vidura Nanayakkara
>
> On Tue, Feb 21, 2017 at 9:08 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>>
>>
>> On Tue, Feb 21, 2017 at 6:33 PM, Vidura Nanayakkara <vidu...@wso2.com>
>> wrote:
>>
>>>
>>> In order to create the above configuration, I may write any of the
>>> below-mentioned code segments.
>>>
>>> 1)
>>>
>>> @Element(description = "Listener configurations")
>>> private List listenerConfigurations =
>>> Arrays.asList(new HttpListenerConfiguration(), new
>>> HttpsListenerConfiguration());
>>>
>>>
>>> Since the plugin only looks at the argument type I will not be able to
>>> have the above-mentioned configuration (Plugin will check for annotations
>>> inside the "Configuration" class and therefore only the elements in the
>>> "Configuration" class will be written to the configuration file)
>>>
>>> Shouldn't that be the intended behaviour?
>>
>> In the above sample, if *listenerConfigurations* is a repeatable element
>> in a configuration file, it might need to have the same set of properties
>> in all the rows. Which means when* @Element *annotation is added to a
>> private variable the mapping between the configuration file and the domain
>> model might need to use the data type of the above variable instead of the
>> data type of the assigned value(s). WDYT?
>>
>> Thanks
>>
>>
>>> 2)
>>>
>>> @Element(description = "Listener configurations")
>>> private List listenerConfigurations =
>>> Arrays.asList(new HttpListenerConfiguration(), new
>>> HttpsListenerConfiguration());
>>>
>>> Since the plugin only looks at the argument type I will not be able to
>>> have the above-mentioned configuration (Plugin will check for annotations
>>> inside the "Object" class). Furthermore since "Object" class doesn't have
>>> any annotation, I will not have any of the configuration elements at all.
>>>
>>> 3)
>>>
>>> @Element(description = "Listener configurations")
>>> private List listenerConfigurations =
>>> Arrays.asList(new HttpListenerConfiguration(), new
>>> HttpsListenerConfiguration());
>>>
>>>
>>> This will throw an exception since the argument type is not stated
>>> within the angle brackets (should take as Object by default right?)
>>>
>>> *Suggestion*
>>>
>>>- Consider the instance rather than the reference type when creating
>>>the configuration file to solve the above problems.
>>>- Iterate through inherited classes when creating the configuration
>>>file. This way we can avoid duplicating the same code in multiple places
>>>and help solve the problem stated in (1)
>>>
>>>
>>> WDYT?
>>>
>>> [1] carbon-kernel issue 1285
>>> <https://github.com/wso2/carbon-kernel/issues/1285>
>>>
>>> Bes
Re: [Architecture] [C5, MSF4J] Carbon C5 - Server Configuration Model
Hi all,
There are few points that are needed to be clarified in this email.
First of all having
@Element(description = "Listener configurations") private
List listenerConfigurations = Arrays.asList(new
HttpListenerConfiguration(), new HttpsListenerConfiguration());
Will produce the below configuration
listenerConfiguration:
-{}
-{}
assuming that *ListenerConfiguration* class has the *@Configuration*
annotation present. So the intended behaviour stated in "[Architecture]
Carbon C5 - Server Configuration Model" architecture mail thread is not
working as intended and needs to be fixed.
So the actual point that needs to be clarified is whether to consider the
reference type or the instance type when preparing the configuration file.
As mentioned by Danesh and Imesh and as per offline discussion with
Kishanthan we will be looking at the reference type when preparing the
configuration.
Thanks,
Vidura Nanayakkara
On Tue, Feb 21, 2017 at 9:08 PM, Imesh Gunaratne <im...@wso2.com> wrote:
>
>
> On Tue, Feb 21, 2017 at 6:33 PM, Vidura Nanayakkara <vidu...@wso2.com>
> wrote:
>
>>
>> In order to create the above configuration, I may write any of the
>> below-mentioned code segments.
>>
>> 1)
>>
>> @Element(description = "Listener configurations")
>> private List listenerConfigurations =
>> Arrays.asList(new HttpListenerConfiguration(), new
>> HttpsListenerConfiguration());
>>
>>
>> Since the plugin only looks at the argument type I will not be able to
>> have the above-mentioned configuration (Plugin will check for annotations
>> inside the "Configuration" class and therefore only the elements in the
>> "Configuration" class will be written to the configuration file)
>>
>> Shouldn't that be the intended behaviour?
>
> In the above sample, if *listenerConfigurations* is a repeatable element
> in a configuration file, it might need to have the same set of properties
> in all the rows. Which means when* @Element *annotation is added to a
> private variable the mapping between the configuration file and the domain
> model might need to use the data type of the above variable instead of the
> data type of the assigned value(s). WDYT?
>
> Thanks
>
>
>> 2)
>>
>> @Element(description = "Listener configurations")
>> private List listenerConfigurations =
>> Arrays.asList(new HttpListenerConfiguration(), new
>> HttpsListenerConfiguration());
>>
>> Since the plugin only looks at the argument type I will not be able to
>> have the above-mentioned configuration (Plugin will check for annotations
>> inside the "Object" class). Furthermore since "Object" class doesn't have
>> any annotation, I will not have any of the configuration elements at all.
>>
>> 3)
>>
>> @Element(description = "Listener configurations")
>> private List listenerConfigurations =
>> Arrays.asList(new HttpListenerConfiguration(), new
>> HttpsListenerConfiguration());
>>
>>
>> This will throw an exception since the argument type is not stated within
>> the angle brackets (should take as Object by default right?)
>>
>> *Suggestion*
>>
>>- Consider the instance rather than the reference type when creating
>>the configuration file to solve the above problems.
>>- Iterate through inherited classes when creating the configuration
>>file. This way we can avoid duplicating the same code in multiple places
>>and help solve the problem stated in (1)
>>
>>
>> WDYT?
>>
>> [1] carbon-kernel issue 1285
>> <https://github.com/wso2/carbon-kernel/issues/1285>
>>
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : vidu...@wso2.com
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran <http://wso2.com/>
>> Twitter : http://twitter.com/viduranana
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> <http://wso2.com/>
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
--
Best Regards,
*Vidura Nanayakkara*
Software Engineer
Email : vidu...@wso2.com
Mobile : +94 (0) 717 919277
Web : http://wso2.com
Blog : https://medium.com/@viduran <http://wso2.com/>
Twitter : http://twitter.com/viduranana
LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5, MSF4J] Carbon C5 - Server Configuration Model
[Adding Danesh] On Tue, Feb 21, 2017 at 6:33 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi all, > > *Note:* This email is in reference to the "[Architecture] Carbon C5 - Se > rver Configuration Model" previously sent to the Architecture mail thread. > > I am currently working on moving the > >1. C5 server configuration model out of the carbon.core [1] ><https://github.com/wso2/carbon-kernel/issues/1285> and creating a >separate component which will support both OSGi and standalone mode. >2. Using the C5 server configuration model to configure the executor >pool in MSF4J > > However, there is an issue that needs to be addressed in relation to the > C5 configuration model and is as stated below: > > Maven configuration plugin currently looks at the class template to > process configurations. However, this has certain limitations considering > the below example. > > Let's say for instance that I want to have the following configuration > segment created. > > listenerConfigurations: > - > id: "msf4j-http" > host: "127.0.0.1" > port: 8080 > - > id: "jaxrs-http" > host: "0.0.0.0" > port: 8094 > scheme: https > keyStoreFile: "src/test/resources/cert.jks" > keyStorePass: secret > certPass: secret > > > In order to create the above configuration, I may write any of the > below-mentioned code segments. > > 1) > > @Element(description = "Listener configurations") > private List listenerConfigurations = > Arrays.asList(new HttpListenerConfiguration(), new > HttpsListenerConfiguration()); > > > Since the plugin only looks at the argument type I will not be able to > have the above-mentioned configuration (Plugin will check for annotations > inside the "Configuration" class and therefore only the elements in the > "Configuration" class will be written to the configuration file) > > > 2) > > @Element(description = "Listener configurations") > private List listenerConfigurations = > Arrays.asList(new HttpListenerConfiguration(), new > HttpsListenerConfiguration()); > > Since the plugin only looks at the argument type I will not be able to > have the above-mentioned configuration (Plugin will check for annotations > inside the "Object" class). Furthermore since "Object" class doesn't have > any annotation, I will not have any of the configuration elements at all. > > 3) > > @Element(description = "Listener configurations") > private List listenerConfigurations = > Arrays.asList(new HttpListenerConfiguration(), new > HttpsListenerConfiguration()); > > > This will throw an exception since the argument type is not stated within > the angle brackets (should take as Object by default right?) > > *Suggestion* > >- Consider the instance rather than the reference type when creating >the configuration file to solve the above problems. >- Iterate through inherited classes when creating the configuration >file. This way we can avoid duplicating the same code in multiple places >and help solve the problem stated in (1) > > > WDYT? > > [1] carbon-kernel issue 1285 > <https://github.com/wso2/carbon-kernel/issues/1285> > > Best Regards, > > *Vidura Nanayakkara* > Software Engineer > > Email : vidu...@wso2.com > Mobile : +94 (0) 717 919277 <+94%2071%20791%209277> > Web : http://wso2.com > Blog : https://medium.com/@viduran <http://wso2.com/> > Twitter : http://twitter.com/viduranana > LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara > <http://wso2.com/> > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5, MSF4J] Carbon C5 - Server Configuration Model
Hi all, *Note:* This email is in reference to the "[Architecture] Carbon C5 - Server Configuration Model" previously sent to the Architecture mail thread. I am currently working on moving the 1. C5 server configuration model out of the carbon.core [1] <https://github.com/wso2/carbon-kernel/issues/1285> and creating a separate component which will support both OSGi and standalone mode. 2. Using the C5 server configuration model to configure the executor pool in MSF4J However, there is an issue that needs to be addressed in relation to the C5 configuration model and is as stated below: Maven configuration plugin currently looks at the class template to process configurations. However, this has certain limitations considering the below example. Let's say for instance that I want to have the following configuration segment created. listenerConfigurations: - id: "msf4j-http" host: "127.0.0.1" port: 8080 - id: "jaxrs-http" host: "0.0.0.0" port: 8094 scheme: https keyStoreFile: "src/test/resources/cert.jks" keyStorePass: secret certPass: secret In order to create the above configuration, I may write any of the below-mentioned code segments. 1) @Element(description = "Listener configurations") private List listenerConfigurations = Arrays.asList(new HttpListenerConfiguration(), new HttpsListenerConfiguration()); Since the plugin only looks at the argument type I will not be able to have the above-mentioned configuration (Plugin will check for annotations inside the "Configuration" class and therefore only the elements in the "Configuration" class will be written to the configuration file) 2) @Element(description = "Listener configurations") private List listenerConfigurations = Arrays.asList(new HttpListenerConfiguration(), new HttpsListenerConfiguration()); Since the plugin only looks at the argument type I will not be able to have the above-mentioned configuration (Plugin will check for annotations inside the "Object" class). Furthermore since "Object" class doesn't have any annotation, I will not have any of the configuration elements at all. 3) @Element(description = "Listener configurations") private List listenerConfigurations = Arrays.asList(new HttpListenerConfiguration(), new HttpsListenerConfiguration()); This will throw an exception since the argument type is not stated within the angle brackets (should take as Object by default right?) *Suggestion* - Consider the instance rather than the reference type when creating the configuration file to solve the above problems. - Iterate through inherited classes when creating the configuration file. This way we can avoid duplicating the same code in multiple places and help solve the problem stated in (1) WDYT? [1] carbon-kernel issue 1285 <https://github.com/wso2/carbon-kernel/issues/1285> Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MSF4J] MSF4J Filter Configuration
rs using the > RequestContext objects > > Thanks > Thusitha > > On Fri, Jan 6, 2017 at 12:35 PM, Bhathiya Jayasekara <bhath...@wso2.com> > wrote: > >> Hi Vidura, >> >> Can we use ContainerRequestContext and ContainerResponseContext to pass >> data among filters? And can we use them to access such data at service >> level as well? >> >> Thanks, >> Bhathiya >> >> On Thu, Jan 5, 2017 at 3:19 PM, Vidura Nanayakkara <vidu...@wso2.com> >> wrote: >> >>> Hi, >>> >>> As per the discussions in the "[Dev] [C5] MSF4J Interceptors need to be >>> configurable" email thread, we have started working on the MSF4J filters. >>> >>> Mentioned below is a brief explanation of how things will look like >>> according to what we have planned so far. >>> >>> *Ability to filter request / response messages * >>> >>> We will be adapting JAX-RS defined interfaces (ContainerRequestFilter, >>> ContainerResponseFilter) for request and response filtering. For handling >>> the request and the response we are hoping to use JAX-RS defined interfaces >>> (ContainerRequestContext and ContainerResponseContext) >>> >>> *Ability to apply/skip filters in global and pre-service levels* >>> >>> Filters could be applied globally, resource or sub-resource vice which >>> implies that when a sub-resource is executed filters applied to the >>> sub-resource, resource and filters applied globally should execute >>> according to the relevant priority (Union set of filters). >>> >>> However, we are not adopting the Annotation driven NameBinding concept >>> defined for JAX-RS Filters but would be adopting a similar concept to >>> reduce the developer effort in writing annotations to the filters. Using >>> this approach we would still be using annotations to define filters in >>> resource and sub-resource levels. >>> >>> Ex:- Applying filters in the resource and sub-resource levels can be >>> done by using the below-mentioned annotations >>> >>> >>> @FilterRequest(filterclass=MyClass.class, priority=1000) >>> @FilterRequest(filterclass=MyClass2.class, priority=2000) >>> @FilterRequest(filterclass=MyClass3.class) >>> // Some method or class >>> >>> @FilterResponse(filterclass=MyClass4.class, priority=1000) >>> @FilterResponse(filterclass=MyClass5.class, priority=2000) >>> @FilterResponse(filterclass=MyClass6.class) >>> // Some method or class >>> >>> >>> By default, filters will be applied globally. >>> >>> *The order of the filters* >>> >>> Priorities for the JAXRSInInterceptors are in ascending order while >>> priorities for the JAXRSOutInterceptors are in descending order. This >>> will feature in proper execution when both ContainerRequestFilter and >>> ContainerResponseFilter >>> interfaces are implemented. >>> >>> Filters which do not have a priority specified will have a default >>> priority [1]. >>> >>> *How to register filters globally, to a resource or a sub-resource* >>> >>>- Using annotations as mentioned above >>>- In fat jar mode, filters can be registered using >>>addFilter(, ) method >>>- In OSGI mode, filters can be registered in the same way >>>interceptors are registered now >>> >>> [1] https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0- >>> 2rd-edition/content/en/part1/chapter12/ordering_filters_and_interceptors.html >>> >>> >>> Best Regards, >>> >>> *Vidura Nanayakkara* >>> Software Engineer >>> >>> Email : vidu...@wso2.com >>> Mobile : +94 (0) 717 919277 <071%20791%209277> >>> Web : http://wso2.com >>> Blog : https://medium.com/@viduran <http://wso2.com/> >>> Twitter : http://twitter.com/viduranana >>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara >>> <http://wso2.com/> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Bhathiya Jayasekara* >> *Senior Software Engineer,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185 <+94%2071%20547%208185>* >> *LinkedIn: http:
[Architecture] [MSF4J] MSF4J Filter Configuration
Hi, As per the discussions in the "[Dev] [C5] MSF4J Interceptors need to be configurable" email thread, we have started working on the MSF4J filters. Mentioned below is a brief explanation of how things will look like according to what we have planned so far. *Ability to filter request / response messages * We will be adapting JAX-RS defined interfaces (ContainerRequestFilter, ContainerResponseFilter) for request and response filtering. For handling the request and the response we are hoping to use JAX-RS defined interfaces (ContainerRequestContext and ContainerResponseContext) *Ability to apply/skip filters in global and pre-service levels* Filters could be applied globally, resource or sub-resource vice which implies that when a sub-resource is executed filters applied to the sub-resource, resource and filters applied globally should execute according to the relevant priority (Union set of filters). However, we are not adopting the Annotation driven NameBinding concept defined for JAX-RS Filters but would be adopting a similar concept to reduce the developer effort in writing annotations to the filters. Using this approach we would still be using annotations to define filters in resource and sub-resource levels. Ex:- Applying filters in the resource and sub-resource levels can be done by using the below-mentioned annotations @FilterRequest(filterclass=MyClass.class, priority=1000) @FilterRequest(filterclass=MyClass2.class, priority=2000) @FilterRequest(filterclass=MyClass3.class) // Some method or class @FilterResponse(filterclass=MyClass4.class, priority=1000) @FilterResponse(filterclass=MyClass5.class, priority=2000) @FilterResponse(filterclass=MyClass6.class) // Some method or class By default, filters will be applied globally. *The order of the filters* Priorities for the JAXRSInInterceptors are in ascending order while priorities for the JAXRSOutInterceptors are in descending order. This will feature in proper execution when both ContainerRequestFilter and ContainerResponseFilter interfaces are implemented. Filters which do not have a priority specified will have a default priority [1]. *How to register filters globally, to a resource or a sub-resource* - Using annotations as mentioned above - In fat jar mode, filters can be registered using addFilter(, ) method - In OSGI mode, filters can be registered in the same way interceptors are registered now [1] https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-2rd-edition/content/en/part1/chapter12/ordering_filters_and_interceptors.html Best Regards, *Vidura Nanayakkara* Software Engineer Email : vidu...@wso2.com Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> Twitter : http://twitter.com/viduranana LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
