Re: [Architecture] [Dev] Account Lock/Disable Feature in IS 6.0.0
On Fri, Jan 20, 2017 at 4:43 PM, Prabath Siriwardena <prab...@wso2.com> wrote: > Hi Isura, > > Please find my comment inline... > > On Fri, Jan 20, 2017 at 2:02 AM, Isura Karunaratne <is...@wso2.com> wrote: > >> Hi all, >> >> >> We are working on implementing account lock/disable features for IS >> 6.0.0. >> >> *Account Lock: * >> >>- User *must not *be able to login to the system. >>- Admin user *can* update the user attributes and assign roles >>(account is active) >>- User cannot start a password recovery flow. >> >> > In summary the user cannot do any actions with the system - but the > Administrators can. > (We could have an option in user's UI to inform/contact admin once the account is locked?) > > >> *Account Disable: * >> >>- User *must not* be able to login to the system. >>- Admin user *can not* update the user attributes and cannot assign >>roles until enabling the account. (inactive state) >>- User cannot start a password recovery flow. >> >> Neither the user nor the Administrator can do any actions on this user. > Special case, the Administrator can enable the user account. > > >> >> >> *When will the account be locked?* >> >> >> >>- Self Signup users until account confirmation >> >> This is special status - and we need to identify this status different > from the account lock. A user in this status can request to resend the > confirmation code. > > Also one (an Administrator) should be able to setup a policy to wipe out > all the unconfirmed accounts after sometime. Also there can be cases we > still let unconfirmed users login to the system - but only a limited set of > functionality is allowed. > >> >>- Try to login with invalid credentials more than configured number >>of attempts. Then the account will be locked configured amount of time. >>(Like 5 minutes). This lock time will be increased if the user locked >> again >>based on a configuration. >>- Provide invalid answers more than configured number of attempts, >>when password recovery >>- User onboarding with Email/SMS verification flow. >> >> Applies the same comment here - for the self-signup > >> >>- When admin needs to block the user to login to the system (lock or >>disable?) >>- When admin initiated password reset flow starts. >>- Being logged into the system on many devices simultaneously? >> >> > We need to identify this states different from the account lock.. > >> >> >> *When will the account be disabled?* >> >> >> >> >> >>- When admin needs to inactivate user. >> >> > >> >> What is the best way handle account disable check? We can do this from a >> inceptor level, then we need to check account disable in each operation. >> >> Thanks >> Isura. >> >> >> >> >> >> *Isura Dilhara Karunaratne* >> Senior Software Engineer | WSO2 >> Email: is...@wso2.com >> Mob : +94 772 254 810 <+94%2077%20225%204810> >> Blog : http://isurad.blogspot.com/ >> >> >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 <(650)%20625-7950> > > http://facilelogin.com > > ___ > Dev mailing list > d...@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Implementation of c5 multitenancy
Few more suggestions to consider.. - Get all tenants : Don't we need to add limit/offset to support pagination? - Get a tenant by name : Response code 400 can be introduced if the name is invalid - Create new tenant: Response code 400 needed to notify the errors in payload. - Delete tenant: Response code 400 can be introduced if the name is invalid/ Can't we introduced 412 if the preconditions are failed to delete a tenant? On Mon, Nov 21, 2016 at 8:44 AM, Joseph Fonseka <jos...@wso2.com> wrote: > Hi Lashantha > > Few corrections according to WSO2 REST API guidelines [1]. > > 1. The POST should return 201 Created response. > 2. And as a practice we do not use 500 error codes in API interface. > 3. If the tenant is already exist you can send a 400 Bad Rest with error > json explaining what went wrong. > > If you want an example please refer [2] and [3]. > > Best Regards > Jo > > > > [1] http://wso2.com/whitepapers/wso2-rest-apis-design-guidelines/ > [2] https://raw.githubusercontent.com/wso2/carbon-apimgt/v6.0.4/ > components/apimgt/org.wso2.carbon.apimgt.rest.api.store/ > src/main/resources/store-api.yaml > [3] https://docs.wso2.com/display/AM200/apidocs/store/ > > On Fri, Nov 18, 2016 at 1:27 PM, Dilan Udara Ariyaratne <dil...@wso2.com> > wrote: > >> Hi Lasantha, >> >> I did go through the list of REST APIs that you have defined in the >> swagger doc. >> But I have not found any API for doing an update to an existing tenant as >> well as deactivation. >> >> Are we skipping those capabilities found in C4 based multi-tenancy, here ? >> >> Regards, >> Dilan. >> >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Wed, Nov 16, 2016 at 11:12 AM, Imesh Gunaratne <im...@wso2.com> wrote: >> >>> On Tue, Nov 15, 2016 at 5:00 PM, Lasantha Samarakoon <lasant...@wso2.com >>> > wrote: >>> >>>> Hi all, >>>> >>>> We are currently working on implementing multitenancy for Carbon-5 >>>> based products. In order to implement this we are creating Kubenetes >>>> namespaces for each tenant (namespaces provides isolation between tenants >>>> and the same approach has been used by WSO2 cloud as well). >>>> >>>> In most of the customer use cases, the tenants can be defined at the >>>> deployment time, but in order to cater SaaS requirements the tenants has to >>>> be created dynamically. To achieve this we have built a REST API using >>>> Microservices[1] (please find the attached Swaggger definition of the API). >>>> This API provides a endpoints for basic CRUD operations on tenants on >>>> Kubenetes cluster. >>>> >>> >>> Great work Lasantha! Can you please share the API resource/method list >>> in text >>> >>> format? >>> >>>> >>>> So in order to proceed with this what are the options to integrate this >>>> with the platform? Do we need to implement a UUF component and/or a CLI as >>>> well? >>>> >>> >>> May be we can write a bash script first and later move to a CLI/UI. >>> >>> I think we would also need to expose methods for automating the >>> deployment process once tenants/namespaces are created. Each WSO2 product >>> would release required K8S defnitions together with the product releases. >>> >>> Thanks >>> >>>> >>>> [1] https://github.com/lasanthaS/wso2-carbon5-multitenancy-api >>>> >>>> >>>> Regards, >>>> >>>> *Lasantha Samarakoon* | Software Engineer >>>> WSO2, Inc. >>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>> Mobile: +94 (71) 214 1576 >>>> Email: lasant...@wso2.com >>>> Web:www.wso2.com >>>> >>>> lean . enterprise . middleware >>>> >>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Software Architect >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: https://medium.com/@imesh TW: @imesh >>> lean. enterprise. middleware >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM C5 - Using UUID columns as Primary Keys in DB tables
Hi Bathiya/Jo, Thanks for the valuable information. +1 for UUID as the PK On Sat, Nov 19, 2016 at 3:41 PM, Joseph Fonseka <jos...@wso2.com> wrote: > > > On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka <jos...@wso2.com> wrote: > >> Hi All >> >> Another most obvious advantage of using UUIDs would that it will simplify >> import/export of APIs. I am +1 for using UUIDs as primary keys. >> > > In a more correct term UUIDs will simplify managing APIs cross > environments. > > >> >> Cheers >> Jo >> >> On Sat, Nov 19, 2016 at 12:42 PM, Bhathiya Jayasekara <bhath...@wso2.com> >> wrote: >> >>> Hi Lahiru, >>> >>> One of the reasons to expose UUIDs instead of auto increment IDs in REST >>> resources is that if we expose auto increment ID, we unwillingly expose >>> certain internal information like how many resources we have in our system >>> and the pattern how we store these resources. That information can be used >>> as vulnerabilities for security attacks. Due to the same reason, it's kind >>> of a standard to use UUIDs instead of auto increment IDs in REST world. You >>> can find some detailed explanations about that on the web[1][2]. >>> >>> [1] http://stackoverflow.com/questions/12378220/api-design-a >>> nd-security-why-hide-internal-ids >>> [2] http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-i >>> ncrement-ids-in-urls.html >>> >>> Thanks, >>> Bhathiya >>> >>> On Sat, Nov 19, 2016 at 12:12 PM, Lahiru Cooray <lahi...@wso2.com> >>> wrote: >>> >>>> Hi Uvindra, >>>> The reason you mentioned is: >>>> "Having a UUID for this purpose means that end users cannot guess the >>>> possible unique identity of other entities, which is possible if we exposed >>>> an integer based identifier." >>>> >>>> What is the purpose of having a non guessable Id here? Anywhere the >>>> user who has permissions to invoke api's can get the uuid list or simply >>>> can view in the Store/Publisher UI. If there are any more implementation >>>> constraints (eg: user should be able to delete api's only in his tenant >>>> domain, etc) should be handle internally. >>>> >>>> What I'm trying to highlight is, we should only move to a hybrid >>>> approach only if there's a valid use case. Else it's less complex if we can >>>> move only with the auto increment Id. >>>> >>>> [Solution we discuss here can also be reused in AppM c5 upgrade] >>>> >>>> >>>> >>>> On Fri, Nov 18, 2016 at 11:27 PM, Uvindra Dias Jayasinha < >>>> uvin...@wso2.com> wrote: >>>> >>>>> We expose the unique UUID of a given artifact to the end user via REST >>>>> APIs. You can see how this is used in the REST API docs[1]. We cant use >>>>> the >>>>> auto increment ID for this purpose for the reasons I mentioned earlier. >>>>> >>>>> [1] https://docs.wso2.com/display/AM200/apidocs/publisher/index.html >>>>> >>>>> On 18 November 2016 at 22:48, Lahiru Cooray <lahi...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I was under the impression that the UUID was used as a result of >>>>>> having registry and UUID was used to map the registry resource. Pls >>>>>> correct >>>>>> me if I'm wrong. >>>>>> >>>>>> When the registry is no longer present, I don't see a real use case >>>>>> of going for a hybrid approach. Either we could use UUID as a PK or an >>>>>> auto >>>>>> increment ID. >>>>>> >>>>>> In this case +1 for an auto increment ID as the PK. >>>>>> Reasons: easy to debug manually/ easy to sort by id/ save space >>>>>> >>>>>> On Fri, Nov 18, 2016 at 9:34 PM, Uvindra Dias Jayasinha < >>>>>> uvin...@wso2.com> wrote: >>>>>> >>>>>>> We already have a UUID column for few tables such as AM_API and >>>>>>> AM_APPLICATION which is used to uniquely identify a record. The reason >>>>>>> why >>>>>>> we have a UUID column is because it is the unique identifier that we >>>>>>> expose >>>>>>> t
Re: [Architecture] APIM C5 - Using UUID columns as Primary Keys in DB tables
Hi, I was under the impression that the UUID was used as a result of having registry and UUID was used to map the registry resource. Pls correct me if I'm wrong. When the registry is no longer present, I don't see a real use case of going for a hybrid approach. Either we could use UUID as a PK or an auto increment ID. In this case +1 for an auto increment ID as the PK. Reasons: easy to debug manually/ easy to sort by id/ save space On Fri, Nov 18, 2016 at 9:34 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > We already have a UUID column for few tables such as AM_API and > AM_APPLICATION which is used to uniquely identify a record. The reason why > we have a UUID column is because it is the unique identifier that we expose > to the end user. Having a UUID for this purpose means that end users cannot > guess the possible unique identity of other entities, which is possible if > we exposed an integer based identifier. > > However at table level we were still maintaining an auto incrementing > primary key. So the UUID was used externally but the integer key was used > privately to maintain foreign key relationships within the schema. > > We first thought it might be a good idea to dispense of the auto > incrementing primary key and use the UUID as the primary key itself since > it seemed like we had two columns that served somewhat duplicate purposes. > But I have been doing some research regarding this and have found that the > industry is divided a bit regarding this point. > > These links advocate UUIDs as primary keys > https://blog.codinghorror.com/primary-keys-ids-versus-guids/ > https://www.clever-cloud.com/blog/engineering/2015/05/20/ > why-auto-increment-is-a-terrible-idea/ > > These links recommend auto incrementing integers as primary keys > http://stackoverflow.com/questions/404040/how-do-you- > like-your-primary-keys/404057#404057 > http://stackoverflow.com/questions/829284/guid-vs-int-identity > > We can still continue with our hybrid approach of having both an auto > incriminating integer as primary key and using the UUID for external > interactions, whihc seems to be also used by some to get the best of both > worlds. > > > So how should we proceed? > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM C5 - Pagination
+1 for Jo's opinion on using RBMS based pagination. I think we are trying here to make the code unnecessarily complex by introducing caches. As discussed this may become more complex when we do sorting/searching operations. Also regarding the performance, I don't see a significant performance gain by introducing our own cache as RDBMS's normally maintain query caches. Only benefit I see here is avoiding the vendor specific queries. How about addressing this concern properly by introducing a factory method and giving the flexibility to plug a new vendor easily when needed. On Wed, Nov 16, 2016 at 3:23 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > Hi Jo, > > On 16 November 2016 at 14:47, Joseph Fonseka <jos...@wso2.com> wrote: > >> Hi Uvindra >> >> On Wed, Nov 16, 2016 at 1:48 PM, Uvindra Dias Jayasinha <uvin...@wso2.com >> > wrote: >>> >>> >>> Searching and sorting will be done at DB level via SQL. It is only the >>> pagination of the returned result set that will be done at Java level. >>> >> >> So does this mean for different search request you will be caching >> separate sets of data ? If that is so will it exhaust the memory and how >> will API search perform under a load. And since the servers will be running >> on containers available memory would be even less. >> > > Thats a good point, definitely should not be caching different search > request results.. Will discuss this with the team and get back to you. > >> >> Why would this be more efficient than Java? We achieve a similar thing by >>> using a local cache so there is no need to have an intermediate in memory >>> DB. What was proposed makes sense when you consider that we a dealing with >>> only a very small amount of data at DB level now. >>> >> >> Considering pagination is done using DBMS, in-memory db will help to work >> only with a one data set as well as needing to maintain one set of >> pagination queries. >> > > Hmmm I still dont understand the difference between in memory DB and in > memory cache. Technically in both cases we are working with an in memory > dataset. > >> >> >>> In the future if we foresee a requirement for DB level pagination we can >>> implement that within the DAO layer, but for now this is more than enough >>> to meet our needs. This way we can avoid introducing unwanted complexity >>> upfront since there is no rationale for doing so. >>> >> >> Agreed, but if the complexity is to support pagination for all the DBMSs >> we can at-least focus on adding db level pagination for commonly used DBMSs >> (ie MySQL, Oracle). >> > > Its not a complexity to support for multiple DB's, we can do that but its > an additional effort we can avoid by going down this path. > >> >> Regards >> Jo >> >> >> >> >> >> >>> >>> >>>> Thanks & Regards >>>> Jo >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>>>> With regards, >>>>>> *Manu*ranga Perera. >>>>>> >>>>>> phone : 071 7 70 20 50 >>>>>> mail : m...@wso2.com >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Uvindra >>>>> >>>>> Mobile: 33962 >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> *Joseph Fonseka* >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 772 512 430 >>>> skype: jpfonseka >>>> >>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 33962 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM C5 - Schema for handling resources stored as blobs
Hi, Well if I use an example to explain what I said, refer data_type column. Check the given sample values. xml,png,json are file extensions while text is a magic word/implementation logic we use to refer urls and inline text (file type). AFAIC these are different data. Even if we treat this as a generic field, we could further nomalize the DB structure having this field in resource type table. eg: CREATE TABLE `AM_FILE_TYPES` ( `FILE_TYPE_ID` INTEGER AUTO_INCREMENT, `FILE_TYPE_NAME` VARCHAR(255), PRIMARY KEY (`FILE_TYPE_ID `) ); (file type: either blob/inline text or url) CREATE TABLE `AM_RESOURCE_TYPES` ( `RESOURCE_TYPE_ID` INTEGER AUTO_INCREMENT, `RESOURCE_TYPE_NAME` VARCHAR(255), `FILE_TYPE_ID ` INTEGER, PRIMARY KEY (`RESOURCE_TYPE_ID`), FOREIGN KEY (`FILE_TYPE_ID `) REFERENCES`AM_FILE_TYPES `(` FILE_TYPE_ID `) ON UPDATE CASCADE ON DELETECASCADE, ); CREATE TABLE `AM_API_RESOURCES` ( `RESOURCE_ID` INTEGER AUTO_INCREMENT, `API_ID` INTEGER, `RESOURCE_TYPE_ID` INTEGER, // `DATA_TYPE` VARCHAR(255), [remove this field] `RESOURCE_TEXT_VALUE` VARCHAR(1024), `RESOURCE_BINARY_VALUE` BLOB, PRIMARY KEY (`RESOURCE_ID`), FOREIGN KEY (`API_ID`) REFERENCES `AM_API`(`API_ID`) ON UPDATE CASCADE ON DELETE CASCADE, FOREIGN KEY (`RESOURCE_TYPE_ID`) REFERENCES `AM_RESOURCE_TYPES`(`RESOURCE_TYPE_ID`) ON UPDATE CASCADE ON DELETE CASCADE ); further if required, we could maintain a extension field in AM_API_RESOURCES table. I'm not telling that the proposed structure is wrong. This is just a suggestion to further normalize and minimize data repetition and to make the structure more clearer. On Wed, Nov 9, 2016 at 4:54 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > > > On 9 November 2016 at 12:36, Lahiru Cooray <lahi...@wso2.com> wrote: > >> >> >> On Tue, Nov 8, 2016 at 1:23 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> >> wrote: >> >>> >>> >>> On 8 November 2016 at 11:10, Lahiru Cooray <lahi...@wso2.com> wrote: >>> >>>> >>>> >>>> On Thu, Nov 3, 2016 at 4:01 PM, Uvindra Dias Jayasinha < >>>> uvin...@wso2.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> Currently APIs have a few resources such as Swagger File, Optional >>>>> WSDL file, Related Documents file and an Optional Thumbnail image that >>>>> needs to be stored as blobs in the DB. >>>>> >>>>> Initially we thought of having separate tables to store these >>>>> resources, but what if we have a single generic resource table to store >>>>> all >>>>> these? >>>>> >>>>> We could have schema such as below for the generic resource table >>>>> >>>>> >>>>> Since we previously stored our resources in the registry, a similar >>>>> generic schema was used to store all such resources by the registry >>>>> itself. >>>>> So anything that is not a text data type can be considered as a BLOB. >>>>> >>>>> The advantages of doing this are, >>>>> >>>>> 1. Can manage all API related resources from a central table without >>>>> having to define custom tables for each resource. >>>>> >>>> +1 >>>> >>>>> 2. When an API is deleted its very easy to locate and remove all the >>>>> resources related with it >>>>> >>>> +1 >>>> >>>>> 3. When a new version of an API is created its very easy to copy over >>>>> the resources associated with the previous version to the new one. >>>>> >>>> Do we have a new API_ID for each version or do we have multiple version >>>> no's against an API_ID? Then we need to maintain Version also as another >>>> column >>>> >>> >>> A new API version will have a new API_ID. >>> >>>> >>>> >>>>> WDYT? >>>>> >>>>> >>>> +1 for the idea. >>>> Also is DATA_TYPE mean the file extension? if so I suggest to rename >>>> the name and also keep the file name as another column. >>>> >>> >>> In some case we are saving URLs with DATA_TYPE column as TEXT so those >>> aren't files. To be generic its better to keep this as DATA_TYPE >>> >> >> In that case I have a different suggestion. Im not sure if maintaining >> irrelevant data in same column is a good practice. >> Can't we maintain the file type (eg: binary or inline) in the resource
Re: [Architecture] APIM C5 - Schema for handling resources stored as blobs
On Tue, Nov 8, 2016 at 1:23 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > > > On 8 November 2016 at 11:10, Lahiru Cooray <lahi...@wso2.com> wrote: > >> >> >> On Thu, Nov 3, 2016 at 4:01 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> Currently APIs have a few resources such as Swagger File, Optional WSDL >>> file, Related Documents file and an Optional Thumbnail image that needs to >>> be stored as blobs in the DB. >>> >>> Initially we thought of having separate tables to store these resources, >>> but what if we have a single generic resource table to store all these? >>> >>> We could have schema such as below for the generic resource table >>> >>> >>> Since we previously stored our resources in the registry, a similar >>> generic schema was used to store all such resources by the registry itself. >>> So anything that is not a text data type can be considered as a BLOB. >>> >>> The advantages of doing this are, >>> >>> 1. Can manage all API related resources from a central table without >>> having to define custom tables for each resource. >>> >> +1 >> >>> 2. When an API is deleted its very easy to locate and remove all the >>> resources related with it >>> >> +1 >> >>> 3. When a new version of an API is created its very easy to copy over >>> the resources associated with the previous version to the new one. >>> >> Do we have a new API_ID for each version or do we have multiple version >> no's against an API_ID? Then we need to maintain Version also as another >> column >> > > A new API version will have a new API_ID. > >> >> >>> WDYT? >>> >>> >> +1 for the idea. >> Also is DATA_TYPE mean the file extension? if so I suggest to rename the >> name and also keep the file name as another column. >> > > In some case we are saving URLs with DATA_TYPE column as TEXT so those > aren't files. To be generic its better to keep this as DATA_TYPE > In that case I have a different suggestion. Im not sure if maintaining irrelevant data in same column is a good practice. Can't we maintain the file type (eg: binary or inline) in the resources types table which Akalanka suggested? And in this transaction table, if the file type is inline we could store the url in a separate column and if the file type is a binary we could store binary value/file name/extension in separate columns. >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 33962 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Lahiru Cooray* >> Software Engineer >> WSO2, Inc.;http://wso2.com/ >> lean.enterprise.middleware >> >> Mobile: +94 715 654154 >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM C5 - Schema for handling resources stored as blobs
On Thu, Nov 3, 2016 at 4:01 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > Hi All, > > Currently APIs have a few resources such as Swagger File, Optional WSDL > file, Related Documents file and an Optional Thumbnail image that needs to > be stored as blobs in the DB. > > Initially we thought of having separate tables to store these resources, > but what if we have a single generic resource table to store all these? > > We could have schema such as below for the generic resource table > > > Since we previously stored our resources in the registry, a similar > generic schema was used to store all such resources by the registry itself. > So anything that is not a text data type can be considered as a BLOB. > > The advantages of doing this are, > > 1. Can manage all API related resources from a central table without > having to define custom tables for each resource. > +1 > 2. When an API is deleted its very easy to locate and remove all the > resources related with it > +1 > 3. When a new version of an API is created its very easy to copy over the > resources associated with the previous version to the new one. > Do we have a new API_ID for each version or do we have multiple version no's against an API_ID? Then we need to maintain Version also as another column > WDYT? > > +1 for the idea. Also is DATA_TYPE mean the file extension? if so I suggest to rename the name and also keep the file name as another column. > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Storing configs in database for C5
;> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sajith Kariyawasam >>> *Associate Tech Lead* >>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >>> *Committer and PMC member, Apache Stratos * >>> *AMIE (SL)* >>> *Mobile: 0772269575* >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 33962 >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmali Baminiwatta > Associate Technical Lead > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > blog : lakmali.com > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Review DB table audit fields for API Manager C5
On Tue, Oct 11, 2016 at 1:44 PM, Sanjeewa Malalgoda <sanje...@wso2.com> wrote: > I think we can manage audit table while still having CREATED_BY, > CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that > approach we may never need to do table scan of audit table while fetching > updates. So each updates will recorded in separate table while original > table having all relevant information. WDYT? > +1 Also we may need the highlighted separate audit table to keep a track of deleted rows. > > Thanks, > sanjeewa. > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Creating several versions of same API on APIM REST APIs
Hi, As per my understanding here what you are trying to achieve is to avoid api duplication when creating new api's. So I would suggest you to implement a validation method and keep it as an util where this could be used in several operations(eg: copy api/update api etc with slight changes) Validation method should be consist of following constraints: 1) Check if the api provide/name/version is unique if true, 2) Check it the context is duplicated only within same api-name/provider api's. (you could do this easily with a simple sql dml statement) On Mon, Sep 12, 2016 at 9:15 AM, Kaveesha Perera <kavee...@wso2.com> wrote: > Hi, > > Currently I'm working on a client side tool to perform import and export > of APIs in APIM. > > I encountered conflict issues(error 409) on following instances when using > REST APIs to create a new API. > 1.when trying to re-import already published API > 2.when trying to import a new version of a already published API > > This is because along API post , initially it check for the context by [1] > and throw a conflict exception if context template of the payload and a > existing API alike. > > Several versions of the same API has same *context template* and it > should be a exceptional scenario of above mentioned procedure. To handle > this hope to do following modifications for apisPost REST API. > > On API post initially do check [1]. If returns true, get the corresponding > API name from the database and check if the API name in the payload and the > published API are same. If same, then retrieve all the published versions > of that API from the database and check those against version stated in the > payload. Method should throws a conflict exception only if the payload > holds a already published version of the API or if the API name on the > payload and API name in the database corresponds to same context template > differs.Else it will allow the normal process of creating a new API.Summary > of the proposed changes are shown in Fig.1.0 > > > *Fig.1.0* > > > > [1] apiProvider.isDuplicateContextTemplate(body.getContext()) > > If any feedback please do reply. > > Regards, > Kaveesha > > -- > Kaveesha Perera > Intern - Software Engineering > > mobile: 0716130471 > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Urgent] App Manager Service Providers registration and XACML policy creation related architectural changes - (was): [Dev] [AppM] Creating XACML Policies and Service Providers in Te
ther interceptor point to do the >>>>>>>> authorization and it is also like same authentication component. You >>>>>>>> can >>>>>>>> write your own handlers, and intercept by any place. We have written an >>>>>>>> another valve as interceptor and authorization handler check the >>>>>>>> permission >>>>>>>> as configure in identity.xml as follows. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> http-method="all"> >>>>>>>> /permission/admin/login >>>>>>>> >>>>>>>>>>>>>>> http-method="put,post"> >>>>>>>> /permission/admin/test >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We are going to release 1.0.0 M1 with next upcoming milestone in >>>>>>>> 5.3.0. >>>>>>>> Your ideas welcome to improve this component in more generic >>>>>>>> manner. Please let us know anything related to this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Harsha Thirimanna* >>>>>>>> Associate Tech Lead | WSO2 >>>>>>>> >>>>>>>> Email: hars...@wso2.com >>>>>>>> Mob: +94715186770 >>>>>>>> Blog: http://harshathirimanna.blogspot.com/ >>>>>>>> Twitter: http://twitter.com/harshathirimann >>>>>>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>>>>>>> rsha-thirimanna/10/ab8/122 >>>>>>>> <http://wso2.com/signature> >>>>>>>> >>>>>>>> On Tue, Aug 9, 2016 at 4:00 AM, Farasath Ahamed <farasa...@wso2.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Rushmin, >>>>>>>>> >>>>>>>>> On Mon, Aug 8, 2016 at 4:14 PM, Rushmin Fernando <rush...@wso2.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Thanks Ishara ! >>>>>>>>>> >>>>>>>>>> Since our products are adopting OAuth protected ReST APIs, is >>>>>>>>>> there an OAuth authencator being developed and planed to be >>>>>>>>>> developed ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Harsha has worked on developing a generic component that can be >>>>>>>>> used by OAuth protected REST APIs[1]. Adding Harsha as he can provide >>>>>>>>> more >>>>>>>>> details on this. >>>>>>>>> >>>>>>>>> [1] https://github.com/wso2-extensions/identity-carbon-auth-rest >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Rushmin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 8, 2016 at 4:04 PM, Ishara Karunarathna < >>>>>>>>>> isha...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dinusha, >>>>>>>>>>> >>>>>>>>>>> In this case I think publisher user should be able to create >>>>>>>>>>> those SP, XACML policies etc. >>>>>>>>>>> Since publisher use is within the publisher role you can assign >>>>>>>>>>> necessary permission to that role. >>>>>>>>>>> Once user login (SSO) to publisher with his credential he can >>>>>>>>>>> get a cookie for that >>>>>>>>>>> and he can use that cookie to authenticate to the admin >>>>>>>>>>> services. >>>>>>>>>>> >>>>>>>>>>> @Rushmin, >>&
[Architecture] [Dev] App Manager-1.2.0 Released !
please visit http://wso2.com/support. *-- The WSO2 App Manager Team --* -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [VOTE] WSO2 App Manager 1.2.0 RC3
Tested following Scenarios: - SSO and SLO - App visibility restrictions - Resource level role based restriction - Favourite apps/page functionality - Sorting and searching +1 Stable - Go ahead and release. On Wed, Jul 20, 2016 at 11:09 PM, Lahiru Cooray <lahi...@wso2.com> wrote: > Hi Devs, > > This is the 3rd Release Candidate of the WSO2 App Manager 1.2.0 > > Please download, test the product and vote. Vote will be open for 72 hours > or as needed. > Refer to github readme for guides. > > The distribution is available to download at [1] > > [1] : > https://github.com/wso2/product-app-manager/releases/download/v1.2.0-RC3/wso2appm-1.2.0.zip > > Fixed Issue in [2], known issues [3], tag to be vote upon [4] > > [2] : https://wso2.org/jira/issues/?filter=13104 > [3] : https://wso2.org/jira/issues/?filter=13148 > [4] : https://github.com/wso2/product-app-manager/releases/tag/v1.2.0-RC3 > > Please vote as follows. > [+] Stable - go ahead and release > [-] Broken - do not release (please explain why) > > Thanks, > App Manager Team > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [Dev] [VOTE] WSO2 App Manager 1.2.0 RC3
Hi Devs, This is the 3rd Release Candidate of the WSO2 App Manager 1.2.0 Please download, test the product and vote. Vote will be open for 72 hours or as needed. Refer to github readme for guides. The distribution is available to download at [1] [1] : https://github.com/wso2/product-app-manager/releases/download/v1.2.0-RC3/wso2appm-1.2.0.zip Fixed Issue in [2], known issues [3], tag to be vote upon [4] [2] : https://wso2.org/jira/issues/?filter=13104 [3] : https://wso2.org/jira/issues/?filter=13148 [4] : https://github.com/wso2/product-app-manager/releases/tag/v1.2.0-RC3 Please vote as follows. [+] Stable - go ahead and release [-] Broken - do not release (please explain why) Thanks, App Manager Team -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 App Manager 1.2.0-Beta2 Released!
*WSO2 App Manager 1.2.0-Beta2 Released!* WSO2 App Manager team is pleased to announce WSO2 App Manager 1.2.0-BETA2 release. Download distribution here <http://builder1.us1.wso2.org/~appm/release-1.2.0/Beta2/wso2appm-1.2.0-BETA2.zip>. This release comes with following new features, improvements and bug fixes. New Features [APPM-1442] <https://wso2.org/jira/browse/APPM-1442> - New asset type - Sites. [APPM-1443] <https://wso2.org/jira/browse/APPM-1443> - Configurable subscription options for Web App and Sites asset types. [APPM-1444] <https://wso2.org/jira/browse/APPM-1444> - Multiple version support for Web App and Sites asset types. [APPM-1446] <https://wso2.org/jira/browse/APPM-1446> - Java APIs for all key App Manager functionalities that need to be integrated with device management functionalities. [APPM-1445] <https://wso2.org/jira/browse/APPM-1445> - Role based visibility control for mobile apps [APPM-1441] <https://wso2.org/jira/browse/APPM-1441> - Redesign product REST APIs with JAX-RS implementation and secure with OAuth [APPM-1447] <https://wso2.org/jira/browse/APPM-1447> - Business Owner concept implementation [APPM-1493] <https://wso2.org/jira/browse/APPM-1493> - Supporting custom fields to be added in publisher UI and new REST APIs [APPM-1492] <https://wso2.org/jira/browse/APPM-1492> - One time download link support for mobile apps Improvements [APPM-1437] <https://wso2.org/jira/browse/APPM-1437> - Navigation improvement to Store [APPM-1440] <https://wso2.org/jira/browse/APPM-1440> - New theme for store UI Tasks [APPM-1438] <https://wso2.org/jira/browse/APPM-1438> - Responsive store UI by Boostrap3 upgrade [APPM-1530] <https://wso2.org/jira/browse/APPM-1530> - Kernal version upgrade to 4.4.7 [SECINTDEV-48] <https://support.wso2.com/jira/browse/SECINTDEV-48> - Security Scan Reports and fixes Bug Fixes WSO2 App Manager 1.2.0-beta2 resolved issues <https://wso2.org/jira/issues/?filter=13104> Reporting Problems Issues can be reported through public JIRA <https://wso2.org/jira/browse/APPM> project assigned to WSO2 AppM. Thanks, App Manager team -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 App Manager 1.2.0-Beta Released!
*WSO2 App Manager 1.2.0-Beta Released!* WSO2 App Manager team is pleased to announce WSO2 App Manager 1.2.0-BETA release. Download distribution here <http://builder1.us1.wso2.org/~appm/release-1.2.0/Beta/wso2appm-1.2.0-BETA.zip>. This release comes with following new features, improvements and bug fixes. New Features [APPM-1442] <https://wso2.org/jira/browse/APPM-1442> - New asset type - Sites. [APPM-1443] <https://wso2.org/jira/browse/APPM-1443> - Configurable subscription options for Web App and Sites asset types. [APPM-1444] <https://wso2.org/jira/browse/APPM-1444> - Multiple version support for Web App and Sites asset types. [APPM-1446] <https://wso2.org/jira/browse/APPM-1446> - Java APIs for all key App Manager functionalities that need to be integrated with device management functionalities. [APPM-1445] <https://wso2.org/jira/browse/APPM-1445> - Role based visibility control for mobile apps [APPM-1441] <https://wso2.org/jira/browse/APPM-1441> - Redesign product REST APIs with JAX-RS implementation and secure with OAuth [APPM-1447] <https://wso2.org/jira/browse/APPM-1447> - Business Owner concept implementation [APPM-1493] <https://wso2.org/jira/browse/APPM-1493> - Supporting custom fields to be added in publisher UI and new REST APIs [APPM-1492] <https://wso2.org/jira/browse/APPM-1492> - One time download link support for mobile apps Improvements [APPM-1437] <https://wso2.org/jira/browse/APPM-1437> - Navigation improvement to Store [APPM-1440] <https://wso2.org/jira/browse/APPM-1440> - New theme for store UI Tasks [APPM-1438] <https://wso2.org/jira/browse/APPM-1438> - Responsive store UI by Boostrap3 upgrade [APPM-1439] <https://wso2.org/jira/browse/APPM-1439> - Kernal version upgrade to 4.4.5 Bug Fixes WSO2 App Manager 1.2.0-beta resolved issues <https://wso2.org/jira/issues/?filter=13104> Reporting Problems Issues can be reported through public JIRA <https://wso2.org/jira/browse/APPM> project assigned to WSO2 AppM. Thanks, App Manager team -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APPM] One time download link support for mobile app install/download
On Tue, Jun 7, 2016 at 9:12 AM, Thilini Shanika <thili...@wso2.com> wrote:
> Hi all,
>
> We are planning to implement one-time app download link support for mobile
> application installation/download in App Manager 1.2.0. The main objective
> of introducing this feature is to overcome security issues with the current
> approach of installing mobile apps.
>
> Below is the designed approach of achieving $Subject.
>
>
> According to above,
>
>- User login to App Store and make subscription/installation to a
>particular mobile app
>- One time download link is generated for the user
>(/binaries/one-time/{UUID}) and the mapping of generated UUID and
>the actual binary file is persisted in a Database table. The status of the
>download will be marked as 0 to indicate that the download link has not
>been used yet.
>- The device will access the binary download API via the generated
>UUID to install the app. When the download/installation is completed, the
>status of the binary downloadable URL reference will be marked as 1 to
>indicate it has been used once. After an app download, any other access to
>the link will be prohibited.
>
>
> There are few concerns regarding the implementation.
>
>- The generated download link is not secured since it is a one-time
>download link. Is there a security concern regarding this approach?
>- According to above, a single user will have to generate separate app
>download links, in a case where he has several devices to download the app.
>In that case, are we going to limit (Configurable limit) the number of
>download links that can be generated by a single user?
>
> AFAIK we use the same operation to perform the enterprise installation as
well, where an admin user can install an App to several users/devices. In
that case I don't think limiting generation of download links user wise
would be a good option (unless we consider the devices as well)
>
>- Are we going to persist the details of the device (device id) that
>the download link had been generated for so that we can enforce the
>security?
>
> +1
> Your comments and suggestions are highly appreciated.
>
> Thanks
> Thilini
>
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware
Mobile: +94 715 654154
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 App Manager 1.2.0-ALPHA Released!
*WSO2 App Manager 1.2.0-ALPHA Released!* WSO2 App Manager team is pleased to announce WSO2 App Manager 1.2.0-ALPHA release. Download distribution here <http://builder1.us1.wso2.org/~appm/release-1.2.0/Alpha/wso2appm-1.2.0-ALPHA.zip>. This release comes with following new features, bug fixes and improvements. Bug Fixes WSO2 App Manager 1.2.0-alpha resolved issues <https://wso2.org/jira/issues/?filter=13082> Improvements [APPM-1437] <https://wso2.org/jira/browse/APPM-1437> - Navigation improvement to Store [APPM-1440] <https://wso2.org/jira/browse/APPM-1440> - New theme for store UI New Features [APPM-1442] <https://wso2.org/jira/browse/APPM-1442> - New asset type - Sites. [APPM-1443] <https://wso2.org/jira/browse/APPM-1443> - Configurable subscription options for Web App and Sites asset types. [APPM-1444] <https://wso2.org/jira/browse/APPM-1444> - Multiple version support for Web App and Sites asset types. [APPM-1446] <https://wso2.org/jira/browse/APPM-1446> - Java APIs for all key App Manager functionalities that need to be integrated with device management functionalities. [APPM-1445] <https://wso2.org/jira/browse/APPM-1445> - Role based visibility control for mobile apps [APPM-1441] <https://wso2.org/jira/browse/APPM-1441> - Redesign product REST APIs with JAX-RS implementation and secure with OAuth [APPM-1447] <https://wso2.org/jira/browse/APPM-1447> - Associate business owner for apps Tasks [APPM-1438] <https://wso2.org/jira/browse/APPM-1438> - Responsive store UI by Boostrap3 upgrade [APPM-1439] <https://wso2.org/jira/browse/APPM-1439> - Kernal version upgrade to 4.4.5 Reporting Problems Issues can be reported through public JIRA <https://wso2.org/jira/browse/APPM> project assigned to WSO2 AppM. Thanks, App Manager team -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppM] Supporting custom fields added to the publisher UI with new REST APIs
gt;>> Associate Technical Lead >>>> WSO2 Inc.: http://wso2.com/ >>>> Mobile: +94725255071 >>>> Blog: http://dinushasblog.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Dinusha Dilrukshi >>> Associate Technical Lead >>> WSO2 Inc.: http://wso2.com/ >>> Mobile: +94725255071 >>> Blog: http://dinushasblog.blogspot.com/ >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services;http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Dimuthu Leelarathne > Director, Solutions Architecture > > WSO2, Inc. (http://wso2.com) > email: dimut...@wso2.com > Mobile: +94773661935 > Blog: http://muthulee.blogspot.com > > Lean . Enterprise . Middleware > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [DEV] WSO2 App Manager 1.2.0 Milestone 5 Released
Hi All, WSO2 App Manager team pleased to announce the WSO2 APP Manager 1.2.0 - Milestone 5 release. It contains following new features and bug fixes. You can download this distribution from below link. http://builder1.us1.wso2.org/~appm/release-1.2.0/M5/wso2appm-1.2.0-M5.zip *New Feature(s) * 1. Oauth secured Rest API's (Web apps) - Store API's - Publisher API's 2. Business Owner concept implementation *Bug Fixes* WSO2 App Manager 1.2.0-M5 resolved issues <https://wso2.org/jira/browse/APPM-1388?filter=12981=project%20%3D%20APPM%20AND%20fixVersion%20%3D%20%221.2.0-M5%22%20AND%20status%20in%20(Resolved%2C%20Closed)> Regards, App Manager Team. -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Swagger, API design and related best practices, and docs
Hi, In AppM REST API developments we used Contract-first approach same as in APIM (guideline [1]). Since we did not have any REST API's we had to start from the scratch (previously we had jaggery based API's and idea was to convert the logic with proper REST naming conventions) Contract-first approach helped us to do a proper designing before moving to the implementation and easiness of generating client/server platform independent stubs based on swagger annotations. But in EMM scenario as you already have the defined API's (which are already been used) I think a better approach will be, generating the swagger definition with an annotation model (for existing API's) and in next phase/version you can continue with Contract-first approach with the generated swagger def. [1] http://wso2.com/library/tutorials/2016/03/tutorial-how-to-turn-a-cool-idea-into-a-business-api-with-the-wso2-platform/ On Thu, Apr 28, 2016 at 3:16 PM, Dilshan Edirisuriya <ed.dils...@gmail.com> wrote: > Hi Prabath, > > Just commenting by looking at the EMM/IOT current state (I do agree that > there needs to be a proper standard on this). Although contract first > approach looks far more clean, EMM/IOT already have APIs defined. Hence > going with contract first approach could result in slight modifications to > the APIs? Not sure whether its valid though. If it so when it comes to EMM > case if there are customers using it, it could have an impact. Also why do > we see different standards across different products like AppM and EMM? > Naming conventions etc. are slightly different. Also how do you manage to > version the APIs with this? In AppM I see a version available in URL path. > Correct me if I am wrong. > > Regards, > > Dilshan > > On 28 April 2016 at 14:53, Prabath Abeysekera <praba...@wso2.com> wrote: > >> Hi Everyone, >> >> What I'm trying to do primarily is setting up Swagger-based docs for >> EMM/IoTS related APIs. However, while I was looking deeper into this, came >> across a few things that I need clarifications upon. >> >> *Code-first or Contract-first?* >> >> Right now it appears that there are two approaches being used in the >> platform for API design and development. >> >> 1. Contract first approach, which utilizes composing the Swagger >> definition upfront and then generating the API implementation out of it. >> >> (** I do understand that there's a whole big debate around different >> developer communities as to whether REST needs a contract, except for the >> HTTP protocol, at all. But, the primary intention of this thread is "not" >> to jump into a similar argument :) ) >> >> 2. Code first approach, which utilizes implementing the API first and >> then generates Swagger definition to be used for documentation purposes, >> etc. >> >> Each approach obviously has its own pros and cons. This is, therefore, to >> see what needs to be/already have standardized as the best approach to go >> about API design and implementation. >> >> If we consider contract-first approach, that looks more elegant and lets >> us enable enforcing proper governance across the API design and >> implementation process. For instance, folks can first work on the Swagger >> definition as the contract, at the design phase and then go into the >> implementations later on after verifying the resource definitions, etc. The >> second approach, on the other hand, makes it easier for us to deal with in >> terms of implementing complex and more coarse-grained HTTP APIs (which I >> believe is a common-case in the platform?) and exposing their definitions. >> >> *Impact of this on API documentation* >> >> So, coming back to the topic of documenting APIs with what was discussed >> earlier, if we go by the first approach, there we have the swagger >> definition up-front so we wouldn't need to go for any annotation-based >> models, etc and instead, can directly generate API documentation based on >> the existing Swagger definition via an appropriate doc generator tool. >> >> In contrast, the code-first approach demands us to go for an >> annotation-model or something similar to get the documentation done. >> >> Whichever the case would ultimately produce the same output, but I >> thought, as a platform we need to stick to just one approach and document >> it properly. So the question is, what would that be? >> >> >> Cheers, >> Prabath >> -- >> Prabath Abeysekara >> Technical Lead >> WSO2 Inc. >> Email: praba...@wso2.com >> Mobile: +94774171471 >> >>
Re: [Architecture] RESTFul API for App Manager - Design discussion
Hi all, Here with I'm sharing the finalized swagger definitions for your reference. On Thu, Mar 31, 2016 at 9:15 AM, Lahiru Cooray <lahi...@wso2.com> wrote: > Hi Sanjiva, > Herewith I have attached the pdf's and yes, we referred the WSO2 REST API > design guideline doc (attached) and also the APIM REST API design [1] as > references > > [1] https://docs.wso2.com/display/AM1100/apidocs/publisher/ > > > > On Thu, Mar 31, 2016 at 8:40 AM, Sanjiva Weerawarana <sanj...@wso2.com> > wrote: > >> Lahiru when sharing Google docs to this public list you need to PDF and >> attach as well .. non-WSO2 people can't read this. >> >> I assume this is compatible with the REST API design guidelines doc we >> wrote right? >> >> On Wed, Mar 30, 2016 at 10:06 AM, Lahiru Cooray <lahi...@wso2.com> wrote: >> >>> Hi All, >>> >>> We are planing to implement a RESTFul API to expose the App Manager >>> functionality. Initially we are focussing on replacing AppM Mobile API's >>> (Store/Publisher) . >>> Please refer the proposed new set of API's design [1] (and comparison >>> with existing API's [2]) and comment your suggestions >>> >>> [1] >>> https://docs.google.com/a/wso2.com/document/d/1UE7SgZGsGnOgo6CokXClc6LVtI3N0tcGeXClFOT7jIA/edit?usp=sharing >>> [2] >>> https://docs.google.com/a/wso2.com/document/d/1aib1gJHCwrpRhp6jNeKfD5KRgldbl_cHf9q9zVi0vTc/edit?usp=sharing >>> >>> -- >>> *Lahiru Cooray* >>> Software Engineer >>> WSO2, Inc.;http://wso2.com/ >>> lean.enterprise.middleware >>> >>> Mobile: +94 715 654154 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >> email: sanj...@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345) >> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >> Lean . Enterprise . Middleware >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 publisher-api.yaml Description: Binary data store-api.yaml Description: Binary data storeadmin-api.yaml Description: Binary data ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [DEV] WSO2 App Manager 1.2.0 Milestone 4 Released
[Adding architecture list] On Tue, Apr 19, 2016 at 10:14 PM, Lahiru Cooray <lahi...@wso2.com> wrote: > Hi All, > > WSO2 App Manager team pleased to announce > the WSO2 APP Manager 1.2.0 - Milestone 4 release. It contains following new > features, improvements and bug fixes. > > You can download this distribution from below link. > *http://builder1.us1.wso2.org/~appm/release-1.2.0/M4/ > <http://builder1.us1.wso2.org/~appm/release-1.2.0/M4/>* > > > *New Feature(s) * > 1. Oauth secured Rest API's (Mobile apps) > >- Store API's >- Publisher API's >- Store Admin API's > > > > > *Improvement(s)*1. UX improvements in App Store. > > *Bug Fixes* > WSO2 App Manager 1.2.0-M4 resolved issues > <https://wso2.org/jira/browse/APPM-1360?filter=12981=project%20%3D%20APPM%20AND%20fixVersion%20%3D%20%221.2.0-M4%22%20AND%20status%20in%20(Resolved%2C%20Closed)> > > > Regards, > App Manager Team. > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] RESTFul API for App Manager - Design discussion
Hi All, We are planing to implement a RESTFul API to expose the App Manager functionality. Initially we are focussing on replacing AppM Mobile API's (Store/Publisher) . Please refer the proposed new set of API's design [1] (and comparison with existing API's [2]) and comment your suggestions [1] https://docs.google.com/a/wso2.com/document/d/1UE7SgZGsGnOgo6CokXClc6LVtI3N0tcGeXClFOT7jIA/edit?usp=sharing [2] https://docs.google.com/a/wso2.com/document/d/1aib1gJHCwrpRhp6jNeKfD5KRgldbl_cHf9q9zVi0vTc/edit?usp=sharing -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [AppM] Improvement - Multiple versions support for Mobile Apps
Hi, We have implemented multiple versions support to WebApps and Sites in AppM. Here, we allow users to create multiple versions of a WebApp/Site and select a particular version as the default. So users can access the default version of the app with the default URL (eg: host_name/context) and also the previously subscribed non default versions by mentioning the particular version in the URL (eg: host_name/context/version). In the Store we have a deployment level configuration to select either to display all versions of an App or to display only the default version. But as per my understanding the same functionality is not applicable for Mobile Apps. Currently in Mobile Apps we can create multiple versions but the latest version is always considered as the active/default (no option to swap default version). Do we need to change this behaviour in Mobile Apps? If so, what would be the most appropriate functionality? Highly appreciate your suggestions. -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppM] Skiping custom login page on J2EE WebApp with JWT.
Hi, This PoC illustrates how to achieve this requirement for an application hosted in tomcat. And similarly, I believe we can achieve the same for a .NET application hosted in an IIS using a customerized HTTP module. Please refer the below examples: [1] https://msdn.microsoft.com/en-us/library/bb398986.aspx#Features [2] https://msdn.microsoft.com/en-us/library/xx2w5c88(v=vs.85).aspx On Fri, Feb 12, 2016 at 4:53 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote: > Hi All, > Any third party applications currently being fronted by AppM will need a > change in the application side to take the credentials from the JWT and > associate it with its internal request flow. This is a barrier for > migrating the existing applications to AppM. > > We have a PoC servlet filter or Tomcat Valve option to make it easier to > migrate an existing J2EE compliant application to AppM. The same technique > can be used to skipping the login page on non standard Java Web > Applications, case by case basis. > > > J2EE webapp security is based on request.getPrincipal() and > request.isUserInRole() standard calls. We have two ways to intercept this > behaviour and put the Principal and Roles into the request pipeline. > > *1. With Servlet Filter* > > We can intercept the request pipeline by adding a servlet filter to the > web application. In order to do this the web application need to be changed > 1.1 Adding custom JWTSecurityFilter , by adding jar a file into WEB-INF/lib > 1.2. Change the "web.xml" adding, and engaging it into the all private > paths. > > > f1 > > org.wso2.appm.Security.servlets.JWTSecurityFilter > > > 1.3. Configuring the custom security xml which matches exactly what > web.xml tags do. Because custom filter does not have > access to web.xml data. > > Please see [1] for more information and PoC. > > > *2. Adapter to container request pipeline. E.g. Tomcat Valve* > > 2.1 Create a tomcat JWTSecurityValve, similar to TomcatSSOValve > 2.2. Add the jar to /lib > 2.3 Configure the configuration on Tomcat based containers, like JBoss) > > > > > > Please see [2] for more information and PoC. > > > > *Comparing option 1 and 2,* > *Option 2:* *Valve*, plugs and affects all the web applications hosted > on the container. However no change on individual webapp is required. We > need to write Valve or a Handler for each container and its major versions, > thus not portable. > *Option 1:* *Filter*, plugs only to each webapp individually, and need > few configuration changes on each webapp. This is appealing when webapp is > hosted on a container owned by another entity. The filter is a standard > J2EE construct. It is portable on any J2EE web container. > > > > [1] https://github.com/visithamanujaya/JWTSecuritySSO/tree/master/Filter > [2] > https://github.com/visithamanujaya/JWTSecuritySSO/tree/master/Valve/Tomcat_8 > > -- > > *Ruwan Abeykoon* > *Architect,* > *WSO2, Inc. http://wso2.com <http://wso2.com/> * > *lean.enterprise.middleware.* > > email: ruw...@wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APPM] [IS] Change of XACML based authorization
Hi Rushmin, I sent the above reply having the impression like that the XACML policy 'yes' / 'no' option is mapped with the resource.. But since its mapped to Policy Group +1 for the change... Thanks.. On Tue, Mar 31, 2015 at 10:55 AM, Lahiru Cooray lahi...@wso2.com wrote: Hi Rushmin, *Regarding XACML Policy assigning change.* Policy Groups were initially introduced to centralise the policy combinations, where we can assign all the required policies and wrap the combination as a policy group. So we do not need to set policies(User Roles, Allow Anonymous, XAML policies , etc) against each resource,instead we can map only the policy group. Here what you have mentioned is technically correct. We do not need the link between Policy Group and XACML Policies. But if we think end user's perspective, I think the XACML policies are also should be included to the policy group. Because for the end user, this is just another policy type. So why does he need to create a policy group with all other policy combinations and again assign the XACML policies separately? i'll vote '0' for the XACML Policy assigning change.. Thanks.. On Fri, Mar 27, 2015 at 8:54 PM, Rushmin Fernando rush...@wso2.com wrote: We are planning to change the existing XACML based authorization implementation. In the current implementation the XACML policies are generated by aggregating the following parts. 1) Target - Resource-Id (Determined by the URL of a resource) 2) Target - Action-Id (Determined by the HTTP verb of a resources) 3) Condition (App creator can author the condition element which whatever logic he needs) In the new implementation the policy generation part will be gone and the users should create policies using the carbon console. The main purpose of generating the policies from APPM side was to prevent a user who owns one app, from writing a XACML policy which might affect another app. Because it was APPM who generated the resource-id (relative URL of the resource) in the target of the policy. So that the users had no control over the resource-id hence there was no possibility for a creator of one app to mention a resource id of another app. So we should think of a way of enforcing this restriction, in the new implementation as well. (May be asking the policy creators to prefix the resource ids with the app UUID)That's one concern. And the other concern is, in the new implementation, the plan is to show the user, the policies list which were created using the Carbon console, when the user is going to create a policy group. So that the user can pick the policies and add them to the policy group. In other words we are going to maintain a mapping between the XACML policies refs and the APPM policy groups. But why ? When a request comes to the gateway we simply send a XACML request which contains the resource id (the http request url) and the action id (http verb). And the XACML engine would go through ALL the XACML policies to find out a policy which would match the given request. So there is not point of maintaining a mapping between the XACML policies and policy groups. Because its the XACML policy's 'target' sections which determine which policy should get engaged to a XACML request, not the mapping we are going to maintain from the APPM side. Therefore without do a mapping, shouldn't it be a simple option to say 'yes' or 'no' to XACML policy evaluation for a given APPM policy group Thoughts please ? Thanks Rushmin -- *Rushmin Fernando* *Technical Lead* WSO2 Inc. http://wso2.com/ - Lean . Enterprise . Middleware email : rush...@wso2.com mobile : +94772310855 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Generic RDBMS Output adapter support
Hi, Maintenance wise it's nice to keep queries in separate XML. And I think it's better to keep all the generic queries in a one section of the XML and keep DBMS specific queries in separate sections. So you don't need to rewrite common queries for each type. Also better to consider MS SQL Server as well in testing ( if it's supported DB type) as there are many syntax differences compared to Oracle and mysql On Fri, Nov 28, 2014 at 4:49 PM, Damith Wickramasinghe dami...@wso2.com wrote: Hi, Currently we have the support only for Mysql and it is decided to implement a generic adapter to support any RDBMS database. For now adapter implementation will be focused on supporting Oracle, Mysql and H2. I will update the thread on decided architecture for the said requirement soon. Any feedbacks on the requirement will be greatly appreciated. Regards, Damith. -- Software Engineer WSO2 Inc.; http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg lean.enterprise.middleware mobile: *+94728671315 %2B94728671315* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppManager] Sorting Applications in the store by accessed fequency
Hi, In addition to my previous mail, instead of directly writing to a DB, periodically we are publishing the events to BAM for analysing and processing so it will run in a different thread. On Fri, Nov 21, 2014 at 11:00 PM, Pulasthi Supun pulas...@wso2.com wrote: Hi All, The method that Udara mentioned would indeed improve performance. but when we scale it up to couple hundred or more applications again this will become a overhead. So how about introducing a map ( as an cache ) that keeps all the invocation data until the map is written to the database periodically.This way all the counter data in the map can be added to the database in a single batch operation which would scale even if there is a large number of applications. Best Regards, Pulasthi I have implemented a Javascript to store the events and post periodically. When an user clicks on an App, javascript triggers and store the relevant data(AppId, UserId) as events(in client side) and periodically (user can define the time gap) JS posts the event[] to a jaggery file. Then from the jaggery it sends the data to server. On Fri, Nov 14, 2014 at 11:49 PM, Udara Liyanage ud...@wso2.com wrote: Hi, So every time an app is accessed the incremented counter needs to be written to db. Isn't it an considerable overhead if apps are accessed frequently. How about keeping the counter in a cache or write to db say for every 10 times(a meaningful value) an app is accessed? Touched, not typed. Erroneous words are a feature, not a typo. On Nov 14, 2014 5:20 PM, Lahiru Cooray lahi...@wso2.com wrote: Hi all, I'm trying to add a new feature to AppManager to unable user to *sort* the subscribed Apps by accessed frequency. In the back end there will be a counter used to store the no of hits per App against each subscriber. When a subscriber access an App (via AppManager gateway end point URL) the counter will be increased. [image: Inline image 3] And in the front end there will be two options that user the can select. (recently added Apps/ most frequently accessed Apps) *Proposed table structure:* *CREATE TABLE APPMGR_APP_HIT_TOTAL* *(* *API_ID INT(10) NOT NULL,* *USER_ID VARCHAR(50) NOT NULL,* *HIT_COUNT BIGINT,* *PRIMARY KEY (API_ID,USER_ID)* *)* Highly Appreciate your feedbacks. -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Shareable Common JS
Hi, *Please refer the mail thread : [Architecture] [AF] Capturing BAM events with an objective of understanding user activity* Currently I'm working on implementing a common JS library modifying the above mentioned JS to make it more generic. User can give the below inputs to this Javascript as a json string: - *isActive* : switch to activate the JS features - *path* : Publisher Jaggery Path (JS library will post an event with results to mentioned path) - *appData* : Data in the web page which needs to add to the event (eg: ApiID, SubscriberID,Email, Username, etc) - *appControls : *User can mention some HTML controls here and for the changes in those controls this JS will execute - *publishedPeriod *: Time gap which user needs to publish. Then the Js will periodically post the result (appData, Timestamp) to the defined publisher path. *Please suggest the best place to keep these type of shareable resources.* -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppManager] Sorting Applications in the store by accessed fequency
thanks a lot for the feedbacks.. On Tue, Nov 18, 2014 at 12:15 PM, Srinath Perera srin...@wso2.com wrote: I also think Udara's idea is good. On Fri, Nov 14, 2014 at 11:49 PM, Udara Liyanage ud...@wso2.com wrote: Hi, So every time an app is accessed the incremented counter needs to be written to db. Isn't it an considerable overhead if apps are accessed frequently. How about keeping the counter in a cache or write to db say for every 10 times(a meaningful value) an app is accessed? Touched, not typed. Erroneous words are a feature, not a typo. On Nov 14, 2014 5:20 PM, Lahiru Cooray lahi...@wso2.com wrote: Hi all, I'm trying to add a new feature to AppManager to unable user to *sort* the subscribed Apps by accessed frequency. In the back end there will be a counter used to store the no of hits per App against each subscriber. When a subscriber access an App (via AppManager gateway end point URL) the counter will be increased. [image: Inline image 3] And in the front end there will be two options that user the can select. (recently added Apps/ most frequently accessed Apps) *Proposed table structure:* *CREATE TABLE APPMGR_APP_HIT_TOTAL* *(* *API_ID INT(10) NOT NULL,* *USER_ID VARCHAR(50) NOT NULL,* *HIT_COUNT BIGINT,* *PRIMARY KEY (API_ID,USER_ID)* *)* Highly Appreciate your feedbacks. -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [AppManager] Sorting Applications in the store by accessed fequency
Hi all, I'm trying to add a new feature to AppManager to unable user to *sort* the subscribed Apps by accessed frequency. In the back end there will be a counter used to store the no of hits per App against each subscriber. When a subscriber access an App (via AppManager gateway end point URL) the counter will be increased. [image: Inline image 3] And in the front end there will be two options that user the can select. (recently added Apps/ most frequently accessed Apps) *Proposed table structure:* *CREATE TABLE APPMGR_APP_HIT_TOTAL* *(* *API_ID INT(10) NOT NULL,* *USER_ID VARCHAR(50) NOT NULL,* *HIT_COUNT BIGINT,* *PRIMARY KEY (API_ID,USER_ID)* *)* Highly Appreciate your feedbacks. -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Extensions for Siddhi - Math operations
Hi Sanjiva, We used the alias 'custom' because we implemented these as custom extensions to Siddhi. Anyway 'math' would be the more meaningful alias. +1 for 'math:' On Sat, Oct 18, 2014 at 11:09 AM, Sanjiva Weerawarana sanj...@wso2.com wrote: Great - but why custom:. Can we not use math:?? On Wed, Oct 15, 2014 at 5:34 PM, Lahiru Cooray lahi...@wso2.com wrote: Hi, We have implemented below Math operations (all the Math operations available in Hive) as extensions to Siddhi engine. round(DOUBLE a)round(DOUBLE a, INT d)floor(DOUBLE a)ceil(DOUBLE a), ceiling(DOUBLE a)rand(), rand(INT seed)exp(DOUBLE a), exp(DECIMAL a)ln(DOUBLE a), ln(DECIMAL a)log10(DOUBLE a), log10(DECIMAL a)log2(DOUBLE a), log2(DECIMAL a)log(DOUBLE base, DOUBLE a) log(DECIMAL base, DECIMAL a)pow(DOUBLE a, DOUBLE p), power(DOUBLE a, DOUBLE p)sqrt(DOUBLE a), sqrt(DECIMAL a)bin(BIGINT a)hex(BIGINT a) hex(STRING a) hex(BINARY a)unhex(STRING a)conv(BIGINT num, INT from_base, INT to_base), conv(STRING num, INT from_base, INT to_base)abs(DOUBLE a)pmod(INT a, INT b), pmod(DOUBLE a, DOUBLE b)sin(DOUBLE a), sin(DECIMAL a)asin(DOUBLE a), asin(DECIMAL a)cos(DOUBLE a), cos(DECIMAL a)acos(DOUBLE a), acos(DECIMAL a)tan(DOUBLE a), tan(DECIMAL a)atan(DOUBLE a), atan(DECIMAL a)degrees(DOUBLE a), degrees(DECIMAL a)radians(DOUBLE a), radians(DOUBLE a)positive(INT a), positive(DOUBLE a)negative(INT a), negative(DOUBLE a)sign(DOUBLE a), sign(DECIMAL a)e()pi() Eg:You can use the operations as below: *from InStreamSample1* *select custom:pi()* *insert into OutStreamSample1;* *from InStreamSample1* *select custom:tan(parameter1)* *insert into OutStreamSample1;* *from InStreamSample1* *select custom:pmod(parameter1,parameter2)* *insert into OutStreamSample1;* We used built-in math operations available in java.lang.Math package and we have implemented the operations which are not available in the mentioned package (eg: pmod, positive,negative,unhex etc). Separate classes were created for each math operation/extension and custom function names are as same as the operation names in java.lang.Math. Appreciate if someone could point out if there are any other missing/needed operations or any improvements regarding this.. Thanks, -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sanjiva Weerawarana, Ph.D. Founder, Chairman CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Extensions for Siddhi - Math operations
Hi, We have implemented below Math operations (all the Math operations available in Hive) as extensions to Siddhi engine. round(DOUBLE a)round(DOUBLE a, INT d)floor(DOUBLE a)ceil(DOUBLE a), ceiling(DOUBLE a)rand(), rand(INT seed)exp(DOUBLE a), exp(DECIMAL a)ln(DOUBLE a), ln(DECIMAL a)log10(DOUBLE a), log10(DECIMAL a)log2(DOUBLE a), log2(DECIMAL a)log(DOUBLE base, DOUBLE a) log(DECIMAL base, DECIMAL a)pow(DOUBLE a, DOUBLE p), power(DOUBLE a, DOUBLE p)sqrt(DOUBLE a), sqrt(DECIMAL a)bin(BIGINT a)hex(BIGINT a) hex(STRING a) hex(BINARY a)unhex(STRING a)conv(BIGINT num, INT from_base, INT to_base), conv(STRING num, INT from_base, INT to_base)abs(DOUBLE a)pmod(INT a, INT b), pmod(DOUBLE a, DOUBLE b)sin(DOUBLE a), sin(DECIMAL a)asin(DOUBLE a), asin(DECIMAL a)cos(DOUBLE a), cos(DECIMAL a)acos(DOUBLE a), acos(DECIMAL a)tan(DOUBLE a), tan(DECIMAL a)atan(DOUBLE a), atan(DECIMAL a)degrees(DOUBLE a), degrees(DECIMAL a)radians(DOUBLE a), radians(DOUBLE a)positive(INT a), positive(DOUBLE a)negative(INT a), negative(DOUBLE a)sign(DOUBLE a), sign(DECIMAL a)e()pi() Eg:You can use the operations as below: *from InStreamSample1* *select custom:pi()* *insert into OutStreamSample1;* *from InStreamSample1* *select custom:tan(parameter1)* *insert into OutStreamSample1;* *from InStreamSample1* *select custom:pmod(parameter1,parameter2)* *insert into OutStreamSample1;* We used built-in math operations available in java.lang.Math package and we have implemented the operations which are not available in the mentioned package (eg: pmod, positive,negative,unhex etc). Separate classes were created for each math operation/extension and custom function names are as same as the operation names in java.lang.Math. Appreciate if someone could point out if there are any other missing/needed operations or any improvements regarding this.. Thanks, -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154 Hive Math Operations (1).rtf Description: RTF file ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
