[jira] [Created] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
Jesse van Bekkum created SYNCOPE-417: Summary: Users are made active when updating in NoOpWorkflowAdapter Key: SYNCOPE-417 URL: https://issues.apache.org/jira/browse/SYNCOPE-417 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.2 Reporter: Jesse van Bekkum Priority: Minor When using the NoOpWorkflow adapter a user is always set to active when an update is done, even if the user is suspended. This is undesirable, I think a user should stay in the state it is. This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): return new WorkflowResult>( new AbstractMap.SimpleEntry(updated.getId(), true), propByRes, "update"); into this: return new WorkflowResult>( new AbstractMap.SimpleEntry(updated.getId(), !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772847#comment-13772847 ] Francesco Chicchiriccò commented on SYNCOPE-417: Hi Jesse, this looks definitely correct: would you mind to provide a proper patch (some [guidelines|https://commons.apache.org/patches.html] are available, if needed). > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-417: --- Fix Version/s: 1.2.0 1.1.4 > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.2 >Reporter: Jesse van Bekkum >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-417: --- Affects Version/s: (was: 1.1.2) 1.1.3 > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse van Bekkum updated SYNCOPE-417: - Attachment: NoOpUserWorkflowAdapter.java.patch Patch for this issue > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > Attachments: NoOpUserWorkflowAdapter.java.patch > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-417: -- Assignee: Francesco Chicchiriccò > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > Attachments: NoOpUserWorkflowAdapter.java.patch > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-417. Resolution: Fixed 1_1_X: http://svn.apache.org/r1524937 trunk: http://svn.apache.org/r1524938 Patch applied (better from source root directory, next time), thanks! > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > Attachments: NoOpUserWorkflowAdapter.java.patch > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772881#comment-13772881 ] Hudson commented on SYNCOPE-417: SUCCESS: Integrated in Syncope-1_1_X #110 (See [https://builds.apache.org/job/Syncope-1_1_X/110/]) [SYNCOPE-417] Applying provided patch (ilgrosso: rev 1524937) * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/workflow/user/NoOpUserWorkflowAdapter.java > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > Attachments: NoOpUserWorkflowAdapter.java.patch > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-417) Users are made active when updating in NoOpWorkflowAdapter
[ https://issues.apache.org/jira/browse/SYNCOPE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772888#comment-13772888 ] Hudson commented on SYNCOPE-417: SUCCESS: Integrated in Syncope-trunk #451 (See [https://builds.apache.org/job/Syncope-trunk/451/]) [SYNCOPE-417] Merge from 1_1_X (ilgrosso: rev 1524938) * /syncope/trunk * /syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/NoOpUserWorkflowAdapter.java > Users are made active when updating in NoOpWorkflowAdapter > -- > > Key: SYNCOPE-417 > URL: https://issues.apache.org/jira/browse/SYNCOPE-417 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Jesse van Bekkum >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 1.1.4, 1.2.0 > > Attachments: NoOpUserWorkflowAdapter.java.patch > > > When using the NoOpWorkflow adapter a user is always set to active when an > update is done, even if the user is suspended. This is undesirable, I think a > user should stay in the state it is. > This can be fixed by changing this line (117/118 of NoOpWorkflowAdapter.java): > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > true), propByRes, "update"); > into this: > return new WorkflowResult>( > new AbstractMap.SimpleEntry(updated.getId(), > !user.isSuspended()), propByRes, "update"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-418) Special chars break REST URLs
Francesco Chicchiriccò created SYNCOPE-418: -- Summary: Special chars break REST URLs Key: SYNCOPE-418 URL: https://issues.apache.org/jira/browse/SYNCOPE-418 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.3 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.4, 1.2.0 Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as [reported in mailing list|http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-418: --- Description: Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as reported in mailing list [1], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. [1] http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html was: Some entities have String keys that are currently accepted without any specific bound (schema, resources, config parameters). When, for example, a value like as an URL is provided, nothing special happens during creation (because such value is embedded into a transfer object); however, any subsequent read or delete, which would require passing the entity key as part of the REST URL, will fail either with Spring MVC and CXF. For example, as [reported in mailing list|http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html], a user schema with name 'http://schemas.examples.org/security/authorization/organizationUnit' can be created but will then be impossible to read or even delete since the REST URL would be something like as http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit After some search, it seems that it is neither Spring MVC nor CXF problem, but instead the JEE container (like as Tomcat, for example) that needs some special configuration for handling such URLs (see CXF-4207 for more details). The most logical and straightforward solution seems to be just setting some limits for the characters admitted; at a first glance, alphanumeric plus some special characters (space, _, -, @, .) should be fine. > Special chars break REST URLs > - > > Key: SYNCOPE-418 > URL: https://issues.apache.org/jira/browse/SYNCOPE-418 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 1.1.4, 1.2.0 > > > Some entities have String keys that are currently accepted without any > specific bound (schema, resources, config parameters). > When, for example, a value like as an URL is provided, nothing special > happens during creation (because such value is embedded into a transfer > object); however, any subsequent read or delete, which would require passing > the entity key as part of the REST URL, will fail either with Spring MVC and > CXF. > For example, as reported in mailing list [1], a user schema with name > 'http://schemas.examples.org/security/authorization/organizationUnit' can be > created but will then be impossible to read or even delete since the REST URL > would be something like as > http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit > After some search, it seems that it is neither Spring MVC nor CXF problem, > but instead the JEE container (like as Tomcat, for example) that needs some > special configuration for handling such URLs (see CXF-4207 for more details). > The most logical and straightforward solution seems to be just setting some > limits for the characters admitted; at a first glance, alphanumeric plus some > special characters (space, _, -, @, .) should be fine. > [1] > http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Errored] apache/syncope#245 (1_1_X - c6c700b)
Build Update for apache/syncope - Build: #245 Status: Errored Duration: 9 minutes and 53 seconds Commit: c6c700b (1_1_X) Author: Francesco Chicchiriccò Message: [SYNCOPE-418] Enforcing name constraints for any schema, resource and configuration git-svn-id: https://svn.apache.org/repos/asf/syncope/branches/1_1_X@1524988 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/syncope/compare/1c16ba8d9d7f...c6c700b8a60d View the full build log and details: https://travis-ci.org/apache/syncope/builds/11592683 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration
[Passed] apache/syncope#246 (1_1_X - 3142aea)
Build Update for apache/syncope - Build: #246 Status: Passed Duration: 17 minutes and 39 seconds Commit: 3142aea (1_1_X) Author: Francesco Chicchiriccò Message: [SYNCOPE-418] Now working with JDK 6 as well... git-svn-id: https://svn.apache.org/repos/asf/syncope/branches/1_1_X@1524998 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/syncope/compare/c6c700b8a60d...3142aeac351c View the full build log and details: https://travis-ci.org/apache/syncope/builds/11593290 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration
[jira] [Resolved] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-418. Resolution: Fixed 1_1_X: http://svn.apache.org/r1524988 http://svn.apache.org/r1524998 trunk: http://svn.apache.org/r1525004 > Special chars break REST URLs > - > > Key: SYNCOPE-418 > URL: https://issues.apache.org/jira/browse/SYNCOPE-418 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.3 >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 1.1.4, 1.2.0 > > > Some entities have String keys that are currently accepted without any > specific bound (schema, resources, config parameters). > When, for example, a value like as an URL is provided, nothing special > happens during creation (because such value is embedded into a transfer > object); however, any subsequent read or delete, which would require passing > the entity key as part of the REST URL, will fail either with Spring MVC and > CXF. > For example, as reported in mailing list [1], a user schema with name > 'http://schemas.examples.org/security/authorization/organizationUnit' can be > created but will then be impossible to read or even delete since the REST URL > would be something like as > http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit > After some search, it seems that it is neither Spring MVC nor CXF problem, > but instead the JEE container (like as Tomcat, for example) that needs some > special configuration for handling such URLs (see CXF-4207 for more details). > The most logical and straightforward solution seems to be just setting some > limits for the characters admitted; at a first glance, alphanumeric plus some > special characters (space, _, -, @, .) should be fine. > [1] > http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Time for 1.1.4?
Hi all, FYI, I'll wait few days for cutting 1.1.4 since SYNCOPE-418, just resolved, has introduced some non-trivial changes. Regards. On 19/09/2013 15:44, Francesco Chicchiriccò wrote: Hi all, I have just noticed that 1.1.4 got 11 issues resolved [1] including some relevant fixes; moreover, there are no left open and 1.1.3 was issued a couple of months ago. Hence I was wondering: isn't this time for a new release? Any thought / objection? Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12324763#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Assigned] (SYNCOPE-131) Assign membership and role schemas to either all memberships / roles or only some memberships / roles
[ https://issues.apache.org/jira/browse/SYNCOPE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-131: -- Assignee: Francesco Chicchiriccò > Assign membership and role schemas to either all memberships / roles or only > some memberships / roles > - > > Key: SYNCOPE-131 > URL: https://issues.apache.org/jira/browse/SYNCOPE-131 > Project: Syncope > Issue Type: Improvement >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 1.2.0 > > > Currently, membership and role schemas are defined for all memberships / > roles. > This means that when defining a mandatory role schema, all roles must provide > a value for the corresponding attribute. Same applies for memberships. > This mechanism should be extended so that you can choose which schemas are > associated to each role / membership, in order to give more flexibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773022#comment-13773022 ] Hudson commented on SYNCOPE-418: SUCCESS: Integrated in Syncope-1_1_X #111 (See [https://builds.apache.org/job/Syncope-1_1_X/111/]) [SYNCOPE-418] Now working with JDK 6 as well... (ilgrosso: rev 1524998) * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AbstractValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/EntitlementValidator.java [SYNCOPE-418] Enforcing name constraints for any schema, resource and configuration (ilgrosso: rev 1524988) * /syncope/branches/1_1_X/common/src/main/java/org/apache/syncope/common/types/EntityViolationType.java * /syncope/branches/1_1_X/common/src/main/java/org/apache/syncope/common/types/SyncopeClientExceptionType.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractDerSchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractSchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractVirSchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncopeConf.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UDerSchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/user/USchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UVirSchema.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/attrvalue/EmailAddressValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AbstractValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValueValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ConnInstanceValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/EntitlementValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ExternalResourceValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/InvalidEntityException.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/NotificationValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PolicyValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PropagationTaskValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ReportValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchedTaskValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameCheck.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncTaskValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfCheck.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeRoleValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeUserValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaCheck.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaValidator.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/rest/controller/DerivedSchemaController.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/rest/data/DerivedSchemaDataBinder.java * /syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/rest/utils/RestServiceExceptionMapper.java * /syncope/branches/1_1_X/core/src/main/webapp/synco
[jira] [Commented] (SYNCOPE-418) Special chars break REST URLs
[
https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773025#comment-13773025
]
Sergey Beryozkin commented on SYNCOPE-418:
--
Hi
JAX-RS UriInfo & UriBuilder may also help. It is as simple as
uriBuilder.path("{var}").build(getValue(), true);
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
> Special chars break REST URLs
> -
>
> Key: SYNCOPE-418
> URL: https://issues.apache.org/jira/browse/SYNCOPE-418
> Project: Syncope
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.3
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.4, 1.2.0
>
>
> Some entities have String keys that are currently accepted without any
> specific bound (schema, resources, config parameters).
> When, for example, a value like as an URL is provided, nothing special
> happens during creation (because such value is embedded into a transfer
> object); however, any subsequent read or delete, which would require passing
> the entity key as part of the REST URL, will fail either with Spring MVC and
> CXF.
> For example, as reported in mailing list [1], a user schema with name
> 'http://schemas.examples.org/security/authorization/organizationUnit' can be
> created but will then be impossible to read or even delete since the REST URL
> would be something like as
> http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit
> After some search, it seems that it is neither Spring MVC nor CXF problem,
> but instead the JEE container (like as Tomcat, for example) that needs some
> special configuration for handling such URLs (see CXF-4207 for more details).
> The most logical and straightforward solution seems to be just setting some
> limits for the characters admitted; at a first glance, alphanumeric plus some
> special characters (space, _, -, @, .) should be fine.
> [1]
> http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SYNCOPE-418) Special chars break REST URLs
[
https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773025#comment-13773025
]
Sergey Beryozkin edited comment on SYNCOPE-418 at 9/20/13 2:11 PM:
---
Hi
JAX-RS UriInfo & UriBuilder may also help. It is as simple as
{code:java}
uriBuilder.path("{var}").build(getValue(), true);
{code}
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
was (Author: sergey_beryozkin):
Hi
JAX-RS UriInfo & UriBuilder may also help. It is as simple as
uriBuilder.path("{var}").build(getValue(), true);
Cheers, Sergey
[1]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html
[2]
https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/UriBuilder.html#build(java.lang.Object[],%20boolean)
> Special chars break REST URLs
> -
>
> Key: SYNCOPE-418
> URL: https://issues.apache.org/jira/browse/SYNCOPE-418
> Project: Syncope
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.3
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.4, 1.2.0
>
>
> Some entities have String keys that are currently accepted without any
> specific bound (schema, resources, config parameters).
> When, for example, a value like as an URL is provided, nothing special
> happens during creation (because such value is embedded into a transfer
> object); however, any subsequent read or delete, which would require passing
> the entity key as part of the REST URL, will fail either with Spring MVC and
> CXF.
> For example, as reported in mailing list [1], a user schema with name
> 'http://schemas.examples.org/security/authorization/organizationUnit' can be
> created but will then be impossible to read or even delete since the REST URL
> would be something like as
> http://localhost:9080syncope/rest/schema/USER/read/http://schemas.examples.org/security/authorization/organizationUnit
> After some search, it seems that it is neither Spring MVC nor CXF problem,
> but instead the JEE container (like as Tomcat, for example) that needs some
> special configuration for handling such URLs (see CXF-4207 for more details).
> The most logical and straightforward solution seems to be just setting some
> limits for the characters admitted; at a first glance, alphanumeric plus some
> special characters (space, _, -, @, .) should be fine.
> [1]
> http://syncope-user.1051894.n5.nabble.com/Remove-attribute-in-user-schema-td5707312.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-418) Special chars break REST URLs
[ https://issues.apache.org/jira/browse/SYNCOPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773046#comment-13773046 ] Hudson commented on SYNCOPE-418: SUCCESS: Integrated in Syncope-trunk #452 (See [https://builds.apache.org/job/Syncope-trunk/452/]) [SYNCOPE-418] Merge from 1_1_X (ilgrosso: rev 1525004) * /syncope/trunk * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/EntityViolationType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncopeClientExceptionType.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractDerSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractVirSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncopeConf.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UDerSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/USchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/user/UVirSchema.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/attrvalue/EmailAddressValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AbstractValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/AttrValueValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ConnInstanceValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ExternalResourceValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/NotificationValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PolicyValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/PropagationTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ReportValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchedTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaNameValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SchemaValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeConfValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeRoleValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncopeUserValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaCheck.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/USchemaValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/SchemaDataBinder.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/AttrTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ConfTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/DerSchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ResourceTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/SchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/VirSchemaTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConfigurationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/DerivedSchemaTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ResourceTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/SchemaTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/VirtualSchemaTestITCase.java > Special chars break REST URLs > - > > Key: SYNCOPE-418 > URL: https://iss
