For your use case, the time between these actions cannot be a very long period. So, you should be using a regular cache with a timeout.
Azeez On Sun, Oct 19, 2014 at 11:22 AM, Firzhan Naqash <firz...@wso2.com> wrote: > Hi, > > This random password will only be used to populate the connection password > field in the secondary store web ui. This password will be generated when > the user presses the edit button and it will be removed when the user > completes "update" operation. This password is merely used to populate the > connection password field ( Because leaving it blank forces the user to > type it each and every time when ever he edits other properties also ). > > > When the request comes to back end, we remove that random value and store > the original password in to config file. > > @Darshana > > Since this usage violates the security best practices, shall we restrict > the cache invalidation time for an hour ? > > Regards, > Firzhan > > On Sun, Oct 19, 2014 at 11:14 AM, Afkham Azeez <az...@wso2.com> wrote: > >> >> >> On Sun, Oct 19, 2014 at 1:12 AM, Firzhan Naqash <firz...@wso2.com> wrote: >> >>> >>> Hi All, >>> >>> Let me explain the use case that I am trying to implement. >>> >>> Currently the secondary user store web ui does not displaying the >>> "connection password" property . If a user wanted to edit some properties, >>> before updating those properties, user have to type the connection password >>> again. >>> >>> As a solution for this we are trying to generate a random password and >>> assign an an unique ID for that password. This unique ID will be associated >>> with that particular edit request message for identifying the random >>> password. This unique ID should be unique across the cluster. This random >>> password will be displayed in the "connection password" field. Therefore >>> the editUserStoreConfiguration message will include unique ID + >>> properties. >>> >>> Once user done with updating other properties ( No password change), he >>> can send the updateUserStoreConfiguration message. Since the update >>> UserStoreConfiguration message has an unique ID, by using that ID we >>> can obtain the random password and do a comparison with the password that >>> comes with the request. If there are any changes, new password will be >>> encrypted and saved with other changes to the secondary store configuration >>> file. >>> >>> In order to support non-sticky session scenarios, we need that >>> particular unique ID and random password to be shared across the cluster. >>> Do I have to persist this information ? Or is it ok to use javax.cache's >>> expiry time set for longer duration ? >>> >> >> You want to maintain this random password indefinitely? Production >> clusters could run for years without being shutdown. Even when it comes to >> normal passwords, users are required to frequently change it, but you want >> to keep a random password forever? That would violate security best >> practices. >> >> >>> >>> >>> Regards, >>> Firzhan >>> >>> On Sat, Oct 18, 2014 at 7:13 PM, Afkham Azeez <az...@wso2.com> wrote: >>> >>>> If this doesn't get invalidated, why do you need a cache or distributed >>>> map? Why not simply store it and load it from registry, and keep it in >>>> memory? >>>> >>>> On Sat, Oct 18, 2014 at 5:42 PM, Johann Nallathamby <joh...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Oct 17, 2014 at 9:52 AM, Darshana Gunawardana < >>>>> darsh...@wso2.com> wrote: >>>>> >>>>>> Hi Azeez, >>>>>> >>>>>> What it needs here is a distributed map which get synced among nodes >>>>>> in the cluster. >>>>>> >>>>>> 1. What would be the best way to do that? Using a Hazelcast >>>>>> distributed map? >>>>>> 2. If Hazelcast distributed map is a option, do we have a way to use >>>>>> a Hazelcast map when writing a component using 4.2.0 kernel. >>>>>> >>>>> >>>>> I don't see any difference between using javax.cache.Cache and >>>>> distributed map except that cache has a timeout. But you can set the >>>>> timeout to a large value and that makes it no different to distributed >>>>> map. >>>>> Anyway we can't rely on both of them for HA if entire cluster goes down. >>>>> In >>>>> that case we need to persist. So +1 for javax.cache.Cache. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Darshana >>>>>> >>>>>> On Fri, Oct 17, 2014 at 9:31 AM, Afkham Azeez <az...@wso2.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 17, 2014 at 12:44 AM, Firzhan Naqash <firz...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Are there any specific way to make sure that cache doesn't get >>>>>>>> invalidated other than setting a longer duration in the setExpiry() >>>>>>>> method >>>>>>>> of CacheBuilder ? >>>>>>>> >>>>>>> >>>>>>> No you have to set a large cache expiry time >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Firzhan >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Afkham Azeez* >>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>> * <http://www.apache.org/>* >>>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>> <http://twitter.com/afkham_azeez> >>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>> >>>>>>> *Lean . Enterprise . Middleware* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> Dev@wso2.org >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> >>>>>> *Darshana Gunawardana*Software Engineer >>>>>> WSO2 Inc.; http://wso2.com >>>>>> >>>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>>>>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> >>>>> *Johann Dilantha Nallathamby* >>>>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>>>> Integration Technologies Team >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - *+94777776950* >>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **az...@wso2.com* <az...@wso2.com> >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **az...@wso2.com* <az...@wso2.com> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **az...@wso2.com* <az...@wso2.com> * cell: +94 77 3320919blog: **http://blog.afkham.org* <http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez* <http://twitter.com/afkham_azeez> *linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
