From dev-return-16422-archive-asf-public=cust-asf.ponee.io@syncope.apache.org Fri Oct 19 20:04:04 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 3574C180679 for ; Fri, 19 Oct 2018 20:04:04 +0200 (CEST) Received: (qmail 39849 invoked by uid 500); 19 Oct 2018 18:04:03 -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 39838 invoked by uid 99); 19 Oct 2018 18:04:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Oct 2018 18:04:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id DF4E2CC9F8 for ; Fri, 19 Oct 2018 18:04:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-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 (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id SbYGOEsLWWKW for ; Fri, 19 Oct 2018 18:04:01 +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 2801D5F381 for ; Fri, 19 Oct 2018 18:04: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 5C1CCE0E87 for ; Fri, 19 Oct 2018 18:04: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 2289625291 for ; Fri, 19 Oct 2018 18:04:00 +0000 (UTC) Date: Fri, 19 Oct 2018 18:04: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 Hi guys. I noticed the issue that leads to inconsistent data that comes in = HTTP response. =C2=A0 In Apache Syncope L2 cache is enabled by default.=20 syncope-core-persistence-jpa-2.0.8.jar!\domains.xml file has a property {code:java} {code} If the transaction is opened, the entity, that is fetched via Entity Manage= r with the method like org.apache.syncope.core.persistence.api.dao.UserDAO#findByUsername, gets in= to L1 cache and L2 cache. Than retrieved JPA entity can be modified in the scope of an opened transac= tion. And if an exception occurs transaction is rolled back. L1 cache is be= ing destroyed because Entity Manager is bound to a current thread, but L2 c= ache can have this managed entity.=20 It means that furtherly going HTTP requests can retrieve this corrupted ent= ity from L2 cache. Here is the use-case how to reproduce this: 1. Create user in Syncope 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. 3. Restart your application to be sure that L2 cache is empty. 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.=20 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. In our application that is based on Syncope 2.0.8, I always clean the L2 ca= che when transaction is rolled back in org.apache.syncope.core.persistence.jpa.spring.DomainTransactionInterceptor= . _invoke(..)_ method looks like this: {code:java} @Override public Object invoke(final MethodInvocation invocation) throws Throwable { try { return super.invoke(invocation); } catch (Throwable e) { EntityManagerFactory entityManagerFactory =3D EntityManagerFactoryUtils.fin= dEntityManagerFactory( ApplicationContextProvider.getBeanFactory(), AuthContextUtils.getDomain()); Cache l2Cache =3D entityManagerFactory.getCache(); if (l2Cache !=3D null) { l2Cache.evictAll(); } LOG.debug("Error during {} invocation", invocation.getMethod(), e); throw e; } } {code} This is the guarantee for that corrected data won't come in response, but I= 'm destroying the cache all the time when exception is thrown from one of @= Transactional methods. You can find an example in confirm_pwd_reset_action.sh script. You can run = it by executing the command: "./confirm_pwd_reset_action.sh | tee temp.log" 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". was: Hi guys. I noticed the issue that leads to inconsitent data that comes in H= TTP response. 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. 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 (which is fine): {code:java} java.lang.IllegalStateException: Could not find EntityManager for domain db= rashevets at org.apache.syncope.core.persistence.jpa.dao.AbstractDAO.entityManager(Ab= stractDAO.java:41) ~[syncope-core-persistence-jpa-2.0.8.jar:?] at org.apache.syncope.core.persistence.jpa.dao.JPAUserDAO.findByUsername(JP= AUserDAO.java:209) ~[syncope-core-persistence-jpa-2.0.8.jar:?] at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor= Impl.java:45005) ~[?:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151] at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(= AopUtils.java:333) ~[spring-aop-4.3.14.RELEASE.jar:4.3.14.RELEASE] at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo= pProxy.java:207) ~[spring-aop-4.3.14.RELEASE.jar:4.3.14.RELEASE] at com.sun.proxy.$Proxy74.findByUsername(Unknown Source) ~[?:?] {code} In Apache Syncope L2 cache is enabled by default.=20 syncope-core-persistence-jpa-2.0.8.jar!\domains.xml file has a property {code:java} {code} If the transaction is opened, the entity, that is fetched via Entity Manage= r with the method like org.apache.syncope.core.persistence.api.dao.UserDAO#findByUsername, gets in= to L1 cache and L2 cache. Than retrieved JPA entity can be modified in the scope of an opened transac= tion. And if an exception occurs transaction is rolled back. L1 cache is be= ing destroyed because Entity Manager is bound to a current thread, but L2 c= ache can have this managed entity.=20 It means that furtherly going HTTP requests can retrieve this corrupted ent= ity from L2 cache. Here is the use-case how to reproduce this: 1. Create user in Syncope 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. 3. Restart your application to be sure that L2 cache is empty. 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.=20 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. In our application that is based on Syncope 2.0.8, I always clean the L2 ca= che when transaction is rolled back in org.apache.syncope.core.persistence.jpa.spring.DomainTransactionInterceptor= . _invoke(..)_ method looks like this: {code:java} @Override public Object invoke(final MethodInvocation invocation) throws Throwable { try { return super.invoke(invocation); } catch (Throwable e) { EntityManagerFactory entityManagerFactory =3D EntityManagerFactoryUtils.fin= dEntityManagerFactory( ApplicationContextProvider.getBeanFactory(), AuthContextUtils.getDomain()); Cache l2Cache =3D entityManagerFactory.getCache(); if (l2Cache !=3D null) { l2Cache.evictAll(); } LOG.debug("Error during {} invocation", invocation.getMethod(), e); throw e; } } {code} This is the guarantee for that corrected data won't come in response, but I= 'm destroying the cache all the time when exception is thrown from one of @= Transactional methods. You can find an example in confirm_pwd_reset_action.sh script. You can run = it by executing the command: "./confirm_pwd_reset_action.sh | tee temp.log" 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". > 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 > > > Hi guys. I noticed the issue that leads to inconsistent data that comes i= n HTTP response. > =C2=A0 > In Apache Syncope L2 cache is enabled by default.=20 > syncope-core-persistence-jpa-2.0.8.jar!\domains.xml file has a property > {code:java} > > {code} > If the transaction is opened, the entity, that is fetched via Entity Mana= ger with the method like > org.apache.syncope.core.persistence.api.dao.UserDAO#findByUsername, gets = into L1 cache and L2 cache. > Than retrieved JPA entity can be modified in the scope of an opened trans= action. And if an exception occurs transaction is rolled back. L1 cache is = being destroyed because Entity Manager is bound to a current thread, but L2= cache can have this managed entity.=20 > It means that furtherly going HTTP requests can retrieve this corrupted e= ntity from L2 cache. > Here is the use-case how to reproduce this: > 1. Create user in Syncope > 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. > 3. Restart your application to be sure that L2 cache is empty. > 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.=20 > 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. > In our application that is based on Syncope 2.0.8, I always clean the L2 = cache when transaction is rolled back in > org.apache.syncope.core.persistence.jpa.spring.DomainTransactionIntercept= or. _invoke(..)_ method looks like this: > {code:java} > @Override > public Object invoke(final MethodInvocation invocation) throws Throwable = { > try { > return super.invoke(invocation); > } catch (Throwable e) { > EntityManagerFactory entityManagerFactory =3D EntityManagerFactoryUtils.f= indEntityManagerFactory( > ApplicationContextProvider.getBeanFactory(), AuthContextUtils.getDomain()= ); > Cache l2Cache =3D entityManagerFactory.getCache(); > if (l2Cache !=3D null) { > l2Cache.evictAll(); > } > LOG.debug("Error during {} invocation", invocation.getMethod(), e); > throw e; > } > } > {code} > This is the guarantee for that corrected data won't come in response, but= I'm destroying the cache all the time when exception is thrown from one of= @Transactional methods. > You can find an example in confirm_pwd_reset_action.sh script. You can ru= n it by executing the command: > "./confirm_pwd_reset_action.sh | tee temp.log" > 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". -- This message was sent by Atlassian JIRA (v7.6.3#76005)