Re: Urgent: updated pull using dbscript
Full On 27/04/17 09:09, Marco Di Sabatino Di Diodoro wrote: Il 26/04/2017 23:10, Tech ha scritto: Hello, we are using the dbscripts to pull information from a database, but we detected that if any change occurs, for example an email address has been modified, the pull task is no able to detect the change and to re-update the new value into Syncope. Is there any parameter somewhere that should be configure to have this done? Which kind of pull are you doing? Full or incremental? Regards M Thanks -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Re: Disable captcha
No, sorry, we saw that the captcha is working differently in version 203, it's not a bug On 26/04/17 19:02, Tech wrote: Hello, there is a small bug in the enduser interface. You can enable or disable the captcha from line 361, but after this result is overwritten by line 374. To resolve we enter twice "false". Regards
Adding new fields over a MariaDB
Hello, using the Syncope 203, when we try to add a new type, we get this error at the moment of saving the change. Here we just try to add an additional email with an EmailValidator, but this happen with any new field that we try to add. Regars 17:11:15.595 ERROR org.apache.syncope.core.rest.cxf.RestServiceExceptionMapper - Exception thrown org.springframework.orm.jpa.JpaSystemException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred.; nested exception is general error> org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. FailedObject: org.apache.syncope.core.persistence.jpa.entity.JPAPlainSchema@ebe52d1 at org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:418) ~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:122) ~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:521) ~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) ~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) ~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:504) ~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292) ~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) ~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.apache.syncope.core.persistence.jpa.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64) ~[syncope-core-persistence-jpa-2.0.3.jar:2.0.3] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) ~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:656) ~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE] at org.apache.syncope.core.logic.SchemaLogic$$EnhancerBySpringCGLIB$$9787cf5b.create() ~[syncope-core-logic-2.0.3.jar:2.0.3] at org.apache.syncope.core.rest.cxf.service.SchemaServiceImpl.create(SchemaServiceImpl.java:41) ~[syncope-core-rest-cxf-2.0.3.jar:2.0.3] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_111] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_111] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_111] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_111] at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:189) ~[cxf-rt-frontend-jaxrs-3.1.11.jar:3.1.11] at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99) ~[cxf-rt-frontend-jaxrs-3.1.11.jar:3.1.11] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) ~[cxf-core-3.1.11.jar:3.1.11] at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:262) ~[cxf-rt-transports-http-3.1.11.jar:3.1.11] at
Disable captcha
Hello, there is a small bug in the enduser interface. You can enable or disable the captcha from line 361, but after this result is overwritten by line 374. To resolve we enter twice "false". Regards
Re: Invalid character CR/LF
Hello,
might we ask to any of you to try a test for us using MariaDB and
Syncope 203:
Create any resource from the Topology interface and try to create and
save any Pull/Push task.
We get with the same problem, we tried also to redeploy over a database
with:
* lower_case_table_name=1
and
* table_definition_cache 16384
* table_open_cache 32162
as suggested, but the result didn't change
On 24/04/17 10:13, Fabio Martelli wrote:
Il 20/04/2017 11:49, Tech ha scritto:
The core is empty, but the core-rest displays this:
09:46:52.952 ERROR
org.apache.syncope.core.rest.cxf.RestServiceExceptionMapper -
Exception thrown
org.springframework.orm.jpa.JpaSystemException: (conn:120) Prepared
statement needs to be re-prepared
Hi, it seems you have some trouble with your DB.
If you are using MySQL or MariaDB, please check for
table_definition_cache configuration parameter value.
Can I suggest you to try out with:
table_definition_cache16384
table_open_cache 32162
table_open_cache_instances 4
Best regards,
F.
Query is: SELECT u.any_id FROM (SELECT DISTINCT any_id FROM
user_search WHERE id IS NOT NULL) u WHERE u.any_id IN (SELECT any_id
FROM user_search WHERE realm_id IN (SELECT id AS realm_id FROM Realm
WHERE id=? OR id=?)), parameters
['ea696a4f-e77a-4ef1-be67-8f8093bc8686','c08b745e-959e-49cd-8b74-5e959e29cde9']
{prepstmnt 158175468 SELECT u.any_id FROM (SELECT DISTINCT any_id
FROM user_search WHERE id IS NOT NULL) u WHERE u.any_id IN (SELECT
any_id FROM user_search WHERE realm_id IN (SELECT id AS realm_id FROM
Realm WHERE id=? OR id=?))} [code=1615, state=HY000]; nested
exception is
org.apache.openjpa.persistence.PersistenceException: (conn:120)
Prepared statement needs to be re-prepared
Query is: SELECT u.any_id FROM (SELECT DISTINCT any_id FROM
user_search WHERE id IS NOT NULL) u WHERE u.any_id IN (SELECT any_id
FROM user_search WHERE realm_id IN (SELECT id AS realm_id FROM Realm
WHERE id=? OR id=?)), parameters
['ea696a4f-e77a-4ef1-be67-8f8093bc8686','c08b745e-959e-49cd-8b74-5e959e29cde9']
{prepstmnt 158175468 SELECT u.any_id FROM (SELECT DISTINCT any_id
FROM user_search WHERE id IS NOT NULL) u WHERE u.any_id IN (SELECT
any_id FROM user_search WHERE realm_id IN (SELECT id AS realm_id FROM
Realm WHERE id=? OR id=?))} [code=1615, state=HY000]
at
org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:418)
~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:122)
~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:521)
~[spring-orm-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:504)
~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292)
~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
~[spring-tx-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.apache.syncope.core.persistence.jpa.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64)
~[syncope-core-persistence-jpa-2.0.3.jar:2.0.3]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:656)
~[spring-aop-4.3.7.RELEASE.jar:4.3.7.RELEASE]
at
org.apache.syncope.core.logic.UserLogic$$EnhancerBySpringCGLIB$$2dba5184.search()
~[syncope-core-logic-2.0.3.jar:2.0.3]
at
org.apache.syncope.core.rest.cxf.service.AbstractAnyService.search(AbstractAnyService.java:134)
~[syncope-core-rest-cxf-2.0.3.jar:2.0.3]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) ~[?:1.8.0_111
Re: DataIntegrityViolation [The transaction has been rolled back..
Hello, also changing the lower_case_table_names the problem remains. The problem is that now all the tables in Syncope changed their names, while the connectors, like active directory still point to the old format, making them unusable. Could you please give it a look? Thanks On 13/04/17 15:28, Marco Di Sabatino Di Diodoro wrote: Hi, Il 13/04/2017 14:15, Tech ha scritto: Hello, I guess that is finally a bug: this is related with the version of the DB/JDBC connector used. We entered into the logs and we saw that there are several errors for "table not found": this is due to the fact that the tables are declared in uppercase, while are stored in Lowercase into the database. Per construction of some DB/JDBC, MariaDB distinguishes also the case sensitivity of the tables names, so the tables are marked as "not found". Just as an experiment, we changed by hand the table names and now looks working. Your database is case sensitive. So If you are using always the same platform, you don't have this kind of problems. However, you may encounter difficulties if you want to transfer configurations between platforms that differ in file system case sensitivity. So there are two options to solve your errors: * Convert MasterContent.xml using the real name of the tables and columns, respecting upper and lower case (you can find at this link [1] the test MasterContent.xml that respects the format and can be loaded anywhere). * If you don't want to convert the file, another solution for MariaDB is to add lower_case_table_names=1 property in my.cnf. Regards Marco [1] https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/test/resources/domains/MasterContent.xml Hope that helps and thanks for the support On 11/04/17 15:37, Fabio Martelli wrote: Hi, it seems it was not a real bug. If you are on linux, pay attention to the default character encoding "character-set-server": utf8mb4 is not compatible with Apache Syncope >2.0.3. BTW, I think your DataIntegrityViolation is not due to the problem above. I've just been able to replicate your issue by using MariaDB 10.0 and Java connector 1.5.9. It seems that there are a sort of incompatibility that affect certain insert statement. I solved the problem by changing the java connector version: MariaDB 10.0 and JConnector 1.4.6 seem to work fine together. Please, find your compatible versions, drop and recreate your db and check it out again. Best regards, F. Il 10/04/2017 16:50, Fabio Martelli ha scritto: Hi, it seems we have a bug. See the issue [1]; it will be solved ASAP. Thank you for reporting. Regards, F. [1] https://issues.apache.org/jira/browse/SYNCOPE-1065 Il 10/04/2017 12:35, Tech ha scritto: Dear experts, We are working with the Syncope 2.0.3-SNAPSHOT, we are doing nothing but changing the default database, from Postgres to MariaDB. We compile and we start a brand new Syncope deployment with a new empty database. We are able to create users, but we every time we try to create a new Type, we get an error "DataIntegrityViolation [The transaction has been rolled back.." and we cannot add any other type. Have you any idea why this could happen? -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Re: Invalid character CR/LF
) ~[tomcat-coyote.jar:8.0.43] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_111] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-util.jar:8.0.43] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111] On 20/04/17 11:36, Fabio Martelli wrote: Hi, please send core logs as well. Regards, F. Il 20/04/2017 11:28, Tech ha scritto: Hello, with Syncope 203 we are facing this error in several part of the console: "*Invalid character CR/LF*". After this is occurring we are pushed back to the login page of the admin console. For example, we open the Realm page, from there we click on Users and we are back to the login page where there is a red label saying "*Error while contacting Syncope core*". Here down what we found in the console.log /org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = body]]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1848) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.markup.html.form.Form.onBeforeRender(Form.java:1809) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.onBeforeRender(Component.java:3916) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.internalBeforeRender(Component.java:950) ~[wicket-core-7.6.0.jar:7.6.0]// //at org.apache.wicket.Component.beforeRender(Component.java:1018) ~[w
Re: Implementing an action in 203
Thank you Marco On 20/04/17 10:47, Marco Di Sabatino Di Diodoro wrote: Hi Il 20/04/2017 10:00, Tech ha scritto: Any ideas? On 19/04/17 16:02, Tech wrote: Dear experts, we are working with the version 203 of Syncope and we would like to implement an Action: From the package org.apache.syncope.core.provisioning.java we extended DefaultLogicActions. We copied our source into core/src/java/org/apache/syncope/core/provisioning/java, we compiled, no errors, but the class seems not appearing from the Console/Realm/Actions, while we have only the default one: DefaultLogicActions your package is not correct, please change the package into core/src/main/java/org/apache/syncope/core/provisioning/java Regards M What are the additional missing steps? Thanks
Implementing an action in 203
Dear experts, we are working with the version 203 of Syncope and we would like to implement an Action: From the package org.apache.syncope.core.provisioning.java we extended DefaultLogicActions. We copied our source into core/src/java/org/apache/syncope/core/provisioning/java, we compiled, no errors, but the class seems not appearing from the Console/Realm/Actions, while we have only the default one: DefaultLogicActions What are the additional missing steps? Thanks
Re: DataIntegrityViolation [The transaction has been rolled back..
Hello, I guess that is finally a bug: this is related with the version of the DB/JDBC connector used. We entered into the logs and we saw that there are several errors for "table not found": this is due to the fact that the tables are declared in uppercase, while are stored in Lowercase into the database. Per construction of some DB/JDBC, MariaDB distinguishes also the case sensitivity of the tables names, so the tables are marked as "not found". Just as an experiment, we changed by hand the table names and now looks working. Hope that helps and thanks for the support On 11/04/17 15:37, Fabio Martelli wrote: Hi, it seems it was not a real bug. If you are on linux, pay attention to the default character encoding "character-set-server": utf8mb4 is not compatible with Apache Syncope >2.0.3. BTW, I think your DataIntegrityViolation is not due to the problem above. I've just been able to replicate your issue by using MariaDB 10.0 and Java connector 1.5.9. It seems that there are a sort of incompatibility that affect certain insert statement. I solved the problem by changing the java connector version: MariaDB 10.0 and JConnector 1.4.6 seem to work fine together. Please, find your compatible versions, drop and recreate your db and check it out again. Best regards, F. Il 10/04/2017 16:50, Fabio Martelli ha scritto: Hi, it seems we have a bug. See the issue [1]; it will be solved ASAP. Thank you for reporting. Regards, F. [1] https://issues.apache.org/jira/browse/SYNCOPE-1065 Il 10/04/2017 12:35, Tech ha scritto: Dear experts, We are working with the Syncope 2.0.3-SNAPSHOT, we are doing nothing but changing the default database, from Postgres to MariaDB. We compile and we start a brand new Syncope deployment with a new empty database. We are able to create users, but we every time we try to create a new Type, we get an error "DataIntegrityViolation [The transaction has been rolled back.." and we cannot add any other type. Have you any idea why this could happen?
Re: Validate occurred propagation
Hello, I'm not talking about the user status, but the resource status. When you provision a resource and you open the user profile, you will see "Resource1(v)" In the case there is a problem the resource will appear as "Resource1 (x)". I want to understand what is the information to turn the X into V On 04.04.17 10:05, Marco Di Sabatino Di Diodoro wrote: Hi Il 04/04/2017 09:49, Tech ha scritto: Dear experts, we are working with Rest and provisioning accounts to a Ws. We are able to correctly create remotely the resource, but we are not able to mark into the system that the propagation correctly occurred (from the Admin Console we still see the resource marked with (x) instead of (v), that means that the update events will be discarded). What is the information that we should provide to Syncope to make it understand the real status of the propagation? What do you mean for status? User status or if the user is properly propagated on the resource? To check the user status from an user, you must return __ENABLE__ attribute, if you can not retrieve the user from the resource, you have an error in your mapping or in the configuration of your connector. Check if the accountId attribute in the resource mapping match the key in your resource. Regards M Thanks
Validate occurred propagation
Dear experts, we are working with Rest and provisioning accounts to a Ws. We are able to correctly create remotely the resource, but we are not able to mark into the system that the propagation correctly occurred (from the Admin Console we still see the resource marked with (x) instead of (v), that means that the update events will be discarded). What is the information that we should provide to Syncope to make it understand the real status of the propagation? Thanks
Re: REST Web Service
We are still working on the Rest connector.
Modifying the CreateScript.groovy we inserted some log and we detected
that we are not able to retrieve any id information.
From the logs we have the feeling that the "
node.set("key",node.textNode(id)) " is not able to retrieve any value:
we can read the information about the user like firstname, surname, etc,
but we get a UnsupportedOperationException when we try to run the key =
node.get(¨key¨).textValue();
where the key is "null" and we are not able to correctly create the
value key.
We want to mention that we are not able yet to arrive to contact the
REST ws, we still need to get out from Syncope.
Thanks
On 29.03.17 20:34, Tech wrote:
Hello Francesco,
thanks for the reply, and actually the tips of the
ReloadScriptOnExecution was really useful to debug the code.
Regards
On 21.03.17 08:59, Francesco Chicchiriccò wrote:
On 20/03/2017 15:45, Tech wrote:
Dear experts,
we are trying to configure a REST Web Service, but we don't how it
should be deployed.
We found in the /test directory some groovy script to
Create/Update/etc, but we don't understand in a real environment
where these script should be copied before compiling.
Hi,
both the Scripted REST [1] and the Scripted SQL [2] connector bundles
share the same approach: the actual implementation of the ConnId
operations (e.g. the child classes of [3], as CREATE, UPDATE, DELETE,
SEARCH, SYNC, AUTHENTICATE, ...) is delegated to individual Groovy
scripts.
The immediate benefit of this approach is that you can adapt the
actual logic for dealing with a specific REST service or a given
database, thus achieving the maximum flexibility; the downside is
that you need to code the scripts, and this requires some skills.
You can find some samples of scripts for the REST connector in the
folder
core/src/test/resources/rest
of your generated Maven project, or at [4], and scripts for the
Scripted SQL connector in the folder
core/src/test/resources/scriptedsql
of your generated Maven project, or at [5].
As you can easily figure out, the actual script content only makes
sense when dealing with the specific REST service / database they
were designed for, e.g. [6] and [7] respectively.
An important feature for speeding up the development of these scripts
is the 'Reload Script On Execution' connector property: when set to
true, each script is reloaded and recompiled every time it is called,
e.g. every time that the corresponding ConnId operation is invoked by
Syncope.
In this way one can immediately check if the script is running fine
or find out errors.
Please do not forge to disable this property once running in production!
Finally, consider that each script can be passed - in the connector
configuration - either as actual content or as absolute file path:
this is the reason why there are "Create Script" and "Create Script
Filename", "Update Script" and "Update Script Filename", etc.
Hope this clarifies.
Regards.
[1] https://connid.atlassian.net/wiki/display/BASE/REST
[2] https://connid.atlassian.net/wiki/display/BASE/Scripted+SQL
[3]
http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/spi/operations/SPIOperation.html
[4]
https://github.com/apache/syncope/tree/2_0_X/fit/core-reference/src/test/resources/rest
[5]
https://github.com/apache/syncope/tree/2_0_X/fit/core-reference/src/test/resources/scriptedsql
[6]
https://github.com/apache/syncope/blob/2_0_X/fit/build-tools/src/main/java/org/apache/syncope/fit/buildtools/cxf/UserService.java
[7]
https://github.com/apache/syncope/blob/2_0_X/fit/build-tools/src/main/resources/testdb.sql#L46-L51
Re: REST Web Service
Hello Francesco, thanks for the reply, and actually the tips of the ReloadScriptOnExecution was really useful to debug the code. Regards On 21.03.17 08:59, Francesco Chicchiriccò wrote: On 20/03/2017 15:45, Tech wrote: Dear experts, we are trying to configure a REST Web Service, but we don't how it should be deployed. We found in the /test directory some groovy script to Create/Update/etc, but we don't understand in a real environment where these script should be copied before compiling. Hi, both the Scripted REST [1] and the Scripted SQL [2] connector bundles share the same approach: the actual implementation of the ConnId operations (e.g. the child classes of [3], as CREATE, UPDATE, DELETE, SEARCH, SYNC, AUTHENTICATE, ...) is delegated to individual Groovy scripts. The immediate benefit of this approach is that you can adapt the actual logic for dealing with a specific REST service or a given database, thus achieving the maximum flexibility; the downside is that you need to code the scripts, and this requires some skills. You can find some samples of scripts for the REST connector in the folder core/src/test/resources/rest of your generated Maven project, or at [4], and scripts for the Scripted SQL connector in the folder core/src/test/resources/scriptedsql of your generated Maven project, or at [5]. As you can easily figure out, the actual script content only makes sense when dealing with the specific REST service / database they were designed for, e.g. [6] and [7] respectively. An important feature for speeding up the development of these scripts is the 'Reload Script On Execution' connector property: when set to true, each script is reloaded and recompiled every time it is called, e.g. every time that the corresponding ConnId operation is invoked by Syncope. In this way one can immediately check if the script is running fine or find out errors. Please do not forge to disable this property once running in production! Finally, consider that each script can be passed - in the connector configuration - either as actual content or as absolute file path: this is the reason why there are "Create Script" and "Create Script Filename", "Update Script" and "Update Script Filename", etc. Hope this clarifies. Regards. [1] https://connid.atlassian.net/wiki/display/BASE/REST [2] https://connid.atlassian.net/wiki/display/BASE/Scripted+SQL [3] http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/spi/operations/SPIOperation.html [4] https://github.com/apache/syncope/tree/2_0_X/fit/core-reference/src/test/resources/rest [5] https://github.com/apache/syncope/tree/2_0_X/fit/core-reference/src/test/resources/scriptedsql [6] https://github.com/apache/syncope/blob/2_0_X/fit/build-tools/src/main/java/org/apache/syncope/fit/buildtools/cxf/UserService.java [7] https://github.com/apache/syncope/blob/2_0_X/fit/build-tools/src/main/resources/testdb.sql#L46-L51
Tasks synchronization
Dear experts, We are trying to work on the process synchronization between two different resources. We pull data from a resource and we push data to another resource What we detected is this scenario that we tried to resolve using the "Priority", increasing it for example to 5 on resource2, but without success. The scenario: * We create User1 in resource1, the resource is pulled to Syncope and created in resource2 (everything as expected) * We change the email to email1, syncope is registering the change as email1, nothing else happen. * We change the email to email2, syncope is registering the change as email2, but it's pushing email1 to resource2. * We change the email to email3, syncope is registering the change as email3, but it's pushing email2 to resource2. How can we delay the propagation of the email to have them synchronized in all systems?
Re: Assign group to user from DB
Just checked: the code is correct, but should be just positioned into
the beforeProvisioning, now it's correctly working.
Thanks for the support!
On 27.03.17 17:53, Tech wrote:
As described at the beginning of the thread, we have a pull process
taking information from a database.
We associated the code to the action to take on the pull.
We want to pull the user into the system and to associate it to the
role based on the specific column.
As far as I understand now we should just use userpatch but put it in
BeforeProvisioning instead of BeforeUpdate?
Thanks
On 27.03.17 17:41, Marco Di Sabatino Di Diodoro wrote:
Il 27/03/2017 17:12, Tech ha scritto:
We used the After because we realized that in the first time we run
the code the users were just created and only in the second time the
code was executed the users were associated to the groups, while we
wanted to have everything done at the same time.
"we run the code the users were just created"
during a create you must work with beforeProvisioning or beforeAssing
"in the second time"
What do you mean with this? You run sync task again?
Here the code:
@Transactional
@Override
public SyncDelta
beforeUpdate(
final ProvisioningProfile profile,
final SyncDelta delta,
final A any,
final M anyPatch) throws JobExecutionException {
if (any instanceof UserTO) {
final UserTO userTO = ((UserTO) any);
String userName = userTO.getUsername();
try {
Set attrs = userTO.getPlainAttrs();
for (AttrTO attr : attrs) {
if
(attr.getSchema().equalsIgnoreCase("group_column")) {
Group oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());
String oGroupName = oGroup.getName();
String oGroupKey = oGroup.getKey();
MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroupKey).build();
LOG.warn("CHECK " + userName + " >
membership before " + userTO.getMembershipMap().size());
boolean res =
userTO.getMemberships().add(membershipTO);
LOG.warn("CHECK " + userName + " >
membership after " + userTO.getMembershipMap().size());
for (int i = 0; i <
userTO.getMemberships().size(); i++) {
LOG.warn("CHECK " + userName + " > print
membership groupKey: " + userTO.getMemberships().get(i).getGroupKey());
LOG.warn("CHECK " + userName + " > print
membership groupName: " +
userTO.getMemberships().get(i).getGroupName());
}
}
}
} catch (Exception e) {
LOG.warn("Something happened...");
}
}
return delta;
}
"beforeUpdate" is called only if the user is already in Syncope, you
have to manipulate the UserPatch
final UserPatch userPatch = (UserPatch) anyMod;
final MembershipPatch membershipPatch = new
MembershipPatch.Builder().group(/oGroup.getKey()/).build();
userPatch.getMemberships().add(membershipPatch);
The UserTO is the old object before the sync task is happen.
Regards
Marco
On 27.03.17 16:24, Marco Di Sabatino Di Diodoro wrote:
Il 27/03/2017 15:03, Tech ha scritto:
I can also mention that printing the content of:
userTO.getMembership().get(0).getGroupKey()
I can see correctly the group key, so the group is correctly
assigned, but probably just not "committed"
During the after you can no longer change the user, it's too late.
Why do you say that during the before action the assignment doesn't
work?
Please, paste your code
Thanks
M
On 27/03/17 13:21, Tech wrote:
Hello again,
we saw that actually implement the membership in our case is not
really working with a before, but we should implement in an after.
The group already exists in the system and we tried to implement
in this way:
@Transactional
@Override
public void after(
final ProvisioningProfile profile,
final SyncDelta delta,
final EntityTO any,
final ProvisioningReport result) throws
JobExecutionException {
if (any instanceof UserTO) {
final UserTO userTO = (UserTO) any;
try {
Set attrs = userTO.getPlainAttrs();
for (AttrTO attr : attrs) {
if
(attr.getSchema().equalsIgnoreCase("column_group")) {
Group oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());
final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();
L
Re: Assign group to user from DB
As described at the beginning of the thread, we have a pull process
taking information from a database.
We associated the code to the action to take on the pull.
We want to pull the user into the system and to associate it to the role
based on the specific column.
As far as I understand now we should just use userpatch but put it in
BeforeProvisioning instead of BeforeUpdate?
Thanks
On 27.03.17 17:41, Marco Di Sabatino Di Diodoro wrote:
Il 27/03/2017 17:12, Tech ha scritto:
We used the After because we realized that in the first time we run
the code the users were just created and only in the second time the
code was executed the users were associated to the groups, while we
wanted to have everything done at the same time.
"we run the code the users were just created"
during a create you must work with beforeProvisioning or beforeAssing
"in the second time"
What do you mean with this? You run sync task again?
Here the code:
@Transactional
@Override
public SyncDelta beforeUpdate(
final ProvisioningProfile profile,
final SyncDelta delta,
final A any,
final M anyPatch) throws JobExecutionException {
if (any instanceof UserTO) {
final UserTO userTO = ((UserTO) any);
String userName = userTO.getUsername();
try {
Set attrs = userTO.getPlainAttrs();
for (AttrTO attr : attrs) {
if
(attr.getSchema().equalsIgnoreCase("group_column")) {
Group oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());
String oGroupName = oGroup.getName();
String oGroupKey = oGroup.getKey();
MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroupKey).build();
LOG.warn("CHECK " + userName + " > membership
before " + userTO.getMembershipMap().size());
boolean res =
userTO.getMemberships().add(membershipTO);
LOG.warn("CHECK " + userName + " > membership
after " + userTO.getMembershipMap().size());
for (int i = 0; i <
userTO.getMemberships().size(); i++) {
LOG.warn("CHECK " + userName + " > print
membership groupKey: " + userTO.getMemberships().get(i).getGroupKey());
LOG.warn("CHECK " + userName + " > print
membership groupName: " + userTO.getMemberships().get(i).getGroupName());
}
}
}
} catch (Exception e) {
LOG.warn("Something happened...");
}
}
return delta;
}
"beforeUpdate" is called only if the user is already in Syncope, you
have to manipulate the UserPatch
final UserPatch userPatch = (UserPatch) anyMod;
final MembershipPatch membershipPatch = new
MembershipPatch.Builder().group(/oGroup.getKey()/).build();
userPatch.getMemberships().add(membershipPatch);
The UserTO is the old object before the sync task is happen.
Regards
Marco
On 27.03.17 16:24, Marco Di Sabatino Di Diodoro wrote:
Il 27/03/2017 15:03, Tech ha scritto:
I can also mention that printing the content of:
userTO.getMembership().get(0).getGroupKey()
I can see correctly the group key, so the group is correctly
assigned, but probably just not "committed"
During the after you can no longer change the user, it's too late.
Why do you say that during the before action the assignment doesn't
work?
Please, paste your code
Thanks
M
On 27/03/17 13:21, Tech wrote:
Hello again,
we saw that actually implement the membership in our case is not
really working with a before, but we should implement in an after.
The group already exists in the system and we tried to implement
in this way:
@Transactional
@Override
public void after(
final ProvisioningProfile profile,
final SyncDelta delta,
final EntityTO any,
final ProvisioningReport result) throws
JobExecutionException {
if (any instanceof UserTO) {
final UserTO userTO = (UserTO) any;
try {
Set attrs = userTO.getPlainAttrs();
for (AttrTO attr : attrs) {
if
(attr.getSchema().equalsIgnoreCase("column_group")) {
Group oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());
final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();
LOG.warn("Membership before
"+userTO.getMembershipMap().size());// This will print 0
userTO.getMemberships().add(membershipTO);
LOG.warn("M
Re: Assign group to user from DB
Hello again,
we saw that actually implement the membership in our case is not really
working with a before, but we should implement in an after.
The group already exists in the system and we tried to implement in this
way:
@Transactional
@Override
public void after(
final ProvisioningProfile profile,
final SyncDelta delta,
final EntityTO any,
final ProvisioningReport result) throws JobExecutionException {
if (any instanceof UserTO) {
final UserTO userTO = (UserTO) any;
try {
Set attrs = userTO.getPlainAttrs();
for (AttrTO attr : attrs) {
if
(attr.getSchema().equalsIgnoreCase("column_group")) {
Group oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());
final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();
LOG.warn("Membership before
"+userTO.getMembershipMap().size());// This will print 0
userTO.getMemberships().add(membershipTO);
LOG.warn("Membership after
"+userTO.getMembershipMap().size()); // This will print 1:
something happened here
}
}
} catch (Exception e) {
LOG.warn("Something happened...");
}
}
}
After the userTO.getMembership().add(membershipTO) we see that the
"size()" value changes from 0 to 1, therefore we assume that the
membership has been assigned, but when we enter in the console interface
and we check the groups, nothing has changed and we see that the user
doesn't belong to any group.
Is there any other missing action that should be taken?
Thanks
On 06.03.17 17:12, Tech wrote:
Yes, finally working, thanks a lot!
On 06/03/17 16:51, Marco Di Sabatino Di Diodoro wrote:
Il 06/03/2017 16:40, Tech ha scritto:
Actually you were right, we used already a "beforeUpdate".
Here the code, there is nothing strange apparently, the boolean
"result" returns "true", but the user is not added to the group
/
/
/@Transactional//
//@Override//
//public SyncDelta
beforeUpdate(//
//final ProvisioningProfile profile,//
//final SyncDelta delta,//
//final A any,//
//final M anyPatch) throws JobExecutionException {//
//
//if (anyPatch instanceof UserPatch) {//
//final UserTO user = ((UserTO) any);//
//Group oGroup = null;/
/String oGroupColumn = "group_colum";/
/Set attrs = user.getPlainAttrs();//
/
/for(AttrTO attr : attrs) {//
//if(attr.getSchema().equalsIgnoreCase(
oGroupColumn)){//
//LOG.warn("We check the schema:"+
attr.getSchema()); //Found//
//LOG.warn("Content:
"+attr.getValues().get(0).toString()); //Found//
//oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());//
//LOG.warn("Group Key: "+oGroup.getKey());
//Group key correctly retrieved//
//final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();//
//LOG.warn("Check membership :"+
membershipTO.getGroupKey()); //Correct, it corresponds to the
previous group key//
//LOG.warn("Get user key:"+ user.getUsername());
// Correct, it corresponds to what found in Syncope DB//
//boolean result =
user.getMemberships().add(membershipTO); //
//LOG.warn("Was the user added to the group?:
"+result); // Returns true//
//}//
//group = user.getPlainAttrMap().get("role");//
//}//
//return delta;//
//}//
//
/
If you're working in the beforeUpdate you need to update the
UserPatch object:
final UserPatch userPatch = (UserPatch) anyMod;
final MembershipPatch membershipPatch = new
MembershipPatch.Builder().group(/oGroup.getKey()/).build();
userPatch.getMemberships().add(membershipPatch);
Regards
Marco
On 06/03/17 16:10, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 06/03/2017 15:45, Tech ha scritto:
Hello,
as suggested, we started to work on the easiest case, we created
the Group1 in Syncope manually and we inserted into the database
column "Group" the entry "Group1".
We implemented only an "after" in this case: we pulled the
information into Syncope and after the java is running.
Following the log we see that:
* we are able to find the user, and his userkey
* we are able to find the group column (a new custom field into
Syncope)
* we are able to find the group key of the group into Sync
Re: Some issues detected with the field date
Hello Marco, we tried to change the year as you suggested, but nothing is changing because the problem is about day and month On 22/03/17 15:26, Marco Di Sabatino Di Diodoro wrote: Il 22/03/2017 15:14, Tech ha scritto: You could try with -M-d or -d-M or -MM-d ... we tried different combinations to make it working, but the result didn't change. We save the user and when we try to edit the date field the only correct information is the year Please, try with -M-d convert years to lowercase Regards M On 22/03/17 14:54, Marco Di Sabatino Di Diodoro wrote: Hi, Il 22/03/2017 14:48, Tech ha scritto: Dear Syncope Team, we are using version 2.0.2 of the product. We detected this issue both from Console and Enduser interface: changing a custom date, the year is reported correctly, but the day and month are wrong. If we try to define a date like the 31-01-2017, the date that is store is actually 02-00-2017. To reproduce your use case I need some information: 1. the conversion pattern defined in your schema 2. steps to reproduce the problem Regards M We also detected that the time is in GMT, therefore if we set as date 01-01-2017 00:00:00, the date that is actually considered is 31-12-2016 23:00:00. Could you please double check this? Thanks -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/ -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Re: Some issues detected with the field date
You could try with -M-d or -d-M or -MM-d ... we tried different combinations to make it working, but the result didn't change. We save the user and when we try to edit the date field the only correct information is the year On 22/03/17 14:54, Marco Di Sabatino Di Diodoro wrote: Hi, Il 22/03/2017 14:48, Tech ha scritto: Dear Syncope Team, we are using version 2.0.2 of the product. We detected this issue both from Console and Enduser interface: changing a custom date, the year is reported correctly, but the day and month are wrong. If we try to define a date like the 31-01-2017, the date that is store is actually 02-00-2017. To reproduce your use case I need some information: 1. the conversion pattern defined in your schema 2. steps to reproduce the problem Regards M We also detected that the time is in GMT, therefore if we set as date 01-01-2017 00:00:00, the date that is actually considered is 31-12-2016 23:00:00. Could you please double check this? Thanks -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Some issues detected with the field date
Dear Syncope Team, we are using version 2.0.2 of the product. We detected this issue both from Console and Enduser interface: changing a custom date, the year is reported correctly, but the day and month are wrong. If we try to define a date like the 31-01-2017, the date that is store is actually 02-00-2017. We also detected that the time is in GMT, therefore if we set as date 01-01-2017 00:00:00, the date that is actually considered is 31-12-2016 23:00:00. Could you please double check this? Thanks
REST Web Service
Dear experts, we are trying to configure a REST Web Service, but we don't how it should be deployed. We found in the /test directory some groovy script to Create/Update/etc, but we don't understand in a real environment where these script should be copied before compiling. Thanks!
Re: Assign group to user from DB
Yes, finally working, thanks a lot!
On 06/03/17 16:51, Marco Di Sabatino Di Diodoro wrote:
Il 06/03/2017 16:40, Tech ha scritto:
Actually you were right, we used already a "beforeUpdate".
Here the code, there is nothing strange apparently, the boolean
"result" returns "true", but the user is not added to the group
/
/
/@Transactional//
//@Override//
//public SyncDelta
beforeUpdate(//
//final ProvisioningProfile profile,//
//final SyncDelta delta,//
//final A any,//
//final M anyPatch) throws JobExecutionException {//
//
//if (anyPatch instanceof UserPatch) {//
//final UserTO user = ((UserTO) any);//
//Group oGroup = null;/
/String oGroupColumn = "group_colum";/
/Set attrs = user.getPlainAttrs();//
/
/for(AttrTO attr : attrs) {//
//if(attr.getSchema().equalsIgnoreCase( oGroupColumn)){//
//LOG.warn("We check the schema:"+
attr.getSchema()); //Found//
//LOG.warn("Content:
"+attr.getValues().get(0).toString()); //Found//
//oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());//
//LOG.warn("Group Key: "+oGroup.getKey());
//Group key correctly retrieved//
//final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();//
//LOG.warn("Check membership :"+
membershipTO.getGroupKey()); //Correct, it corresponds to the
previous group key//
//LOG.warn("Get user key:"+ user.getUsername());
// Correct, it corresponds to what found in Syncope DB//
//boolean result =
user.getMemberships().add(membershipTO); //
//LOG.warn("Was the user added to the group?:
"+result); // Returns true//
//}//
//group = user.getPlainAttrMap().get("role");//
//}//
//return delta;//
//}//
//
/
If you're working in the beforeUpdate you need to update the UserPatch
object:
final UserPatch userPatch = (UserPatch) anyMod;
final MembershipPatch membershipPatch = new
MembershipPatch.Builder().group(/oGroup.getKey()/).build();
userPatch.getMemberships().add(membershipPatch);
Regards
Marco
On 06/03/17 16:10, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 06/03/2017 15:45, Tech ha scritto:
Hello,
as suggested, we started to work on the easiest case, we created
the Group1 in Syncope manually and we inserted into the database
column "Group" the entry "Group1".
We implemented only an "after" in this case: we pulled the
information into Syncope and after the java is running.
Following the log we see that:
* we are able to find the user, and his userkey
* we are able to find the group column (a new custom field into
Syncope)
* we are able to find the group key of the group into Syncope,
based on the group column found in the previous point
* we create the membership based on the group key (final
MembershipTO membershipTO = new
MembershipTO.Builder().group(group.getKey()).build();)
* we add the membership to the user.
Checking the return value of the last "add(membershipTO)", we see
that it's returning a "true", therefore we think that everything
went well, but when we enter into the admin console of Syncope, the
user has not being assigned to the Group1.
Is there a missing step?
you're near the solution. I presume you're working with UserTO. So,
to update an user during the pull process, you must implement the
assignment of the membership during beforeProvision, beforeAssign or
beforeUpdate.
Updating the UserTO in the "after" is too late. The only way to
update an user in the after is with the DAO.
Regards
Marco
Thanks
On 03/03/17 19:49, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 03/03/2017 15:53, Tech ha scritto:
Hello Francesco,
we went through the directory
core/src/test/resources/scriptedsql, but we didn't find any
concrete example that might help us to implement what we might
need to do, we were expecting that the solution was in the
PullActions, but we didn't understood that that was addressing
only __ACCOUNT__ and not groups.
What steps should be followed to assign the User1 to Group1 in
Syncope when the information into the database are something like
USERNAME|GROUP
User1|Group1
User2|Group1
?
The Scripted Sqlallows to synchronize users, groups or any type.
Groovy script gives the possibility to specify which type of
object you like to manage, for example, during a search you can
add different case statement one for each type:
switch ( objectClass ) {
case "__ACCOUNT__":
sql.eachRow("SELECT *
Re: Assign group to user from DB
Actually you were right, we used already a "beforeUpdate".
Here the code, there is nothing strange apparently, the boolean "result"
returns "true", but the user is not added to the group
/
/
/@Transactional//
//@Override//
//public SyncDelta beforeUpdate(//
//final ProvisioningProfile profile,//
//final SyncDelta delta,//
//final A any,//
//final M anyPatch) throws JobExecutionException {//
//
//if (anyPatch instanceof UserPatch) {//
//final UserTO user = ((UserTO) any);//
//Group oGroup = null;/
/String oGroupColumn = "group_colum";/
/Set attrs = user.getPlainAttrs();//
/
/for(AttrTO attr : attrs) {//
//if(attr.getSchema().equalsIgnoreCase( oGroupColumn)){//
//LOG.warn("We check the schema:"+
attr.getSchema()); //Found//
//LOG.warn("Content:
"+attr.getValues().get(0).toString()); //Found//
//oGroup =
groupDAO.findByName(attr.getValues().get(0).toString());//
//LOG.warn("Group Key: "+oGroup.getKey()); //Group
key correctly retrieved//
//final MembershipTO membershipTO = new
MembershipTO.Builder().group(oGroup.getKey()).build();//
//LOG.warn("Check membership :"+
membershipTO.getGroupKey()); //Correct, it corresponds to the previous
group key//
//LOG.warn("Get user key:"+ user.getUsername()); //
Correct, it corresponds to what found in Syncope DB//
//boolean result =
user.getMemberships().add(membershipTO); //
//LOG.warn("Was the user added to the group?:
"+result); // Returns true//
//}//
//group = user.getPlainAttrMap().get("role");//
//}//
//return delta;//
//}//
//
/
On 06/03/17 16:10, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 06/03/2017 15:45, Tech ha scritto:
Hello,
as suggested, we started to work on the easiest case, we created the
Group1 in Syncope manually and we inserted into the database column
"Group" the entry "Group1".
We implemented only an "after" in this case: we pulled the
information into Syncope and after the java is running.
Following the log we see that:
* we are able to find the user, and his userkey
* we are able to find the group column (a new custom field into
Syncope)
* we are able to find the group key of the group into Syncope,
based on the group column found in the previous point
* we create the membership based on the group key (final
MembershipTO membershipTO = new
MembershipTO.Builder().group(group.getKey()).build();)
* we add the membership to the user.
Checking the return value of the last "add(membershipTO)", we see
that it's returning a "true", therefore we think that everything went
well, but when we enter into the admin console of Syncope, the user
has not being assigned to the Group1.
Is there a missing step?
you're near the solution. I presume you're working with UserTO. So, to
update an user during the pull process, you must implement the
assignment of the membership during beforeProvision, beforeAssign or
beforeUpdate.
Updating the UserTO in the "after" is too late. The only way to update
an user in the after is with the DAO.
Regards
Marco
Thanks
On 03/03/17 19:49, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 03/03/2017 15:53, Tech ha scritto:
Hello Francesco,
we went through the directory core/src/test/resources/scriptedsql,
but we didn't find any concrete example that might help us to
implement what we might need to do, we were expecting that the
solution was in the PullActions, but we didn't understood that that
was addressing only __ACCOUNT__ and not groups.
What steps should be followed to assign the User1 to Group1 in
Syncope when the information into the database are something like
USERNAME|GROUP
User1|Group1
User2|Group1
?
The Scripted Sqlallows to synchronize users, groups or any type.
Groovy script gives the possibility to specify which type of object
you like to manage, for example, during a search you can add
different case statement one for each type:
switch ( objectClass ) {
case "__ACCOUNT__":
sql.eachRow("SELECT * FROM Users " + where",
{result.add([__UID__:it.id, __NAME__:it.id, ID:it.id,
NAME:it.name, ...,])} );
break
case "__GROUPS__":
sql.eachRow("SELECT * FROM Groups " + where",
{result.add([__UID__:it.id, __NAME__:it.id, ID:it.id,
NAME:it.name, ...,])} );
break
case "__DEPARTMENT__":
sql.eachRow("SELECT * FROM Departments " + where",
{result.add([__UID__
Re: Assign group to user from DB
Hello,
as suggested, we started to work on the easiest case, we created the
Group1 in Syncope manually and we inserted into the database column
"Group" the entry "Group1".
We implemented only an "after" in this case: we pulled the information
into Syncope and after the java is running.
Following the log we see that:
* we are able to find the user, and his userkey
* we are able to find the group column (a new custom field into Syncope)
* we are able to find the group key of the group into Syncope, based
on the group column found in the previous point
* we create the membership based on the group key (final MembershipTO
membershipTO = new
MembershipTO.Builder().group(group.getKey()).build();)
* we add the membership to the user.
Checking the return value of the last "add(membershipTO)", we see that
it's returning a "true", therefore we think that everything went well,
but when we enter into the admin console of Syncope, the user has not
being assigned to the Group1.
Is there a missing step?
Thanks
On 03/03/17 19:49, Marco Di Sabatino Di Diodoro wrote:
Hi,
Il 03/03/2017 15:53, Tech ha scritto:
Hello Francesco,
we went through the directory core/src/test/resources/scriptedsql,
but we didn't find any concrete example that might help us to
implement what we might need to do, we were expecting that the
solution was in the PullActions, but we didn't understood that that
was addressing only __ACCOUNT__ and not groups.
What steps should be followed to assign the User1 to Group1 in
Syncope when the information into the database are something like
USERNAME|GROUP
User1|Group1
User2|Group1
?
The Scripted Sqlallows to synchronize users, groups or any type.
Groovy script gives the possibility to specify which type of object
you like to manage, for example, during a search you can add different
case statement one for each type:
switch ( objectClass ) {
case "__ACCOUNT__":
sql.eachRow("SELECT * FROM Users " + where",
{result.add([__UID__:it.id, __NAME__:it.id, ID:it.id,
NAME:it.name, ...,])} );
break
case "__GROUPS__":
sql.eachRow("SELECT * FROM Groups " + where",
{result.add([__UID__:it.id, __NAME__:it.id, ID:it.id,
NAME:it.name, ...,])} );
break
case "__DEPARTMENT__":
sql.eachRow("SELECT * FROM Departments " + where",
{result.add([__UID__:it.id, __NAME__:it.id, NAME:it.name,
DEPARTMENT:it.department, ...,])} );
break
default:
result;
}
In order to assign a group to a user, you must implement a pull
action. But before doing this, you have to know if thegroups already
exist on Syncope or are to be created simultaneously with the users.
In the first case you need to implement a simpler action:
final UserTO userTO = (UserTO) entity;
Group group = groupDAO.findByName(groupName);
if (group == null) {
throw new RuntimeException("Group not found");
}
final MembershipTO membershipTO = new
MembershipTO.Builder().group(group.getKey()).build();
userTO.getMemberships().add(membershipTO);
second case you must create the group (with dao)
Group group = groupDAO.findByName(groupName);
if (group == null) {
group = entityFactory.newEntity(Group.class);
group.setRealm(realmDAO.getRoot());
group.setName(groupName);
group = groupDAO.save(courseGroup);
}
and then assign it to the user during the after action.
Regards
M
Thanks
On 01/03/17 14:40, Francesco Chicchiriccò wrote:
Hi,
are you sure that you are using the Scripted SQL connector?
The Database Table connector, in fact, only provides support for the
__ACCOUNT__ ObjectClass, e.g. only for users, as suggested by the
error below.
In order to use the Scripted SQL connector, you must also provide
the adequate Groovy scripts matching your own database schema; some
samples can be found under the
core/src/test/resources/scriptedsql
directory of your generated Maven project.
HTH
Regards.
On 27/02/2017 17:47, Tech wrote:
Hello,
coming back to this point: we prepared the code to integrate the
group propagation from a DB to Syncope but we encountered some
problems.
Before integrating the code that we developed, we started to add
the concept of Group into our system.
* Our database has a column called "role", where the only content
is "GroupTest".
* We created the group "GroupTest" also in Syncope to have a 1:1
relation.
* We created the type "role" and we put it into the "BaseGroup"
schema.
* We go back to the resources and we Edit provision rules, we add
a Group that we map with name:role.
Since now on, every Pull, also the one for the Users, will
terminate in a FAILURE with the error:
org.quartz.JobExecutionException: While pulling from connector [See
nested exc
Re: Assign group to user from DB
Hello Francesco, we went through the directory core/src/test/resources/scriptedsql, but we didn't find any concrete example that might help us to implement what we might need to do, we were expecting that the solution was in the PullActions, but we didn't understood that that was addressing only __ACCOUNT__ and not groups. What steps should be followed to assign the User1 to Group1 in Syncope when the information into the database are something like USERNAME|GROUP User1|Group1 User2|Group1 ? Thanks On 01/03/17 14:40, Francesco Chicchiriccò wrote: Hi, are you sure that you are using the Scripted SQL connector? The Database Table connector, in fact, only provides support for the __ACCOUNT__ ObjectClass, e.g. only for users, as suggested by the error below. In order to use the Scripted SQL connector, you must also provide the adequate Groovy scripts matching your own database schema; some samples can be found under the core/src/test/resources/scriptedsql directory of your generated Maven project. HTH Regards. On 27/02/2017 17:47, Tech wrote: Hello, coming back to this point: we prepared the code to integrate the group propagation from a DB to Syncope but we encountered some problems. Before integrating the code that we developed, we started to add the concept of Group into our system. * Our database has a column called "role", where the only content is "GroupTest". * We created the group "GroupTest" also in Syncope to have a 1:1 relation. * We created the type "role" and we put it into the "BaseGroup" schema. * We go back to the resources and we Edit provision rules, we add a Group that we map with name:role. Since now on, every Pull, also the one for the Users, will terminate in a FAILURE with the error: org.quartz.JobExecutionException: While pulling from connector [See nested exception: java.lang.IllegalArgumentException: Operation requires an Account ObjectClass.] at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:284) at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:60) at org.apache.syncope.core.provisioning.java.pushpull.AbstractProvisioningJobDelegate.doExecute(AbstractProvisioningJobDelegate.java:558) at org.apache.syncope.core.provisioning.java.job.AbstractSchedTaskJobDelegate.execute(AbstractSchedTaskJobDelegate.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) Removing the mapping of the group, everything will turn back to normality. Any idea why this could happen? Thanks! On 06/02/17 17:58, Marco Di Sabatino Di Diodoro wrote: Il 06/02/2017 17:41, Marco Di Sabatino Di Diodoro ha scritto: Hi, Il 06/02/2017 17:11, Tech ha scritto: Dear experts, we're pulling information from a database. We want to assign automatically a group to a user. The original table has a format like -- "USERNAME" : "user01" -- "ROLE": "employee" In a pull task is possible to add a template. The template can be used for setting default values on entities during a pull task. To configure a template go to Topology --> select the external resource to pull --> Pull Task and click the Template icon [1 Pull Templates]. [1] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull If a User is associated to a Group in your Database, and you like assign the corresponding User as a member of the corresponding Group in Syncope, you must implement a Pull Action [1]. Connid doesn't implement the assignment of a membership, so to obviate we can use a pull action. [1] https://syncope.apache.org/docs/reference-guide.html#pullactions We want the user being created into Syncope associated to the already existing group "employee", but we don't see how to create this association. Is there any reference that we should check? Thanks -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Re: Assign group to user from DB
We didn't know at all that about the Scripted SQL connectors, we were following the pull/pushactions examples. On 01/03/17 14:40, Francesco Chicchiriccò wrote: Hi, are you sure that you are using the Scripted SQL connector? The Database Table connector, in fact, only provides support for the __ACCOUNT__ ObjectClass, e.g. only for users, as suggested by the error below. In order to use the Scripted SQL connector, you must also provide the adequate Groovy scripts matching your own database schema; some samples can be found under the core/src/test/resources/scriptedsql directory of your generated Maven project. HTH Regards. On 27/02/2017 17:47, Tech wrote: Hello, coming back to this point: we prepared the code to integrate the group propagation from a DB to Syncope but we encountered some problems. Before integrating the code that we developed, we started to add the concept of Group into our system. * Our database has a column called "role", where the only content is "GroupTest". * We created the group "GroupTest" also in Syncope to have a 1:1 relation. * We created the type "role" and we put it into the "BaseGroup" schema. * We go back to the resources and we Edit provision rules, we add a Group that we map with name:role. Since now on, every Pull, also the one for the Users, will terminate in a FAILURE with the error: org.quartz.JobExecutionException: While pulling from connector [See nested exception: java.lang.IllegalArgumentException: Operation requires an Account ObjectClass.] at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:284) at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:60) at org.apache.syncope.core.provisioning.java.pushpull.AbstractProvisioningJobDelegate.doExecute(AbstractProvisioningJobDelegate.java:558) at org.apache.syncope.core.provisioning.java.job.AbstractSchedTaskJobDelegate.execute(AbstractSchedTaskJobDelegate.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) Removing the mapping of the group, everything will turn back to normality. Any idea why this could happen? Thanks! On 06/02/17 17:58, Marco Di Sabatino Di Diodoro wrote: Il 06/02/2017 17:41, Marco Di Sabatino Di Diodoro ha scritto: Hi, Il 06/02/2017 17:11, Tech ha scritto: Dear experts, we're pulling information from a database. We want to assign automatically a group to a user. The original table has a format like -- "USERNAME" : "user01" -- "ROLE": "employee" In a pull task is possible to add a template. The template can be used for setting default values on entities during a pull task. To configure a template go to Topology --> select the external resource to pull --> Pull Task and click the Template icon [1 Pull Templates]. [1] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull If a User is associated to a Group in your Database, and you like assign the corresponding User as a member of the corresponding Group in Syncope, you must implement a Pull Action [1]. Connid doesn't implement the assignment of a membership, so to obviate we can use a pull action. [1] https://syncope.apache.org/docs/reference-guide.html#pullactions We want the user being created into Syncope associated to the already existing group "employee", but we don't see how to create this association. Is there any reference that we should check? Thanks -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Dynamic role - the task remains blocked
Dear experts, we want to report you something we detected in the Syncope-Console. We are importing some information from a database where a column is called "MYGROUP" and the content is "Employee". We created a group into Syncope called MYGROUP and in the group we defined a Dynamic group where the attribute.myrole == Employee, the user is automatically assigned to the group. When we check the users, we can validate that they are correctly assigned to the group MYGROUP. We perform some modification on the Database, we run again the pull, but this time we see that from the Dashboard/Control/Available, we see the pull still running, and also pushing on the Stop, the popup will confirm us that the task has been performed correctly, but also restarting Syncope, the task will be still running. We are not able to run anymore any Pull, and we were forced to run a restore of the database. What should be done to avoid this? Thanks
Jobs blocked after modification
Dear experts, we tried to run some modification from the interface, but now we aren't anymore able to pull any information because we have the jobs blocked as showed by the image. We rebooted the application, but the problem wasn't resolved. We click on the "STOP", but the tasks are not stopping. We removed the resources and we recreated, but the problem still persist, have you any idea about how to resolve this issue? Thanks
Re: Assign group to user from DB
Hello, coming back to this point: we prepared the code to integrate the group propagation from a DB to Syncope but we encountered some problems. Before integrating the code that we developed, we started to add the concept of Group into our system. * Our database has a column called "role", where the only content is "GroupTest". * We created the group "GroupTest" also in Syncope to have a 1:1 relation. * We created the type "role" and we put it into the "BaseGroup" schema. * We go back to the resources and we Edit provision rules, we add a Group that we map with name:role. Since now on, every Pull, also the one for the Users, will terminate in a FAILURE with the error: org.quartz.JobExecutionException: While pulling from connector [See nested exception: java.lang.IllegalArgumentException: Operation requires an Account ObjectClass.] at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:284) at org.apache.syncope.core.provisioning.java.pushpull.PullJobDelegate.doExecuteProvisioning(PullJobDelegate.java:60) at org.apache.syncope.core.provisioning.java.pushpull.AbstractProvisioningJobDelegate.doExecute(AbstractProvisioningJobDelegate.java:558) at org.apache.syncope.core.provisioning.java.job.AbstractSchedTaskJobDelegate.execute(AbstractSchedTaskJobDelegate.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) Removing the mapping of the group, everything will turn back to normality. Any idea why this could happen? Thanks! On 06/02/17 17:58, Marco Di Sabatino Di Diodoro wrote: Il 06/02/2017 17:41, Marco Di Sabatino Di Diodoro ha scritto: Hi, Il 06/02/2017 17:11, Tech ha scritto: Dear experts, we're pulling information from a database. We want to assign automatically a group to a user. The original table has a format like -- "USERNAME" : "user01" -- "ROLE": "employee" In a pull task is possible to add a template. The template can be used for setting default values on entities during a pull task. To configure a template go to Topology --> select the external resource to pull --> Pull Task and click the Template icon [1 Pull Templates]. [1] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull If a User is associated to a Group in your Database, and you like assign the corresponding User as a member of the corresponding Group in Syncope, you must implement a Pull Action [1]. Connid doesn't implement the assignment of a membership, so to obviate we can use a pull action. [1] https://syncope.apache.org/docs/reference-guide.html#pullactions We want the user being created into Syncope associated to the already existing group "employee", but we don't see how to create this association. Is there any reference that we should check? Thanks -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/ -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/
Re: Enduser interface - Enum values
Thanks Andrea, looking forward for version 2.0.3 On 02/23/2017 10:27 AM, Andrea Patricelli wrote: t configuration, there is a bug in the Enduser, it does not support labels longer than 1 character. I've just open [1]. Fix will be available since 2.0.3 release (and in 2.0.3-SNAPSHOT). Best regards,
Enduser interface - Enum values
Dear experts, we created a custom Enum type "p_language" The mappings should be * 1: English * 2: German translated in this way Type: Enum values * 1 * 2 Labels * English * German Basic validator When we enter in the user interface we see in the dropdown * E * N * G while we are expecting * English * German Could you please doublecheck or confirm us if we are using a wrong configuration? Thanks
Re: Get error - while try to synchronize AD data to syncpe
Once you created the connector, you save and you go back to the Topology
page.
Once you are there you can left click on the connector that you already
created and a grey menu will open on the right.
From that menu you have to choose "Create Resource"
Once you will have also create the resource you will see that a new
"square" will appear in the topology view.
Arrived to that step, you click one more time on the Resource and a
bigger menu will open on the right.
From this menu select the second bullet point, from there you will be
able to syncronize the mappings (firstName : givenName: lastName : sn...
etc)
On 02/22/2017 04:53 PM, Raj Kumar wrote:
Can you bit elaborate please. I am new to syncope and 2.0.2 is totally
different on UI compare to old version. Kindly elaborate the steps .
Thanks,
Rajkumar k
Thanks,
Rajkumar k
On Feb 22, 2017 8:56 PM, "Tech" <t...@psynd.net
<mailto:t...@psynd.net>> wrote:
Always from the Topology you should create the resource.
Click on the connector and a popup will appear on the right.
There you can also define the mappings
On 02/22/2017 04:20 PM, rajkumar wrote:
Hi,
I have set up syncope 2.0.2 in my centos server and i have
created connector
for sync data from AD to Syncope. I have checked the
connection and there
are no issues.
But when i try to run the pull task, it is giving success
status but in
connid.log i am getting below error.
*[2017-02-22T15:09:51.998]
net.tirasa.connid.bundles.ldap.schema.LdapSchemaMapping
Attribute __ENABLE__ of object class __ACCOUNT__ is not mapped
to an LDAP
attribute Method: getLdapAttribute
[2017-02-22T15:09:51.998]
org.identityconnectors.framework.common.objects.ResultsHandler
Enter: {Uid=Attribute: {Name=__UID__, Value=[Bernd_S_epS]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
{Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
Attribute: {Name=__NAME__,
Value=[CN=Bernd_S_epS,OU=G_GI_GEO_epS,OU=MUL,DC=loc,DC=trumobi,DC=de]},
Attribute: {Name=__UID__, Value=[Bernd_S_epS]}, Attribute:
{Name=__ENABLE__,
Value=[]}, Attribute: {Name=name, Value=[Bernd_S_epS]}],
Name=Attribute:
{Name=__NAME__,
Value=[CN=Bernd_S_epS,OU=G_GI_GEO_epS,OU=MUL,DC=loc,DC=trumobi,DC=de]}}
Method: handle*
Kindly help me in this to fix the issue.
Thanks in advance
Rajkumar K
--
View this message in context:
http://syncope-user.1051894.n5.nabble.com/Get-error-while-try-to-synchronize-AD-data-to-syncpe-tp5709003.html
<http://syncope-user.1051894.n5.nabble.com/Get-error-while-try-to-synchronize-AD-data-to-syncpe-tp5709003.html>
Sent from the syncope-user mailing list archive at Nabble.com.
Re: Get error - while try to synchronize AD data to syncpe
Always from the Topology you should create the resource.
Click on the connector and a popup will appear on the right.
There you can also define the mappings
On 02/22/2017 04:20 PM, rajkumar wrote:
Hi,
I have set up syncope 2.0.2 in my centos server and i have created connector
for sync data from AD to Syncope. I have checked the connection and there
are no issues.
But when i try to run the pull task, it is giving success status but in
connid.log i am getting below error.
*[2017-02-22T15:09:51.998]
net.tirasa.connid.bundles.ldap.schema.LdapSchemaMapping
Attribute __ENABLE__ of object class __ACCOUNT__ is not mapped to an LDAP
attribute Method: getLdapAttribute
[2017-02-22T15:09:51.998]
org.identityconnectors.framework.common.objects.ResultsHandler
Enter: {Uid=Attribute: {Name=__UID__, Value=[Bernd_S_epS]},
ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute:
{Name=__PASSWORD__,
Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
Attribute: {Name=__NAME__,
Value=[CN=Bernd_S_epS,OU=G_GI_GEO_epS,OU=MUL,DC=loc,DC=trumobi,DC=de]},
Attribute: {Name=__UID__, Value=[Bernd_S_epS]}, Attribute: {Name=__ENABLE__,
Value=[]}, Attribute: {Name=name, Value=[Bernd_S_epS]}], Name=Attribute:
{Name=__NAME__,
Value=[CN=Bernd_S_epS,OU=G_GI_GEO_epS,OU=MUL,DC=loc,DC=trumobi,DC=de]}}
Method: handle*
Kindly help me in this to fix the issue.
Thanks in advance
Rajkumar K
--
View this message in context:
http://syncope-user.1051894.n5.nabble.com/Get-error-while-try-to-synchronize-AD-data-to-syncpe-tp5709003.html
Sent from the syncope-user mailing list archive at Nabble.com.
Understanding connector agent in remote system
Dear experts, we checked from the documentation that the conn bundles could be also deployed on the target system instead of that in Syncope. We want to understand with you if it would be possible to configure a similar scenario and to validate if our understanding is correct: * Syncope is deployed on Server1 and the target system on the Server2. * Syncope calls the remote connector deployed on the Server2 (using REST?) * The remote connector deployed on Server2 extracts the data (SELECT FIRSTNAME, LASTNAME FROM USER;) * The remote connector caches the result of the query * Syncope extract the information from the remote connector and take them to Server1. Is that correct? Thanks
Re: Syncope development environment
Hello Andrea, not with the source codes, but with the MVN project On 02/16/2017 04:39 PM, Andrea Patricelli wrote: Hi Alin, Il 16/02/2017 16:09, Tech ha scritto: Hello, Is there any way we can setup a full development environment with debug possibilities from IntelliJ or another IDE, and if yes can you give us a link? Are you working on a project created with maven archetype (explained at [1]) or directly on the sources? Thanks, Alin HTH, Andrea [1] https://syncope.apache.org/docs/getting-started.html#maven-project -- Andrea Patricelli Tirasa - Open Source Excellence http://www.tirasa.net/ PMC member at The Apache Software Foundation Syncope
Syncope development environment
Hello, Is there any way we can setup a full development environment with debug possibilities from IntelliJ or another IDE, and if yes can you give us a link? Thanks, Alin
Re: Bug to JEXL script using custom field with "-" propagating a "0"
Hello, thanks for the clarification Regards On 02/15/2017 04:28 PM, Francesco Chicchiriccò wrote: On 15/02/2017 16:18, Tech wrote: Dear Experts, we want to bring to your attention a bug that we detected into the admin console. If you create a custom field containing a dash "-" like "first-name", we detected that in the case we would like to apply some JEXL in the push (but maybe this might apply also in other cases), for example if we want to push our internal field "first-name" to Active Directory "email", the provisioning will just propagate "0". For example: * first-name + '@mydomain.local' will return * "0@mydomain.local" This error will disappear if the field will be named "first_name" or "firstname". Let us know if we should open a bug in Jira. This limitation actually comes from the fact that you are using a schema in a JEXL expression, and variables in JEXL (similarly as in Java) do not admit the minus character in their name; see https://commons.apache.org/proper/commons-jexl/reference/syntax.html for reference, under 'Identifiers / variables' Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Bug to JEXL script using custom field with "-" propagating a "0"
Dear Experts, we want to bring to your attention a bug that we detected into the admin console. If you create a custom field containing a dash "-" like "first-name", we detected that in the case we would like to apply some JEXL in the push (but maybe this might apply also in other cases), for example if we want to push our internal field "first-name" to Active Directory "email", the provisioning will just propagate "0". For example: * first-name + '@mydomain.local' will return * "0@mydomain.local" This error will disappear if the field will be named "first_name" or "firstname". Let us know if we should open a bug in Jira. Regards
Re: Active Directory password propagation
Hello, actually that field at that stage was not flagged. Checking them it's now working, but was generated confusion is that without checking them, the other information as FirstName, LastName etc are propagated. Is there a way to keep as default the check [v] active? Thanks for the support! On 15/02/2017 12:07, Andrea Patricelli wrote: > > Good morning, > > we made a double check and password propagation on Active Directory > was successful. > > In the user edit form (first tab of the wizard), beneath password and > confirm password text areas, there are two (or more) checkboxes > (depends on the number of resources associated to the user), have you > flagged the AD checkbox? > Please see image at [1]. > > HTH, > Andrea > > [1] https://ibin.co/3CTCYNjuyWT7.png > > Il 13/02/2017 14:52, Tech ha scritto: >> Dear experts, >> >> We guess that there is a bug in the AD connector. >> >> 1. We are able to set in SSL the connection >> 2. we can create a user with a chosen password >> 3. we login with success to the system using the chosen password >> 4. we try to change any value from the user interface and these >> changes are immediately reflected to the AD >> 5. we change the password, but it is not propagated >> 6. we change the first name and it's correctly propagated, but the >> password is not >> 7. we try to manually run the PushTask, and only in this case the >> password is correctly propagated >> >> We are able to automatically propagate all fields except the password >> (that requires a manual propagation), could you please double check? >> >> Thanks >> >> >> >> >> On 30/01/2017 16:02, Tech wrote: >>> The value in 'password.cipher.algorithm' was SHA1. >>> >>> We updated to AES, we changed again the password for the user and we >>> tried to login again to the enduser portal. >>> >>> It's working, we tried to connect to AD but without success. >>> >>> We realized after that the password, with a difference with the >>> other fields, is not immediately propagate when changed, but it's >>> only propagated by the scheduler. >>> >>> Can this be changed? >>> >>> Thanks for your support >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 30/01/2017 15:24, Francesco Chicchiriccò wrote: >>>> On 30/01/2017 15:18, Tech wrote: >>>>> Yes, I can confirm, right in this moment we are only performing >>>>> manual provisioning. >>>>> >>>>> This is of course not the goal, but before moving to an automatic >>>>> provision of accounts we want the manual one working >>>> >>>> What is your value for the 'password.cipher.algorithm' general >>>> configuration parameter? If not 'AES', pushing password values (as >>>> any other encrypted value) will not work anyway. >>>> >>>> The point is that Active Directory requires cleartext password >>>> values (encrypted via ConnId's GuardedString), which are normally >>>> available only during user update, not later. This unless AES (e.g. >>>> reversible encryption) is set for internal password values. >>>> Provisioning - via resource assignment - is part of user update, >>>> push occurs after user update. >>>> >>>> Regards. >>>> >>>>> On 30/01/2017 15:14, Francesco Chicchiriccò wrote: >>>>>> On 30/01/2017 15:11, Tech wrote: >>>>>>> We are associating using a manual provisioning >>>>>> >>>>>> Do you mean that you are only relying on a push task for >>>>>> provisioning to AD? >>>>>> >>>>>> Could you confirm that you are *not* assigning the AD resource >>>>>> directly to the users, neither via group membership or template? >>>>>> >>>>>>> Here the main information: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Connector version 1.3.2 >>>>>>> >>>>>>> -SSL enabled >>>>>>> -Retrieve deleted users enabled >>>>>>> -Retrieve deleted groups enabled >>>>>>> -Trust all certs enabled >>>>>>> >>>>>>> Entry object classes: >>>>>>> -Top >>>>>>> -person >>>>>&g
How to purge Syncope user form DB and execution history
Dear All, 1. I would like to ask you if already exists a script to purge a Syncope user (deleting the credentials, etc. = absolute deletion) form the DB. 2. We have an important amount of information checking the "Result status of execution", we would like to know if also exists an automatic procedure to keep trace only of the most recent information to have a more agile log. Kind regards, Mária
Re: Password reset procedure from enduser interface
Hello Francesco, Thanks for your update, we created the notification in the parameters and the template, but we get stuck before the point you were describing: We went through the procedure, the user creates his own account, with an email and a password. For simplicity, we created only one security question. Once he forget the password, he comes back to the EndUser interface and he request to insert the challenge answer. Even if the challenge answer is correct (and I can check that it's correctly stored into the database), we receive an error saying: 18:44:20.883 ERROR org.apache.syncope.client.enduser.resources.UserSelfPasswordReset - Error while updating user java.lang.Exception: A correct security answer should be provided at org.apache.syncope.client.enduser.resources.UserSelfPasswordReset.newResourceResponse(UserSelfPasswordReset.java:76) ~[syncope-client-enduser-2.0.2.jar:2.0.2] at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:629) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:105) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:108) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) ~[wicket-request-7.6.0.jar:7.6.0] at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284) ~[wicket-core-7.6.0.jar:7.6.0] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) ~[catalina.jar:8.0.39] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) ~[catalina.jar:8.0.39] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) ~[catalina.jar:8.0.39] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) ~[catalina.jar:8.0.39] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) ~[catalina.jar:8.0.39] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) ~[catalina.jar:8.0.39] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) ~[catalina.jar:8.0.39] at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) ~[catalina.jar:8.0.39] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) ~[catalina.jar:8.0.39] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:509) ~[catalina.jar:8.0.39] at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1104) ~[tomcat-coyote.jar:8.0.39] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) ~[tomcat-coyote.jar:8.0.39] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520) ~[tomcat-coyote.jar:8.0.39] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476) ~[tomcat-coyote.jar:8.0.39] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_111] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-util.jar:8.0.39] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111] But we know that the challenge answer is correct and all in lowercase like in the database, I can't understand why it doesn't find the correct value. Thanks, Mária On 19/01/2017 11:22, Francesco Chicchiriccò wrote: > On 18/01/2017 14:13, Francesco Chicchiriccò wrote: >> On 18/01/2017 11:59, Francesco Chicchiriccò wrote: >>> On 18/01/2017 11:38, Tech wrote: >>>> Hello, >>>> >>>> we faced something that could be a bug in version 2.0.1 and version >>>> 2.0.2
Re: Admin user interface - custom fields order
Hello Andrea, thanks for your feedback, we are gonna use in this case directly the version 2.0.3. When will it be officially released? Is there a page with all the improvement/bug fixes for this new release? Thanks On 02/02/2017 12:36, andrea wrote: > > Hi, > > In addition to what said yesterday starting from version 2.0.3 > (currently SNAPSHOT) you can refer to [5] to add, remove, edit USER > attributes sorting strategies. > > Best regards, > Andrea > > [5] > https://github.com/apache/syncope/blob/2_0_X/client/enduser/src/main/resources/META-INF/resources/app/js/app.js#L392 > > > Il 01/02/2017 16:22, andrea ha scritto: >> >> Il 01/02/2017 15:13, Tech ha scritto: >>> >>> Dear all, >>> >> Good evening, >> >> please see my response inline. >>> >>> we created some custom fields, like fname and lname. >>> >>> We added to the BaseUser class and we have in the order: >>> >>> * email >>> * fname >>> * lname >>> >>> We log as user to the interface to register a new user, and this >>> order is respected. >>> >>> We go back to the Console and using the interface "Edit AnyTypeClass >>> BaseUser" we change the order as: >>> >>> * lname >>> * fname >>> * email >>> >>> We log with the old user, but the order is still the old one. >>> >>> We create a new user and also in this case the order of the fields >>> is still the old one. >>> >>> Are we missing any step here? >>> >> No, but you have to consider that ordering of attributes on the >> Enduser Console is forced to be *alphabetical*. So the result will >> ever be: >> >> * email >> * fname >> * lname >> >> moreover the order defined during "Edit AnyTypeClass BaseUser" does >> not matter. >> The order defined in that form is not applied to other forms, >> consider the case in which an user or any type has two auxiliary >> classes (one of the AnyTypeClasses available), which sorting will be >> taken? >> On the *administration console* the ordering of the attributes into >> the edit form is alphabetical, too; though it can be customized >> through advanced techniques. >> >> To force another kind of schema sorting in the *Enduser Console* you >> should edit UserController.js (see [1]) by sorting schemas variable >> or schemaService.js (see [2] and [3]) by sorting response.data (you >> may extract it into a new variable). >> We created just now a new issue about a better sorting customization; >> please take a look at [4]. >>> >>> Thanks >>> >> HTH regards, >> Andrea >> >> [1] >> https://github.com/apache/syncope/blob/2_0_X/client/enduser/src/main/resources/META-INF/resources/app/js/controllers/UserController.js#L71 >> [2] >> https://github.com/apache/syncope/blob/2_0_X/client/enduser/src/main/resources/META-INF/resources/app/js/services/schemaService.js#L33 >> [3] >> https://github.com/apache/syncope/blob/2_0_X/client/enduser/src/main/resources/META-INF/resources/app/js/services/schemaService.js#L45 >> [4] https://issues.apache.org/jira/browse/SYNCOPE-1005 >> -- >> Andrea Patricelli >> >> Tirasa - Open Source Excellence >> http://www.tirasa.net/ >> >> PMC member at The Apache Software Foundation >> Syncope > > -- > Andrea Patricelli > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > PMC member at The Apache Software Foundation > Syncope
Schema types - Non-Editable and Hidden fields
Dear Experts, We want to associate some custom fields to a user and we were wondering if: 1) a field could be visible for the user but not editable, for example the First/Last names. We saw from the console the option to make not-editable, but, after checking this flag, also the administrator is prevented by edit this field. Is there a way to let the administrator to update these information without temporary uncheck the flag or modifying the information directly in the DB? 2) a field should be present and linked to the user, for example we might need a technical information like a copy of the ObjectGUID, but we don't want to display this to the user, is it possible to keep it hidden by the user, but visible from the Console? Thanks
Re: Deploy MVN Syncope with Workflow
Apparently is working: we modified the pom.xml in common/core/console/enduser removing the references to the test, we modified the core/src/test/resources file replacing the one present into the "main". We redeployed and for now it looks ok. Thank you On 02/02/2017 14:33, Francesco Chicchiriccò wrote: > On 02/02/2017 14:27, Tech wrote: >> The point is that we create a brand new database (empty), we >> deploying using "-P all" and for some reason the database is already >> filled with some test data. >> >> We see that there are already some connectors configured, some roles >> and moreover some users like "*Verdi*", "*Rossini*" and "*Vivaldi*" >> that we don't understand where they are coming from. > > This is the test content coming from > > core/src/test/resources/domains/MasterContent.xml > > which is normally only loaded when starting in embedded mode; in > production mode (e.g. with plain build) the content from > > core/src/main/resources/domains/MasterContent.xml > > is loaded instead. > > You should identify which MasterContent.xml is actually loaded when > starting with an empty database, and possibly why. > > Normally, the test content is expected to be loaded exclusively in the > in-memory H2 instance used by embedded mode. > > Regards. > >> On 02/02/2017 12:25, Francesco Chicchiriccò wrote: >>> On 02/02/2017 12:21, Tech wrote: >>>> >>>> Dear experts, >>>> >>>> we would like to deploy syncope 2.0.2 using the workflows. >>>> >>>> We are using this command: >>>> >>>> * mvn -P all clean verify -Dconf.directory=/opt/syncope/conf >>>> -Dbundles.directory=/opt/syncope/bundles >>>> -Dlog.directory=/opt/syncope/log >>>> >>>> In the >>>> >>>> * core/src/main/resources/all/provisioning.properties and >>>> * core/src/main/resources/provisioning.properties >>>> >>>> we configured >>>> >>>> * quartz.sql=tables_mariadb.sql >>>> >>>> and in the >>>> >>>> * core/src/main/resources/domain/Master.properties >>>> >>>> we configured our MariaDB, but we are still pointing to the H2, >>>> while deploying without the option "-P all" we can correctly point >>>> to our MariaDB. >>>> >>>> Is there any other parameter that we should configure? >>> >>> If you want to use, in the application deployed into the external >>> Java EE container (for example) >>> >>> core/src/main/resources/all/provisioning.properties >>> core/src/main/resources/all/workflow.properties >>> >>> instead of >>> >>> core/src/main/resources/provisioning.properties >>> core/src/main/resources/workflow.properties >>> >>> you will need to copy >>> >>> core/src/main/resources/all/provisioning.properties >>> core/src/main/resources/all/workflow.properties >>> >>> to /opt/syncope/conf, as you have configured such directory to be >>> the source for configuration. >>> >>> HTH >>> Regards. > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
Re: Deploy MVN Syncope with Workflow
The point is that we create a brand new database (empty), we deploying using "-P all" and for some reason the database is already filled with some test data. We see that there are already some connectors configured, some roles and moreover some users like "*Verdi*", "*Rossini*" and "*Vivaldi*" that we don't understand where they are coming from. We don't think that this is the expected behavior, could you please advise? Thanks On 02/02/2017 12:25, Francesco Chicchiriccò wrote: > On 02/02/2017 12:21, Tech wrote: >> >> Dear experts, >> >> we would like to deploy syncope 2.0.2 using the workflows. >> >> We are using this command: >> >> * mvn -P all clean verify -Dconf.directory=/opt/syncope/conf >> -Dbundles.directory=/opt/syncope/bundles >> -Dlog.directory=/opt/syncope/log >> >> In the >> >> * core/src/main/resources/all/provisioning.properties and >> * core/src/main/resources/provisioning.properties >> >> we configured >> >> * quartz.sql=tables_mariadb.sql >> >> and in the >> >> * core/src/main/resources/domain/Master.properties >> >> we configured our MariaDB, but we are still pointing to the H2, while >> deploying without the option "-P all" we can correctly point to our >> MariaDB. >> >> Is there any other parameter that we should configure? > > If you want to use, in the application deployed into the external Java > EE container (for example) > > core/src/main/resources/all/provisioning.properties > core/src/main/resources/all/workflow.properties > > instead of > > core/src/main/resources/provisioning.properties > core/src/main/resources/workflow.properties > > you will need to copy > > core/src/main/resources/all/provisioning.properties > core/src/main/resources/all/workflow.properties > > to /opt/syncope/conf, as you have configured such directory to be the > source for configuration. > > HTH > Regards. > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/
Deploy MVN Syncope with Workflow
Dear experts, we would like to deploy syncope 2.0.2 using the workflows. We are using this command: * mvn -P all clean verify -Dconf.directory=/opt/syncope/conf -Dbundles.directory=/opt/syncope/bundles -Dlog.directory=/opt/syncope/log In the * core/src/main/resources/all/provisioning.properties and * core/src/main/resources/provisioning.properties we configured * quartz.sql=tables_mariadb.sql and in the * core/src/main/resources/domain/Master.properties we configured our MariaDB, but we are still pointing to the H2, while deploying without the option "-P all" we can correctly point to our MariaDB. Is there any other parameter that we should configure? Thanks
Admin user interface - custom fields order
Dear all, we created some custom fields, like fname and lname. We added to the BaseUser class and we have in the order: * email * fname * lname We log as user to the interface to register a new user, and this order is respected. We go back to the Console and using the interface "Edit AnyTypeClass BaseUser" we change the order as: * lname * fname * email We log with the old user, but the order is still the old one. We create a new user and also in this case the order of the fields is still the old one. Are we missing any step here? Thanks
Re: Active Directory password propagation
The value in 'password.cipher.algorithm' was SHA1.
We updated to AES, we changed again the password for the user and we
tried to login again to the enduser portal.
It's working, we tried to connect to AD but without success.
We realized after that the password, with a difference with the other
fields, is not immediately propagate when changed, but it's only
propagated by the scheduler.
Can this be changed?
Thanks for your support
On 30/01/2017 15:24, Francesco Chicchiriccò wrote:
> On 30/01/2017 15:18, Tech wrote:
>> Yes, I can confirm, right in this moment we are only performing
>> manual provisioning.
>>
>> This is of course not the goal, but before moving to an automatic
>> provision of accounts we want the manual one working
>
> What is your value for the 'password.cipher.algorithm' general
> configuration parameter? If not 'AES', pushing password values (as any
> other encrypted value) will not work anyway.
>
> The point is that Active Directory requires cleartext password values
> (encrypted via ConnId's GuardedString), which are normally available
> only during user update, not later. This unless AES (e.g. reversible
> encryption) is set for internal password values.
> Provisioning - via resource assignment - is part of user update, push
> occurs after user update.
>
> Regards.
>
>> On 30/01/2017 15:14, Francesco Chicchiriccò wrote:
>>> On 30/01/2017 15:11, Tech wrote:
>>>> We are associating using a manual provisioning
>>>
>>> Do you mean that you are only relying on a push task for
>>> provisioning to AD?
>>>
>>> Could you confirm that you are *not* assigning the AD resource
>>> directly to the users, neither via group membership or template?
>>>
>>>> Here the main information:
>>>>
>>>>
>>>>
>>>> Connector version 1.3.2
>>>>
>>>> -SSL enabled
>>>> -Retrieve deleted users enabled
>>>> -Retrieve deleted groups enabled
>>>> -Trust all certs enabled
>>>>
>>>> Entry object classes:
>>>> -Top
>>>> -person
>>>> -organizationalPerson
>>>> -inetOrgPerson
>>>> -user
>>>>
>>>> Custom user search filter
>>>> cn=*
>>>>
>>>> Rootsuffixes + base contexts + defaul people container:
>>>> ou=myad,dc=test,dc=local
>>>>
>>>> uidAttribute
>>>> - cn
>>>>
>>>> Object clases to synchronize
>>>> - user
>>>>
>>>>
>>>>
>>>> Resource:
>>>>
>>>> username -> cn (remote key)
>>>> password -> __PASSWORD__ (Password)
>>>> email -> mail
>>>> fn -> givenName
>>>> ln -> sn
>>>> username -> sAMAccountName
>>>>
>>>> Object link
>>>> 'CN='+username+',OU=myad,dc=test,dc=local'
>>>>
>>>>
>>>>
>>>>
>>>> Push tasks:
>>>>
>>>> Active
>>>> Matching rule : Update
>>>> Unmatching rule: provision
>>>> Allow Create, update, delete, sync status
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 30/01/2017 15:01, Francesco Chicchiriccò wrote:
>>>>> On 30/01/2017 14:53, Tech wrote:
>>>>>> This is what happen when I open the Password Manager, while when
>>>>>> I update the password no log is generated.
>>>>>
>>>>> This is what I suspected: you could definitely find a confirmation
>>>>> if you are able to verify that the user on Active Directory has
>>>>> still the password set during create (while on Syncope the
>>>>> password value was changed).
>>>>>
>>>>> How are you associating the users to the AD resource? Directly or
>>>>> via group? Could you please enlist your full connector
>>>>> configuration (with *all* options) and resource mapping?
>>>>> Screenshots will also work via http://pasteboard.co/, for example.
>>>>>
>>>>> Regards.
>>>>>
>>>>>> 13:43:57.477 DEBUG Enter: getObject(ObjectClass: __ACCOUNT__,
>>>>>> Attribute: {Name=__UID__, Value=[user07]}, OperationOptions:
>>>>>> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]})
>>>>>> Method: getObject
>>>>>> 13
Re: Active Directory password propagation
Yes, I can confirm, right in this moment we are only performing manual
provisioning.
This is of course not the goal, but before moving to an automatic
provision of accounts we want the manual one working
On 30/01/2017 15:14, Francesco Chicchiriccò wrote:
> On 30/01/2017 15:11, Tech wrote:
>> We are associating using a manual provisioning
>
> Do you mean that you are only relying on a push task for provisioning
> to AD?
>
> Could you confirm that you are *not* assigning the AD resource
> directly to the users, neither via group membership or template?
>
>> Here the main information:
>>
>>
>>
>> Connector version 1.3.2
>>
>> -SSL enabled
>> -Retrieve deleted users enabled
>> -Retrieve deleted groups enabled
>> -Trust all certs enabled
>>
>> Entry object classes:
>> -Top
>> -person
>> -organizationalPerson
>> -inetOrgPerson
>> -user
>>
>> Custom user search filter
>> cn=*
>>
>> Rootsuffixes + base contexts + defaul people container:
>> ou=myad,dc=test,dc=local
>>
>> uidAttribute
>> - cn
>>
>> Object clases to synchronize
>> - user
>>
>>
>>
>> Resource:
>>
>> username -> cn (remote key)
>> password -> __PASSWORD__ (Password)
>> email -> mail
>> fn -> givenName
>> ln -> sn
>> username -> sAMAccountName
>>
>> Object link
>> 'CN='+username+',OU=myad,dc=test,dc=local'
>>
>>
>>
>>
>> Push tasks:
>>
>> Active
>> Matching rule : Update
>> Unmatching rule: provision
>> Allow Create, update, delete, sync status
>>
>>
>>
>>
>>
>>
>>
>> On 30/01/2017 15:01, Francesco Chicchiriccò wrote:
>>> On 30/01/2017 14:53, Tech wrote:
>>>> This is what happen when I open the Password Manager, while when I
>>>> update the password no log is generated.
>>>
>>> This is what I suspected: you could definitely find a confirmation
>>> if you are able to verify that the user on Active Directory has
>>> still the password set during create (while on Syncope the password
>>> value was changed).
>>>
>>> How are you associating the users to the AD resource? Directly or
>>> via group? Could you please enlist your full connector configuration
>>> (with *all* options) and resource mapping? Screenshots will also
>>> work via http://pasteboard.co/, for example.
>>>
>>> Regards.
>>>
>>>> 13:43:57.477 DEBUG Enter: getObject(ObjectClass: __ACCOUNT__,
>>>> Attribute: {Name=__UID__, Value=[user07]}, OperationOptions:
>>>> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]})
>>>> Method: getObject
>>>> 13:43:57.477 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
>>>> LdapFilter[nativeFilter: (cn=user07); entryDN: null],
>>>> org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@3c72ca1f,
>>>> OperationOptions:
>>>> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]})
>>>> Method: executeQuery
>>>> 13:43:57.478 WARN Reading passwords not supported Method:
>>>> getAttributesToGet
>>>> 13:43:57.478 WARN Attribute __ENABLE__ of object class __ACCOUNT__
>>>> is not mapped to an LDAP attribute Method: getLdapAttribute
>>>> 13:43:57.478 DEBUG Options filter: {0} null Method:
>>>> getInternalSearch
>>>> 13:43:57.478 DEBUG Search filter: {0} cn=* Method:
>>>> getInternalSearch
>>>> 13:43:57.478 DEBUG Native filter: {0} (cn=user07) Method:
>>>> getInternalSearch
>>>> 13:43:57.478 DEBUG Membership filter: {0} Method:
>>>> getInternalSearch
>>>> 13:43:57.478 DEBUG Searching in [OU=myad,DC=test,DC=local] with
>>>> filter
>>>> (&(&(objectClass=top)(objectClass=person)(objectClass=organizationalPerson)(objectClass=user))(cn=user07)(cn=*))
>>>> and SearchControls: {returningAttributes=[cn, entryDN, givenName,
>>>> mail, sAMAccountName, sn, unicodePwd, userAccountControl],
>>>> scope=SUBTREE} Method: doSearch
>>>> 13:43:57.479 DEBUG User Account Control: 512Method:
>>>> createConnectorObject
>>>> 13:43:57.479 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
>>>> Value=[user07]}, ObjectClass=ObjectClass: __ACCOUNT__,
>>>> Attributes=[Attribute: {Name=__PASSWORD
Re: Active Directory password propagation
We are associating using a manual provisioning
Here the main information:
Connector version 1.3.2
-SSL enabled
-Retrieve deleted users enabled
-Retrieve deleted groups enabled
-Trust all certs enabled
Entry object classes:
-Top
-person
-organizationalPerson
-inetOrgPerson
-user
Custom user search filter
cn=*
Rootsuffixes + base contexts + defaul people container:
ou=myad,dc=test,dc=local
uidAttribute
- cn
Object clases to synchronize
- user
Resource:
username -> cn (remote key)
password -> __PASSWORD__ (Password)
email -> mail
fn -> givenName
ln -> sn
username -> sAMAccountName
Object link
'CN='+username+',OU=myad,dc=test,dc=local'
Push tasks:
Active
Matching rule : Update
Unmatching rule: provision
Allow Create, update, delete, sync status
On 30/01/2017 15:01, Francesco Chicchiriccò wrote:
> On 30/01/2017 14:53, Tech wrote:
>> This is what happen when I open the Password Manager, while when I
>> update the password no log is generated.
>
> This is what I suspected: you could definitely find a confirmation if
> you are able to verify that the user on Active Directory has still the
> password set during create (while on Syncope the password value was
> changed).
>
> How are you associating the users to the AD resource? Directly or via
> group? Could you please enlist your full connector configuration (with
> *all* options) and resource mapping? Screenshots will also work via
> http://pasteboard.co/, for example.
>
> Regards.
>
>> 13:43:57.477 DEBUG Enter: getObject(ObjectClass: __ACCOUNT__,
>> Attribute: {Name=__UID__, Value=[user07]}, OperationOptions:
>> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]})
>> Method: getObject
>> 13:43:57.477 DEBUG Enter: executeQuery(ObjectClass: __ACCOUNT__,
>> LdapFilter[nativeFilter: (cn=user07); entryDN: null],
>> org.identityconnectors.framework.impl.api.local.operations.SearchImpl$1@3c72ca1f,
>> OperationOptions:
>> {ATTRS_TO_GET:[__PASSWORD__,mail,sAMAccountName,givenName,__NAME__,cn,sn,__UID__,__ENABLE__]})
>> Method: executeQuery
>> 13:43:57.478 WARN Reading passwords not supported Method:
>> getAttributesToGet
>> 13:43:57.478 WARN Attribute __ENABLE__ of object class __ACCOUNT__
>> is not mapped to an LDAP attribute Method: getLdapAttribute
>> 13:43:57.478 DEBUG Options filter: {0} null Method: getInternalSearch
>> 13:43:57.478 DEBUG Search filter: {0} cn=* Method: getInternalSearch
>> 13:43:57.478 DEBUG Native filter: {0} (cn=user07) Method:
>> getInternalSearch
>> 13:43:57.478 DEBUG Membership filter: {0} Method: getInternalSearch
>> 13:43:57.478 DEBUG Searching in [OU=myad,DC=test,DC=local] with
>> filter
>> (&(&(objectClass=top)(objectClass=person)(objectClass=organizationalPerson)(objectClass=user))(cn=user07)(cn=*))
>> and SearchControls: {returningAttributes=[cn, entryDN, givenName,
>> mail, sAMAccountName, sn, unicodePwd, userAccountControl],
>> scope=SUBTREE} Method: doSearch
>> 13:43:57.479 DEBUG User Account Control: 512Method:
>> createConnectorObject
>> 13:43:57.479 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
>> Value=[user07]}, ObjectClass=ObjectClass: __ACCOUNT__,
>> Attributes=[Attribute: {Name=__PASSWORD__,
>> Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
>> Attribute: {Name=userAccountControl, Value=[512]}, Attribute:
>> {Name=sAMAccountName, Value=[user07]}, Attribute: {Name=mail,
>> Value=[user07@test.local]}, Attribute: {Name=__NAME__,
>> Value=[CN=user07,OU=myad,DC=test,DC=local]}, Attribute: {Name=cn,
>> Value=[user07]}, Attribute: {Name=sn, Value=[oln07updated]},
>> Attribute: {Name=__UID__, Value=[user07]}, Attribute:
>> {Name=__ENABLE__, Value=[true]}, Attribute: {Name=givenName,
>> Value=[ofn07updated]}], Name=Attribute: {Name=__NAME__,
>> Value=[CN=user07,OU=myad,DC=test,DC=local]}} Method: handle
>> 13:43:57.479 DEBUG Return: falseMethod: handle
>> 13:43:57.479 DEBUG Return Method: executeQuery
>> 13:43:57.480 DEBUG Return: {Uid=Attribute: {Name=__UID__,
>> Value=[user07]}, ObjectClass=ObjectClass: __ACCOUNT__,
>> Attributes=[Attribute: {Name=__PASSWORD__,
>> Value=[org.identityconnectors.common.security.GuardedString@204e249b]},
>> Attribute: {Name=sAMAccountName, Value=[user07]}, Attribute:
>> {Name=mail, Value=[user07@test.local]}, Attribute: {Name=__NAME__,
>> Value=[CN=user07,OU=myad,DC=test,DC=local]}, Attribute: {Name=cn,
>> Value=[user07]}, Attribute: {Name=sn, Value=[oln07updated]},
>> Attribute: {Name=__UID__, Value=[user07]}, Attribute:
>> {Name=__ENABLE__, Value=[true]}, Attribute: {
Re: Active Directory password propagation
When we create the user we are able to initialize the correct password, connecting to the target system we can verify that Syncope did its job. If the Admin tries to reset the password from the console, or if the user tries to change is password from the enduser interface, the password is still correctly updated into Syncope, but it's not propagated to AD, therefore the user will be able to login only using the old password. On 30/01/2017 12:28, Tech wrote: > I'm not sure about this step. > > As mentioned we can already propagate changes as "email, "first name" > and "last name". > > The AD user that we are using is able to change the passwords of other > AD users, create, update and delete other users. > > I think that there is an additional step that was not performed in > Syncope. > > > > > > On 27/01/2017 16:32, Fabio Martelli wrote: >> Il 27/01/2017 15:53, Tech ha scritto: >>> Yes, we are connecting via SSL. >>> >>> We know that the connection is working because we are still able to >>> propagate the user modification like firstname and lastname. >>> >>> We can change the password and internally is working, but it's not >>> propagated to AD. >> When you performed the change password by using the administration >> console, did you select AD resource in the list provided after >> password fields? >> Are you sure that the user principal configured to perform updates >> into AD owns all the needed entitlements? >>> >>> >>> >>> >>> >>> >>> the On 27/01/2017 15:42, Fabio Martelli wrote: >>>> Hi, find my comment in-line. >>>> Regards, >>>> F. >>>> >>>> Il 27/01/2017 12:12, Tech ha scritto: >>>>> >>>>> Hello, >>>>> >>>>> we are working on the password propagation using the AD connector. >>>>> >>>>> We are able to check the connectivity both using plain and SSL, we >>>>> are able to create new users and to update information like email, >>>>> first name and last name. >>>>> >>>>> We edit the connector: >>>>> >>>>> * We check SSL >>>>> * we change the Server port to 636 >>>>> * We enable Trust all certs >>>>> >>>>> We run again some modification and the first name and last name >>>>> are still updated. >>>>> >>>>> We try now to change the password, both from user and admin interface. >>>>> >>>>> The user can correctly access to Syncope using the new >>>>> credentials, while we detect that the password is not correctly >>>>> propagated to the target system. >>>>> >>>> >>>> Do you mean that you can still access with the previous one? >>>> Please note that you can change password by working in SSL only [1]. >>>> >>>> Regards, >>>> F. >>>> >>>> [1] >>>> https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory(JNDI)-Configuration >>>> >>>> >>>>> Any clues? >>>>> >>>>> Thanks! >>>>> >>>> >>>> >>>> -- >>>> Fabio Martelli >>>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44 >>>> http://blog.tirasa.net/author/fabio/index.html >>>> >>>> Tirasa - Open Source Excellence >>>> http://www.tirasa.net/ >>>> >>>> Apache Syncope PMC >>>> http://people.apache.org/~fmartelli/ >>> >>> >> >> >> -- >> Fabio Martelli >> https://it.linkedin.com/pub/fabio-martelli/1/974/a44 >> http://blog.tirasa.net/author/fabio/index.html >> >> Tirasa - Open Source Excellence >> http://www.tirasa.net/ >> >> Apache Syncope PMC >> http://people.apache.org/~fmartelli/ > >
Re: Active Directory password propagation
I'm not sure about this step. As mentioned we can already propagate changes as "email, "first name" and "last name". The AD user that we are using is able to change the passwords of other AD users, create, update and delete other users. I think that there is an additional step that was not performed in Syncope. On 27/01/2017 16:32, Fabio Martelli wrote: > Il 27/01/2017 15:53, Tech ha scritto: >> Yes, we are connecting via SSL. >> >> We know that the connection is working because we are still able to >> propagate the user modification like firstname and lastname. >> >> We can change the password and internally is working, but it's not >> propagated to AD. > When you performed the change password by using the administration > console, did you select AD resource in the list provided after > password fields? > Are you sure that the user principal configured to perform updates > into AD owns all the needed entitlements? >> >> >> >> >> >> >> the On 27/01/2017 15:42, Fabio Martelli wrote: >>> Hi, find my comment in-line. >>> Regards, >>> F. >>> >>> Il 27/01/2017 12:12, Tech ha scritto: >>>> >>>> Hello, >>>> >>>> we are working on the password propagation using the AD connector. >>>> >>>> We are able to check the connectivity both using plain and SSL, we >>>> are able to create new users and to update information like email, >>>> first name and last name. >>>> >>>> We edit the connector: >>>> >>>> * We check SSL >>>> * we change the Server port to 636 >>>> * We enable Trust all certs >>>> >>>> We run again some modification and the first name and last name are >>>> still updated. >>>> >>>> We try now to change the password, both from user and admin interface. >>>> >>>> The user can correctly access to Syncope using the new credentials, >>>> while we detect that the password is not correctly propagated to >>>> the target system. >>>> >>> >>> Do you mean that you can still access with the previous one? >>> Please note that you can change password by working in SSL only [1]. >>> >>> Regards, >>> F. >>> >>> [1] >>> https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory(JNDI)-Configuration >>> >>> >>>> Any clues? >>>> >>>> Thanks! >>>> >>> >>> >>> -- >>> Fabio Martelli >>> https://it.linkedin.com/pub/fabio-martelli/1/974/a44 >>> http://blog.tirasa.net/author/fabio/index.html >>> >>> Tirasa - Open Source Excellence >>> http://www.tirasa.net/ >>> >>> Apache Syncope PMC >>> http://people.apache.org/~fmartelli/ >> >> > > > -- > Fabio Martelli > https://it.linkedin.com/pub/fabio-martelli/1/974/a44 > http://blog.tirasa.net/author/fabio/index.html > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Apache Syncope PMC > http://people.apache.org/~fmartelli/
Re: Active Directory password propagation
Yes, we are connecting via SSL. We know that the connection is working because we are still able to propagate the user modification like firstname and lastname. We can change the password and internally is working, but it's not propagated to AD. the On 27/01/2017 15:42, Fabio Martelli wrote: > Hi, find my comment in-line. > Regards, > F. > > Il 27/01/2017 12:12, Tech ha scritto: >> >> Hello, >> >> we are working on the password propagation using the AD connector. >> >> We are able to check the connectivity both using plain and SSL, we >> are able to create new users and to update information like email, >> first name and last name. >> >> We edit the connector: >> >> * We check SSL >> * we change the Server port to 636 >> * We enable Trust all certs >> >> We run again some modification and the first name and last name are >> still updated. >> >> We try now to change the password, both from user and admin interface. >> >> The user can correctly access to Syncope using the new credentials, >> while we detect that the password is not correctly propagated to the >> target system. >> > > Do you mean that you can still access with the previous one? > Please note that you can change password by working in SSL only [1]. > > Regards, > F. > > [1] > https://connid.atlassian.net/wiki/pages/viewpage.action?pageId=360482#ActiveDirectory(JNDI)-Configuration > > >> Any clues? >> >> Thanks! >> > > > -- > Fabio Martelli > https://it.linkedin.com/pub/fabio-martelli/1/974/a44 > http://blog.tirasa.net/author/fabio/index.html > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Apache Syncope PMC > http://people.apache.org/~fmartelli/
Active Directory password propagation
Hello, we are working on the password propagation using the AD connector. We are able to check the connectivity both using plain and SSL, we are able to create new users and to update information like email, first name and last name. We edit the connector: * We check SSL * we change the Server port to 636 * We enable Trust all certs We run again some modification and the first name and last name are still updated. We try now to change the password, both from user and admin interface. The user can correctly access to Syncope using the new credentials, while we detect that the password is not correctly propagated to the target system. Any clues? Thanks!
DelegateAdministrationException: Missing entitlement or realm administration for USER
Dear experts, we defined some custom fields into our Syncope 2.0.1. We create a user we fill his fields and we can save correctly. If we add an additional field and we try to edit the user from the syncope-enduser we are not able to save the modification and the following error-popup is displayed: "errorLogin failed: Remote exception with status code: NOT_FOUND". What should we do to avoid such errors? Thanks
Label on custom attributes
Dear all,
we need to create custom attributes in Syncope, but we realized the
correspondence 1:1 with Key/Column/Label.
For example we might need to display some attributes that should not be
read necessary in English and that could contain accents.
For example we imagine something like this:
firstname: {
"lang":"en" {
"value":"Name"
},
"lang":"fr": {
"value":"Prénom"
}
}
In this case we could keep a stick reference for the name, in our case
"firstname", but after display in a different way (and language) and
being able to implement also accents: is there a way to do it?
Thanks!
Password reset procedure from enduser interface
Hello, we faced something that could be a bug in version 2.0.1 and version 2.0.2. We created a SecurityQuestion from the Admin interface and the user is prompted to enter one during the creation of his account. The SecurityQuestion is correctly stored into the DB. We "forget" the password and we try to recover it using the interface, but we cannot reset it. This is happening both for existing and new users. Could you please double-check? Thanks, Mária
Re: Date format on user self-registration
Hello, thanks, in the version 2.0.2 the Date is working correctly. Regards On 18/01/2017 10:31, Francesco Chicchiriccò wrote: > On 18/01/2017 10:23, Tech wrote: >> Hello, >> >> we created the new java files as requested, we modified the >> dynamicPlainAttribute.js , but we didn't resolve the situation yet. >> >> We tried two scenarios: the first with an existing user that needs to >> enter the date field where before it was empty, the second with a brand >> new user where he enter for the first time the information, but also in >> this case the date is not saved into the system. >> >> Could you please double check? > > Hi, > I have just tried locally and it worked as expected; you could also > try yourself with our public demo at > > http://syncope-vm.apache.org:9080/syncope-console/ > http://syncope-vm.apache.org:9080/syncope-enduser/ > > The version deployed there is the latest 2.0.2-SNAPSHOT. > > Regards. > >> On 13/01/2017 11:58, Francesco Chicchiriccò wrote: >>> On 2017-01-12 14:50 (+0100), Francesco Chicchiriccò >>> <ilgro...@apache.org> wrote: >>>> On 12/01/2017 14:27, Tech wrote: >>>>> Dear experts, >>>>> >>>>> We added the date as custom field, we added it to the BaseUser class >>>>> and after we added to the USER schema. >>>>> >>>>> During the self registration we are able to display the field, >>>>> that is >>>>> correctly displayed as Date (we can also see the calendar button). >>>>> >>>>> We can complete the registration procedure, but the information is >>>>> not >>>>> stored into the Database. >>>>> >>>>> We modified the Conversion-Pattern using -MM-dd, but this changes >>>>> only the way the data is displayed in the interface, but we can't >>>>> still store the information into the database. >>>>> >>>> Hi, >>>> it seems you've spotted a bug in the Enduser UI; I have just performed >>>> the following steps: >>>> >>>> 1. from Admin UI, create new Date schema with conversion pattern >>>> '-MM-dd' and added to the base type for USER >>>> 2. perform self-registration via Enduser UI, provided a value for the >>>> new Date attribute >>>> 3. open the new user from Admin UI, no value found for the new Date >>>> attribute >>>> >>>> So, the bug is confirmed. >>>> >>>> Moreover, I also did: >>>> >>>> 4. from Admin UI, set a value for the new Date attribute on the new >>>> user >>>> 5. log into the Enduser UI as the new user, see the value set from >>>> Admin >>>> UI, then update the Date schema with a new value >>>> 6. from Admin UI, see the new value as provided via Enduser UI >>>> >>>> Hence the bug seems to occur only during self-registration. >>>> >>>> Would you mind opening an issue >>>> on >>>> >>>> https://issues.apache.org/jira/browse/SYNCOPE/ >>>> >>>> ? >>> Hi, >>> I have just committed a fix for SYNCOPE-992 (the issue you've opened >>> as request above, thx). >>> >>> Such fix will be available with release of Apache Syncope 2.0.2; >>> should you want to backport the fix on your local project, you will >>> have to >>> >>> 1. create the directory >>> >>> enduser/src/main/java/org/apache/syncope/client/enduser/resources/ >>> >>> the download the class >>> >>> https://github.com/apache/syncope/blob/eded0eb3af5b96b513d934f19509bdf4b06e9df0/client/enduser/src/main/java/org/apache/syncope/client/enduser/resources/UserSelfCreateResource.java >>> >>> >>> in the new created directory >>> >>> 2. replace the file content of >>> >>> enduser/src/main/webapp/app/js/directives/dynamicPlainAttribute.js >>> >>> with the content from >>> >>> https://github.com/apache/syncope/blob/eded0eb3af5b96b513d934f19509bdf4b06e9df0/client/enduser/src/main/resources/META-INF/resources/app/js/directives/dynamicPlainAttribute.js >>> >>> >>> Afterwards, naturally, you'll have to rebuild & redeploy. >>> >>> Regards. >
Re: Date format on user self-registration
Hello, we created the new java files as requested, we modified the dynamicPlainAttribute.js , but we didn't resolve the situation yet. We tried two scenarios: the first with an existing user that needs to enter the date field where before it was empty, the second with a brand new user where he enter for the first time the information, but also in this case the date is not saved into the system. Could you please double check? Thanks On 13/01/2017 11:58, Francesco Chicchiriccò wrote: > On 2017-01-12 14:50 (+0100), Francesco Chicchiriccò <ilgro...@apache.org> > wrote: >> On 12/01/2017 14:27, Tech wrote: >>> Dear experts, >>> >>> We added the date as custom field, we added it to the BaseUser class >>> and after we added to the USER schema. >>> >>> During the self registration we are able to display the field, that is >>> correctly displayed as Date (we can also see the calendar button). >>> >>> We can complete the registration procedure, but the information is not >>> stored into the Database. >>> >>> We modified the Conversion-Pattern using -MM-dd, but this changes >>> only the way the data is displayed in the interface, but we can't >>> still store the information into the database. >>> >> Hi, >> it seems you've spotted a bug in the Enduser UI; I have just performed >> the following steps: >> >> 1. from Admin UI, create new Date schema with conversion pattern >> '-MM-dd' and added to the base type for USER >> 2. perform self-registration via Enduser UI, provided a value for the >> new Date attribute >> 3. open the new user from Admin UI, no value found for the new Date >> attribute >> >> So, the bug is confirmed. >> >> Moreover, I also did: >> >> 4. from Admin UI, set a value for the new Date attribute on the new user >> 5. log into the Enduser UI as the new user, see the value set from Admin >> UI, then update the Date schema with a new value >> 6. from Admin UI, see the new value as provided via Enduser UI >> >> Hence the bug seems to occur only during self-registration. >> >> Would you mind opening an issue >> on >> >> https://issues.apache.org/jira/browse/SYNCOPE/ >> >> ? > Hi, > I have just committed a fix for SYNCOPE-992 (the issue you've opened as > request above, thx). > > Such fix will be available with release of Apache Syncope 2.0.2; should you > want to backport the fix on your local project, you will have to > > 1. create the directory > > enduser/src/main/java/org/apache/syncope/client/enduser/resources/ > > the download the class > > https://github.com/apache/syncope/blob/eded0eb3af5b96b513d934f19509bdf4b06e9df0/client/enduser/src/main/java/org/apache/syncope/client/enduser/resources/UserSelfCreateResource.java > > in the new created directory > > 2. replace the file content of > > enduser/src/main/webapp/app/js/directives/dynamicPlainAttribute.js > > with the content from > > https://github.com/apache/syncope/blob/eded0eb3af5b96b513d934f19509bdf4b06e9df0/client/enduser/src/main/resources/META-INF/resources/app/js/directives/dynamicPlainAttribute.js > > Afterwards, naturally, you'll have to rebuild & redeploy. > > Regards.
Date format on user self-registration
Dear experts, We added the date as custom field, we added it to the BaseUser class and after we added to the USER schema. During the self registration we are able to display the field, that is correctly displayed as Date (we can also see the calendar button). We can complete the registration procedure, but the information is not stored into the Database. We modified the Conversion-Pattern using -MM-dd, but this changes only the way the data is displayed in the interface, but we can't still store the information into the database. Could you please advise? Thanks
Modification not stored into the system
Dear Experts, we installed Syncope and we were able to start it. We detected that the modification like creation of Realms or creation of Users were not registered into the platform because when we restart the AS, everything looks like a fresh installation. We thought that this could be related with the storing of information into a repository: following the confluence we modified the links to the repositories to MariaDB, we installed the new tablespace for Syncope, we restarted correcly the application, but the modification are still not kept when we restart the AS. We don't see any error into the logs, is there any step that we missed during the installation? Thanks
Re: Unable to install Syncope 2.0
Hello Francesco, thank you for your feedback, everything proceed well following this procedure. Thank you again for the support. On 2016-11-24 12:07, Francesco Chicchiriccò wrote: Hi, for the sake of clarity, the github repository [1] you mention below is a third party project maintained by my company and hence not directly under control of the Apache Syncope project. Anyway, as stated in the README.md, it is a kind of utility reference for running Apache Syncope in JBoss / Wildfly, built by applying the advices provided by the official documentation. For this reason, it is not meant for being deployed in Tomcat or other Java EE containers: if you need that, please follow the official documentation [2]. Coming to your error, the problem I read from the stacktrace below is that the admin console is not able to connect to the core (quick ref to Syncope architecture [3]), essentially because the port is wrong: 9080 while I suppose Wildfly is listening to 8080, as per default. Please note that this means anyway that the core was successfully deployed, as you can check by pointing your browser to http://host:8080/syncope/ which should display something similar to [4], e.g. the REST reference. The fix is easy, anyway: just copy the actual configuration files onto /opt/syncope/conf, the directory which was configured during the build: $ mvn -Dconf.directory=/opt/syncope/conf \ -Dbundles.directory=/opt/syncope/bundles \ -Dlog.directory=/opt/syncope/log clean package $ cp core/target/classes/*properties /opt/syncope/conf/ $ cp console/target/classes/*properties /opt/syncope/conf/ $ cp enduser/target/classes/*properties /opt/syncope/conf/ I have also updated the README.md there accordingly. HTH Regards. [1] https://github.com/Tirasa/syncopeOnJBoss/ [2] http://syncope.apache.org/docs/getting-started.html#maven-project [3] http://syncope.apache.org/docs/getting-started.html#a-bird-s-eye-view-on-the-architecture [4] http://syncope.apache.org/rest/2.0/index.html On 23/11/2016 20:18, Tech wrote: Dear Experts, we tried to install Syncope 2.0 on a Unix environment with these features: - CentOS7 - Java1.8.0.111 - Mvn 3.10 + - Tomcat 8.0.39 - Wildfly 10.1 We tried to follow this procedure https://github.com/Tirasa/syncopeOnJBoss/blob/master/README.md and we tried to deploy the war both in Tomcat and WildFly without success. We got this error when we start the application and we are not able to find a solution: could you please support? 19:35:20,844 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /syncope-console/: org.apache.wicket.WicketRuntimeException: Unable to instantiate web session class org.apache.syncope.client.console.SyncopeConsoleSession at org.apache.wicket.authroles.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:121) at org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:1714) at org.apache.wicket.Session.get(Session.java:169) at org.apache.syncope.client.console.SyncopeConsoleSession.get(SyncopeConsoleSession.java:103) at org.apache.syncope.client.console.SyncopeConsoleRequestCycleListener.onException(SyncopeConsoleRequestCycleListener.java:61) [..] Caused by: javax.ws.rs.ProcessingException: java.net.ConnectException: ConnectException invoking http://localhost:9080/syncope/rest/platform: Connection refused (Connection refused) at org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractClient.java:596) at org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient.java:578) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:748) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:231) at com.sun.proxy.$Proxy247.platform(Unknown Source) at org.apache.syncope.client.console.SyncopeConsoleSession.(SyncopeConsoleSession.java:113) ... 62 more [..] Caused by: java.net.ConnectException: ConnectException invoking http://localhost:9080/syncope/rest/platform: Connection refused (Connection refused) at sun.reflect.GeneratedConstructorAccessor102.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1377) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1361) [..] Caused by: java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206
Unable to install Syncope 2.0
Dear Experts, we tried to install Syncope 2.0 on a Unix environment with these features: - CentOS7 - Java1.8.0.111 - Mvn 3.10 + - Tomcat 8.0.39 - Wildfly 10.1 We tried to follow this procedure https://github.com/Tirasa/syncopeOnJBoss/blob/master/README.md and we tried to deploy the war both in Tomcat and WildFly without success. We got this error when we start the application and we are not able to find a solution: could you please support? 19:35:20,844 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /syncope-console/: org.apache.wicket.WicketRuntimeException: Unable to instantiate web session class org.apache.syncope.client.console.SyncopeConsoleSession at org.apache.wicket.authroles.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:121) at org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:1714) at org.apache.wicket.Session.get(Session.java:169) at org.apache.syncope.client.console.SyncopeConsoleSession.get(SyncopeConsoleSession.java:103) at org.apache.syncope.client.console.SyncopeConsoleRequestCycleListener.onException(SyncopeConsoleRequestCycleListener.java:61) [..] Caused by: javax.ws.rs.ProcessingException: java.net.ConnectException: ConnectException invoking http://localhost:9080/syncope/rest/platform: Connection refused (Connection refused) at org.apache.cxf.jaxrs.client.AbstractClient.checkClientException(AbstractClient.java:596) at org.apache.cxf.jaxrs.client.AbstractClient.preProcessResult(AbstractClient.java:578) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:748) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:231) at com.sun.proxy.$Proxy247.platform(Unknown Source) at org.apache.syncope.client.console.SyncopeConsoleSession.(SyncopeConsoleSession.java:113) ... 62 more [..] Caused by: java.net.ConnectException: ConnectException invoking http://localhost:9080/syncope/rest/platform: Connection refused (Connection refused) at sun.reflect.GeneratedConstructorAccessor102.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1377) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1361) [..] Caused by: java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) Thanks!
