From dev-return-16436-archive-asf-public=cust-asf.ponee.io@syncope.apache.org Fri Oct 19 20:54:05 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4F9CE180652 for ; Fri, 19 Oct 2018 20:54:05 +0200 (CEST) Received: (qmail 58647 invoked by uid 500); 19 Oct 2018 18:54:04 -0000 Mailing-List: contact dev-help@syncope.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@syncope.apache.org Delivered-To: mailing list dev@syncope.apache.org Received: (qmail 58636 invoked by uid 99); 19 Oct 2018 18:54:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2018 18:54:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0814A1807B4 for ; Fri, 19 Oct 2018 18:54:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id LplhHOXHDNzY for ; Fri, 19 Oct 2018 18:54:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id B434B5F2FF for ; Fri, 19 Oct 2018 18:54:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id EAE97E0177 for ; Fri, 19 Oct 2018 18:54:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3BF5125292 for ; Fri, 19 Oct 2018 18:54:00 +0000 (UTC) Date: Fri, 19 Oct 2018 18:54:00 +0000 (UTC) From: "DmitriyB. (JIRA)" To: dev@syncope.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (SYNCOPE-1386) Not committed managed objects can get into L2 cache. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SYNCOPE-1386?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:all-tabpanel ] DmitriyB. updated SYNCOPE-1386: ------------------------------- Description:=20 =C2=A0 Hi guys. I noticed the issue that leads to inconsistent data that comes in = response.=C2=A0 =C2=A0 Here is the use-case how to reproduce the problem:=C2=A0 =C2=A0 1. Create user in Syncope=C2=A0 2. Do a request password reset action and make sure that token that is used= for pwd reset action is generated and stored into database.=C2=A0 3. Restart your application to be sure that L2 cache is empty.=C2=A0 4. Confirm password reset action for this user and make sure that requested= password doesn't apply the password rules. In my case password is too shor= t. The exception like "InvalidUser:InvalidPassword: Password too short" sho= uld be thrown.=C2=A0 5. Request the user by username. The user that comes in HTTP Response doesn= 't have "token" and "tokenExpireTime" attributes. But you may find "token" = and "tokenExpireTime" value in SyncopeUser table for this user.=C2=A0 =C2=A0 I also noticed that ~ after 5 minutes left the L2 cache is gone. You can find an example in confirm_pwd_reset_action.sh script. Run this com= mand to execute the script:=C2=A0 "./confirm_pwd_reset_action.sh | tee temp.log"=C2=A0 Here I'm trying to do confirm-password-reset action after 5 minutes of wait= ing with the password that doesn't match the rules. And then I'm requesting= user by username. In response it comes without "token" and "tokenExpireTim= e". =C2=A0 was: |Hi guys. I noticed the issue that leads to inconsitent data that comes in = response.=C2=A0 =C2=A0 In Apache Syncope the Application Scoped Entity manager is used for all ope= rations with the database. Entity manager is created by appropriate Entity = Manager Factory that matches a particular domain. Thus, the scope of Persis= tence Context is extended and also it is bound to a current thread.=C2=A0 Moreover, Entity Manager that is created by Entity Manager Factory is Trans= actional. Thus any execution using entity manager without opened transactio= n leads to exception like:=C2=A0 =C2=A0{code:java} =C2=A0 java.lang.IllegalStateException: Could not find EntityManager for domain db= rashevets=C2=A0 at org.apache.syncope.core.persistence.jpa.dao.AbstractDAO.entityManager(Ab= stractDAO.java:41) ~[syncope-core-persistence-jpa-2.0.8.jar:?]=C2=A0 at org.apache.syncope.core.persistence.jpa.dao.JPAUserDAO.findByUsername(JP= AUserDAO.java:209) ~[syncope-core-persistence-jpa-2.0.8.jar:?]=C2=A0 at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) ~[?:?]=C2= =A0 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor= Impl.java:45005) ~[?:1.8.0_151]=C2=A0 at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]=C2=A0 at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(= AopUtils.java:333) ~[spring-aop-4.3.14.RELEASE.jar:4.3.14.RELEASE]=C2=A0 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo= pProxy.java:207) ~[spring-aop-4.3.14.RELEASE.jar:4.3.14.RELEASE]=C2=A0 at com.sun.proxy.$Proxy74.findByUsername(Unknown Source) ~[?:?]=C2=A0 {code} =C2=A0 =C2=A0 In Apache Syncope L2 cache is enabled by default.=C2=A0 syncope-core-persistence-jpa-2.0.8.jar!\domains.xml file has a property=C2= =A0{code:java} =C2=A0 =C2=A0 {code} =C2=A0 Here is the use-case how to reproduce the problem:=C2=A0 =C2=A0 1. Create user in Syncope=C2=A0 2. Do a request password reset action and make sure that token that is used= for pwd reset action is generated and stored into database.=C2=A0 3. Restart your application to be sure that L2 cache is empty.=C2=A0 4. Confirm password reset action for this user and make sure that requested= password doesn't apply the password rules. In my case password is too shor= t. The exception like "InvalidUser:InvalidPassword: Password too short" sho= uld be thrown.=C2=A0 5. Request the user by username. The user that comes in HTTP Response doesn= 't have "token" and "tokenExpireTime" attributes. But you may find "token" = and "tokenExpireTime" value in SyncopeUser table for this user.=C2=A0 =C2=A0 I also noticed that ~ after 5 minutes left the L2 cache is gone. You can find an example in confirm_pwd_reset_action.sh script. Run this com= mand to execute the scirpt:=C2=A0 "./confirm_pwd_reset_action.sh \| tee temp.log"=C2=A0 Here I'm trying to do confirm-password-reset action after 5 minutes of wait= ing with the password that doesn't match the rules. And then I'm requesting= user by username. In response it comes without "token" and "tokenExpireTim= e". =C2=A0| =C2=A0 > Not committed managed objects can get into L2 cache. > ---------------------------------------------------- > > Key: SYNCOPE-1386 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1386 > Project: Syncope > Issue Type: Bug > Components: core > Affects Versions: 2.0.8 > Reporter: DmitriyB. > Priority: Major > Attachments: confirm_pwd_reset_action.sh > > > =C2=A0 > Hi guys. I noticed the issue that leads to inconsistent data that comes i= n response.=C2=A0 > =C2=A0 > Here is the use-case how to reproduce the problem:=C2=A0 > =C2=A0 > 1. Create user in Syncope=C2=A0 > 2. Do a request password reset action and make sure that token that is us= ed for pwd reset action is generated and stored into database.=C2=A0 > 3. Restart your application to be sure that L2 cache is empty.=C2=A0 > 4. Confirm password reset action for this user and make sure that request= ed password doesn't apply the password rules. In my case password is too sh= ort. The exception like "InvalidUser:InvalidPassword: Password too short" s= hould be thrown.=C2=A0 > 5. Request the user by username. The user that comes in HTTP Response doe= sn't have "token" and "tokenExpireTime" attributes. But you may find "token= " and "tokenExpireTime" value in SyncopeUser table for this user.=C2=A0 > =C2=A0 > I also noticed that ~ after 5 minutes left the L2 cache is gone. > You can find an example in confirm_pwd_reset_action.sh script. Run this c= ommand to execute the script:=C2=A0 > "./confirm_pwd_reset_action.sh | tee temp.log"=C2=A0 > Here I'm trying to do confirm-password-reset action after 5 minutes of wa= iting with the password that doesn't match the rules. And then I'm requesti= ng user by username. In response it comes without "token" and "tokenExpireT= ime". > =C2=A0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)