[jira] [Assigned] (SYNCOPE-706) INTERNAL_SERVER_ERROR when authenticating with non existing username
[ https://issues.apache.org/jira/browse/SYNCOPE-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-706: -- Assignee: Francesco Chicchiriccò > INTERNAL_SERVER_ERROR when authenticating with non existing username > > > Key: SYNCOPE-706 > URL: https://issues.apache.org/jira/browse/SYNCOPE-706 > Project: Syncope > Issue Type: Bug > Components: client >Affects Versions: 2.0.0 >Reporter: Massimiliano Perrone >Assignee: Francesco Chicchiriccò > Fix For: 2.0.0 > > > I'm working on the master branch. > Trying to use the org.apache.syncope.client.lib.SyncopeClient class to call > the Syncope rest services, I get an INTERNAL_SERVER_ERROR creating the client > with a wrong username. > It works fine if I try to create the client with a right user and a wrong > password because I get "User admin not authenticated" exception message. > The stacktrace is: > org.apache.syncope.core.persistence.api.dao.NotFoundException: Null key > > org.apache.syncope.core.persistence.jpa.dao.AbstractAnyDAO.authFind(AbstractAnyDAO.java:87) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:606) > > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302) > > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) > > org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99) > > org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281) > > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > > org.apache.syncope.core.misc.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) > com.sun.proxy.$Proxy129.authFind(Unknown Source) > > org.apache.syncope.core.workflow.java.AbstractUserWorkflowAdapter.internalSuspend(AbstractUserWorkflowAdapter.java:95) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:606) > > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302) > > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) > > org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99) > > org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281) > > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > > org.apache.syncope.core.misc.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-706) INTERNAL_SERVER_ERROR when authenticating with non existing username
[ https://issues.apache.org/jira/browse/SYNCOPE-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954575#comment-14954575 ] ASF subversion and git services commented on SYNCOPE-706: - Commit a3e23c1f175dbdda338c4cf01d8acf6fc3c4f365 in syncope's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=a3e23c1 ] [SYNCOPE-706] Fix provided > INTERNAL_SERVER_ERROR when authenticating with non existing username > > > Key: SYNCOPE-706 > URL: https://issues.apache.org/jira/browse/SYNCOPE-706 > Project: Syncope > Issue Type: Bug > Components: client >Affects Versions: 2.0.0 >Reporter: Massimiliano Perrone >Assignee: Francesco Chicchiriccò > Fix For: 2.0.0 > > > I'm working on the master branch. > Trying to use the org.apache.syncope.client.lib.SyncopeClient class to call > the Syncope rest services, I get an INTERNAL_SERVER_ERROR creating the client > with a wrong username. > It works fine if I try to create the client with a right user and a wrong > password because I get "User admin not authenticated" exception message. > The stacktrace is: > org.apache.syncope.core.persistence.api.dao.NotFoundException: Null key > > org.apache.syncope.core.persistence.jpa.dao.AbstractAnyDAO.authFind(AbstractAnyDAO.java:87) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:606) > > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302) > > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) > > org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99) > > org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281) > > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > > org.apache.syncope.core.misc.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) > com.sun.proxy.$Proxy129.authFind(Unknown Source) > > org.apache.syncope.core.workflow.java.AbstractUserWorkflowAdapter.internalSuspend(AbstractUserWorkflowAdapter.java:95) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:606) > > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302) > > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) > > org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99) > > org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281) > > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > > org.apache.syncope.core.misc.spring.DomainTransactionInterceptor.invoke(DomainTransactionInterceptor.java:64) > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
ConfigurationLogic behavior
Hi all,
I found this "strange" behavior working with ConfigurationService class.
When I try to delete a configuration I get always a valid response also
when the configuration key doesn't exist (while I was expecting a
NotFound error).
Reading the code I found below difference from (1) ConfigurationLogic
and, for instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String
schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence, the
first one hasn't.
It is the right behavior?
Massi
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 085973
http://www.tirasa.net
"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)
[jira] [Commented] (SYNCOPE-707) ConfigurationLogic doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954945#comment-14954945
]
ASF subversion and git services commented on SYNCOPE-707:
-
Commit fcd85f6c4f9225919c1a55e4535cf0c151aab8e9 in syncope's branch
refs/heads/master from massi
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=fcd85f6 ]
Fixed SYNCOPE-707
> ConfigurationLogic doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SYNCOPE-707) ConfigurationLogic doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Perrone updated SYNCOPE-707:
-
Summary: ConfigurationLogic doesn't check the existence of key during
deletion. (was: ConfigurationLogin doesn't check the existence of key during
deletion.)
> ConfigurationLogic doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: ConfigurationLogic behavior
On 13/10/2015 14:52, Massimiliano Perrone wrote:
Il 13/10/2015 13:03, Francesco Chicchiriccò ha scritto:
On 13/10/2015 12:50, Massimiliano Perrone wrote:
Hi all,
I found this "strange" behavior working with ConfigurationService
class.
When I try to delete a configuration I get always a valid response
also when the configuration key doesn't exist (while I was expecting
a NotFound error).
Reading the code I found below difference from (1)
ConfigurationLogic and, for instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String
schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence,
the first one hasn't.
It is the right behavior?
Nice catch: please open an issue - and possibly provide a fix as well
if you can; essentially, the method above should become similar to
[1] or [2].
Hi Francesco,
following your suggestion I added the check before the delete
operation, it seems to work but...
But developing the test for it I found that the exception isn't the
expected one. As you can read below to catch the exception I added the
generic Exception class (3) so, printed the class name, I found that
it is a javax.xml.ws.WebServiceException exception (4).
Furthermore during the CLI development I had to always catch the
WebServiceException exception but, until now, I thought it was the
right exception to catch, but now I have some doubts.
(3)
try {
configurationService.delete("nonExistent");
fail("NOT POSSIBLE");
} catch (SyncopeClientException e) {
assertEquals(Response.Status.NOT_FOUND,
e.getType().getResponseStatus());
} catch (Exception e) {
e.printStackTrace();
fail(e.getMessage() + " C " + e.getClass());
}
(4)
java.lang.AssertionError: Remote exception with status code: NOT_FOUND
C class javax.xml.ws.WebServiceException
When throwing NotFoundException form ConfigurationLogic, such exception
is converted into an HTTP message by RestServiceExceptionMapper [3];
moreover, if using SyncopeClient (as you're doing), the
RestClientExceptionMapper [4] attempts to convert the HTTP message back
into a Java exception.
The exception you should received from the DELETE invocation (once
fixed) is exactly the same that you receive when trying to GET an
non-existing configuration attribute, e.g.
curl -X GET --header "Accept: application/json" --header "Authorization:
Basic YWRtaW46cGFzc3dvcmQ="
"http://localhost:9080/syncope/rest/configurations/non-existing;
returns
< HTTP/1.1 404 Not Found
< Date: Tue, 13 Oct 2015 13:06:53 GMT
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< X-Application-Error-Code: NotFound
< X-Application-Error-Info: NotFound:NotFoundException: Configuration
schema caz
< X-Syncope-Domain: Master
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
<
* Connection #1 to host syncopecore2-tirasa.rhcloud.com left intact
{"status":404,"type":"NotFound","elements":["NotFoundException:
Configuration schema caz"]}
which looks fine to me.
Using SyncopeClient:
try {
new SyncopeClientFactoryBean().
setAddress(ADDRESS).
create(ADMIN_UNAME, ADMIN_PWD).
getService(ConfigurationService.class).
get("non-existing");
fail();
} catch (SyncopeClientException e) {
assertEquals(ClientExceptionType.NotFound, e.getType());
}
I don't understand why your code is not working in a similar fashion, then.
Incidentally, I've noticed that the test
org.apache.syncope.fit.core.reference.ConfigurationITCase.delete()
needs to be adjusted as part of SYNCOPE-707.
Regards.
[1]
https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RoleLogic.java#L88-L100
[2]
https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RealmLogic.java#L85-L96
[3]
https://github.com/apache/syncope/blob/master/core/rest-cxf/src/main/java/org/apache/syncope/core/rest/cxf/RestServiceExceptionMapper.java#L214-L216
[4]
[jira] [Resolved] (SYNCOPE-707) ConfigurationLogic doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimiliano Perrone resolved SYNCOPE-707.
--
Resolution: Fixed
> ConfigurationLogic doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SYNCOPE-707) ConfigurationLogin doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954799#comment-14954799
]
Francesco Chicchiriccò commented on SYNCOPE-707:
This issue also affects 1_2_X:
https://github.com/apache/syncope/blob/1_2_X/core/src/main/java/org/apache/syncope/core/rest/controller/ConfigurationController.java#L71-L73
> ConfigurationLogin doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: ConfigurationLogic behavior
Il 13/10/2015 13:03, Francesco Chicchiriccò ha scritto:
On 13/10/2015 12:50, Massimiliano Perrone wrote:
Hi all,
I found this "strange" behavior working with ConfigurationService class.
When I try to delete a configuration I get always a valid response
also when the configuration key doesn't exist (while I was expecting
a NotFound error).
Reading the code I found below difference from (1) ConfigurationLogic
and, for instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String
schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence,
the first one hasn't.
It is the right behavior?
Nice catch: please open an issue - and possibly provide a fix as well
if you can; essentially, the method above should become similar to
[1] or [2].
Hi Francesco,
following your suggestion I added the check before the delete operation,
it seems to work but...
But developing the test for it I found that the exception isn't the
expected one. As you can read below to catch the exception I added the
generic Exception class (3) so, printed the class name, I found that it
is a javax.xml.ws.WebServiceException exception (4).
Furthermore during the CLI development I had to always catch the
WebServiceException exception but, until now, I thought it was the right
exception to catch, but now I have some doubts.
(3)
try {
configurationService.delete("nonExistent");
fail("NOT POSSIBLE");
} catch (SyncopeClientException e) {
assertEquals(Response.Status.NOT_FOUND,
e.getType().getResponseStatus());
} catch (Exception e) {
e.printStackTrace();
fail(e.getMessage() + " C " + e.getClass());
}
(4)
java.lang.AssertionError: Remote exception with status code: NOT_FOUND C
class javax.xml.ws.WebServiceException
Regards.
[1]
https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RoleLogic.java#L88-L100
[2]
https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RealmLogic.java#L85-L96
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 085973
http://www.tirasa.net
"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)
[jira] [Updated] (SYNCOPE-707) ConfigurationLogin doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-707:
---
Priority: Minor (was: Major)
> ConfigurationLogin doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SYNCOPE-707) ConfigurationLogin doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-707:
---
Fix Version/s: 1.2.6
> ConfigurationLogin doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SYNCOPE-707) ConfigurationLogin doesn't check the existence of key during deletion.
Massimiliano Perrone created SYNCOPE-707:
Summary: ConfigurationLogin doesn't check the existence of key
during deletion.
Key: SYNCOPE-707
URL: https://issues.apache.org/jira/browse/SYNCOPE-707
Project: Syncope
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Massimiliano Perrone
Assignee: Massimiliano Perrone
Fix For: 2.0.0
When I try to delete a configuration I get always a valid response also when
the configuration key doesn't exist (while I was expecting a NotFound error).
Reading the code I found below difference from (1) ConfigurationLogic and, for
instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence, the first
one hasn't.
We have to add the same check on the ConfigurationLogic class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SYNCOPE-707) ConfigurationLogin doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-707:
---
Description:
When I try to delete a configuration I get always a valid response also when
the configuration key doesn't exist (while I was expecting a NotFound error).
Reading the code I found below difference from (1) ConfigurationLogic and, for
instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence, the first
one hasn't.
We have to add the same check on the ConfigurationLogic class.
Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
was:
When I try to delete a configuration I get always a valid response also when
the configuration key doesn't exist (while I was expecting a NotFound error).
Reading the code I found below difference from (1) ConfigurationLogic and, for
instance, (2) SchemaLogic classes:
(1)
@PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
public void delete(final String schema) {
confDAO.delete(schema);
}
(2)
@PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
public void delete(final SchemaType schemaType, final String schemaName) {
if (!doesSchemaExist(schemaType, schemaName)) {
throw new NotFoundException(schemaType + "/" + schemaName);
}
switch (schemaType) {
case VIRTUAL:
virSchemaDAO.delete(schemaName);
break;
case DERIVED:
derSchemaDAO.delete(schemaName);
break;
case PLAIN:
default:
plainSchemaDAO.delete(schemaName);
}
}
As you can read the second class has a control on schema existence, the first
one hasn't.
We have to add the same check on the ConfigurationLogic class.
> ConfigurationLogin doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SYNCOPE-707) ConfigurationLogic doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955018#comment-14955018
]
ASF subversion and git services commented on SYNCOPE-707:
-
Commit 876fde9aa6abe7501a6cfdd53e32be0828ecdf03 in syncope's branch
refs/heads/1_2_X from massi
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=876fde9 ]
removed useless try/catch for delete test, SYNCOPE-707
> ConfigurationLogic doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Fixed: apache/syncope#649 (1_2_X - 876fde9)
Build Update for apache/syncope - Build: #649 Status: Fixed Duration: 17 minutes and 34 seconds Commit: 876fde9 (1_2_X) Author: massi Message: removed useless try/catch for delete test, SYNCOPE-707 View the changeset: https://github.com/apache/syncope/compare/091b0662c8d7...876fde9aa6ab View the full build log and details: https://travis-ci.org/apache/syncope/builds/85130471 -- You can configure recipients for build notifications in your .travis.yml file. See http://docs.travis-ci.com/user/notifications
[jira] [Created] (SYNCOPE-708) Conform the Logger "service stack" to others
Massimiliano Perrone created SYNCOPE-708: Summary: Conform the Logger "service stack" to others Key: SYNCOPE-708 URL: https://issues.apache.org/jira/browse/SYNCOPE-708 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.2.5, 2.0.0 Reporter: Massimiliano Perrone Assignee: Massimiliano Perrone Fix For: 1.2.6, 2.0.0 I notice that LoggerServiceImpl#read method performs some code for LoggerLogic. Create a new method called read also in LoggerLogic to put the actual LoggerServiceImpl#read code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-707) ConfigurationLogic doesn't check the existence of key during deletion.
[
https://issues.apache.org/jira/browse/SYNCOPE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955007#comment-14955007
]
ASF subversion and git services commented on SYNCOPE-707:
-
Commit 6852628030c6492a85fbaeaa81d9001315f5d985 in syncope's branch
refs/heads/master from massi
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=6852628 ]
removed useless try/catch for delete test, SYNCOPE-707
> ConfigurationLogic doesn't check the existence of key during deletion.
> --
>
> Key: SYNCOPE-707
> URL: https://issues.apache.org/jira/browse/SYNCOPE-707
> Project: Syncope
> Issue Type: Bug
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
>Priority: Minor
> Fix For: 1.2.6, 2.0.0
>
>
> When I try to delete a configuration I get always a valid response also when
> the configuration key doesn't exist (while I was expecting a NotFound error).
> Reading the code I found below difference from (1) ConfigurationLogic and,
> for instance, (2) SchemaLogic classes:
> (1)
> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
> public void delete(final String schema) {
> confDAO.delete(schema);
> }
> (2)
> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
> public void delete(final SchemaType schemaType, final String schemaName) {
> if (!doesSchemaExist(schemaType, schemaName)) {
> throw new NotFoundException(schemaType + "/" + schemaName);
> }
> switch (schemaType) {
> case VIRTUAL:
> virSchemaDAO.delete(schemaName);
> break;
> case DERIVED:
> derSchemaDAO.delete(schemaName);
> break;
> case PLAIN:
> default:
> plainSchemaDAO.delete(schemaName);
> }
> }
> As you can read the second class has a control on schema existence, the first
> one hasn't.
> We have to add the same check on the ConfigurationLogic class.
> Relevant mail thread: http://markmail.org/message/3ufidttokvw2km5k
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SYNCOPE-700) Documentation artifacts
[
https://issues.apache.org/jira/browse/SYNCOPE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955156#comment-14955156
]
ASF subversion and git services commented on SYNCOPE-700:
-
Commit 36cc7725fcfcc7b3d1101bf5821690d1539ad127 in syncope's branch
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=36cc772 ]
[SYNCOPE-700] Getting started completed
> Documentation artifacts
> ---
>
> Key: SYNCOPE-700
> URL: https://issues.apache.org/jira/browse/SYNCOPE-700
> Project: Syncope
> Issue Type: Improvement
> Components: documentation
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.0
>
>
> As [discussed|http://markmail.org/message/dpleneuzrfcsmq2r] in mailing list,
> setup the {{asciidoctor-maven-plugin}} in order to generate, alongside with
> the build, the project documentation in HTML and PDF.
> The generated documentation will then be part of release artifacts and always
> up-to-date with current release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SYNCOPE-700) Documentation artifacts
[
https://issues.apache.org/jira/browse/SYNCOPE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955171#comment-14955171
]
ASF subversion and git services commented on SYNCOPE-700:
-
Commit 1708454 from [~ilgrosso]
[ https://svn.apache.org/r1708454 ]
[SYNCOPE-700] Publishing artifacts to project site
> Documentation artifacts
> ---
>
> Key: SYNCOPE-700
> URL: https://issues.apache.org/jira/browse/SYNCOPE-700
> Project: Syncope
> Issue Type: Improvement
> Components: documentation
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.0
>
>
> As [discussed|http://markmail.org/message/dpleneuzrfcsmq2r] in mailing list,
> setup the {{asciidoctor-maven-plugin}} in order to generate, alongside with
> the build, the project documentation in HTML and PDF.
> The generated documentation will then be part of release artifacts and always
> up-to-date with current release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Apache Syncope documentation
Hi all, I have just completed the getting started guide, and published the draft artifacts to http://syncope.apache.org/2.0.0-SNAPSHOT/docs/ Regards. On 30/09/2015 15:41, Francesco Chicchiriccò wrote: Hi all, right before packing my things for Budapest, I've just pushed an update on the Getting Started guide, which is currently half-way: the missing content should be easy to adapt from some wiki pages. Please check the latest status and let me know: http://ilgrosso.github.io/syncope2/getting-started.html http://ilgrosso.github.io/syncope2/getting-started.pdf For those of you that are going to ApacheCon: see you there! Regards. On 29/09/2015 15:19, Francesco Chicchiriccò wrote: On 29/09/2015 08:36, Marco Di Sabatino Di Diodoro wrote: Hi Francesco, Il 28/09/2015 18:22, Francesco Chicchiriccò ha scritto: Hi, I've opened SYNCOPE-700 to track this work. You can find the initial work rendered at [8] (under the "New documentation" title), with the two guides I believe are required, both available as HTML and PDF. As written below, I've added the POM configuration for generating such documentation via AsciiDoctor, in a separate "doc" build profile, and some initial skeleton with commit [9]. Naturally, several things need to be improved (footer content over all) and, mainly, the actual content is to be written. Meanwhile, can you take a look at proposed Table Of Contents and let me have your feedback? It sounds good. I propose adding the following chapters: 3.6 Notifications 3.7 Audits Marco, I have updated the TOC including the two items above and completed (at least for the moment) the work on aspect, both for PDF and HTML. [8] was also updated. ...time to start writing some actual content! Regards. On 28/09/2015 14:06, Francesco Chicchiriccò wrote: On 28/09/2015 13:18, Marco Di Sabatino Di Diodoro wrote: Hi all, this morning I found this thesis [1]. I disagree about some points, but I note with regret that the documentation of Apache Syncope is not complete and exhaustive. There are many features that are currently not explained anywhere. With this mail I would like to invite all of you to work together to make Syncope more attractive and interesting. WDYT? Marco, I completely agree with you. I see the great amount of inexact and / or misunderstood facts reported in [1] (but also in [2]) and I am getting more and more convinced that we absolutely need to produce a comprehensive documentation, to be maintained and aligned with software releases (as OpenJPA does [3], for example) rather than a loosely coupled stack of ageing wiki pages. I am ready to open an issue on JIRA for this, and I also volunteer for setting up the initial structure and tooling. My idea is that an adequate tool for this job needs to: 1. bundled to Maven build and (possibly) Maven site 2. produce at least HTML and PDF output 3. be diffuse enough I've seen that Docbkx [4] and the related Maven plugin [5] are quite stable and fulfils the requirements above . I'd rather go with AsciiDoc [6] and related Maven plugin [7], claiming to do all that and also be fast (and "à la page" nowadays, it seems). WDYT? [1] https://www.theseus.fi/bitstream/handle/10024/92040/Viitanen_Samu.pdf?sequence=1 [2] https://compare.evolveum.com/details-syncope.html [3] http://openjpa.apache.org/builds/2.4.0/apache-openjpa/docs/main.html [4] http://docbkx-tools.sourceforge.net/ [5] http://blog.javaforge.net/post/30820930927/generating-project-documentation-with-maven-docbook-docb [6] http://asciidoctor.org/ [7] http://asciidoctor.org/docs/asciidoctor-maven-plugin/ [8] http://ilgrosso.github.io/syncope2/ [9] http://git-wip-us.apache.org/repos/asf/syncope/commit/5dc51917 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
