Congratulations to the authors and contributors on the very detailed tutorial. Ticket-monster is really getting me started on JavaEE and JBoss.
I have a question and a proposed improvement about the Rest services mentioned here. I'll start with the question.
Question - Rest security:
I have successfully converted the persistence framework for my project necessities using PostgreSQL with jdbc drivers, and noticed a security issue. Ticket-monster appears to be the kind of application that does not require its data to be private in most scenarios, and the JSON result of the services is accessible to anything that can reach the ticket-monster/rest/<servicename> path. So anyone can see the contents of my database.
How would one restrict the services for scenarios where privacy is key and authentication required? I have noticed JBoss uses RestEasy so I'm referencing that too. I will give 3 examples that are not only the most generic but that I'm also needing for the system I am developing:
Scenario 1: an application that uses account authentication and likes to keep data private at the user level. Would one be able to adapt it with role-based authentication as described in the RESTEasy user guide (chapters 36/37 http://docs.jboss.org/resteasy... ? Also, would one be able to define role-based authentication to the parameter "level" of a service. For instance, as described in "Retrieving Events" you can specify categories. Could user 'JDoe' be able to access category X of events, and user 'JSmith' access category Y?
Scenario 2: always-required authentication for any and all services, for trusted applications only, without role restriction. A shared key or certificate could be used to prove that an application is part of the system, and thus is a trusted component that can access results.
Scenario 3: A mix of scenario 1 and 2. There are somewhat publicly available services (i.e. public to trusted applications only), but still keep private, user-specific services with role authentication (so even in the universe of all trusted applications, only certain users can access specific services or a specific parameter to a service call).
Proposed improvement - Avoiding Bi-directional mapping redundancies in JSON serialization:
I don't know if this is specific to my environment, but the most recent version of the ticket-monster GIT repository keeps throwing me on an infinite serialization loop, that eventually causes an exception when calling services that retrieve entities with Bi-directional relations (long sentence, sorry).
To reproduce this bug, one just needs to try and book a ticket for an existing Show. The ShowService will attempt to get the children entity Performances, which in turn is has a list of shows in its own definition. So the serialization class (a dependency of hibernate if I'm not mistaken: org.codehaus.jackson) will try and serialize the following:
1 - adding a @JsonIgnore annotation on the Show member in Performance entity (Performance.java). Serializer class will ignore shows (might be bad when reusing).
2 - (appears more correct) adding @JsonManagedReference in the parent (Show entity, Show.java), before it's Set<performance> member, and then @JsonBackReference on the Show member of Performance.java. Since this is not available in the default version of the Jackson library for the project, I updated pom.xml to include the dependency:
With both of them, the business logic appears to be correct for the booking page, but I didn't analyze it further so it might produce BL inconsistencies on whichever other page uses it. I would appreciate your input on this solution since I am using the same fix in my PostgreSQL imported model and services.</performance></performance></performance></servicename>
Settings
TBorba
Congratulations to the authors and contributors on the very detailed tutorial. Ticket-monster is really getting me started on JavaEE and JBoss.
I have a question and a proposed improvement about the Rest services mentioned here. I'll start with the question.
Question - Rest security:
I have successfully converted the persistence framework for my project necessities using PostgreSQL with jdbc drivers, and noticed a security issue. Ticket-monster appears to be the kind of application that does not require its data to be private in most scenarios, and the JSON result of the services is accessible to anything that can reach the ticket-monster/rest/<servicename> path. So anyone can see the contents of my database.
How would one restrict the services for scenarios where privacy is key and authentication required? I have noticed JBoss uses RestEasy so I'm referencing that too. I will give 3 examples that are not only the most generic but that I'm also needing for the system I am developing:
Scenario 1: an application that uses account authentication and likes to keep data private at the user level. Would one be able to adapt it with role-based authentication as described in the RESTEasy user guide (chapters 36/37 http://docs.jboss.org/resteasy... ? Also, would one be able to define role-based authentication to the parameter "level" of a service. For instance, as described in "Retrieving Events" you can specify categories. Could user 'JDoe' be able to access category X of events, and user 'JSmith' access category Y?
Scenario 2: always-required authentication for any and all services, for trusted applications only, without role restriction. A shared key or certificate could be used to prove that an application is part of the system, and thus is a trusted component that can access results.
Scenario 3: A mix of scenario 1 and 2. There are somewhat publicly available services (i.e. public to trusted applications only), but still keep private, user-specific services with role authentication (so even in the universe of all trusted applications, only certain users can access specific services or a specific parameter to a service call).
Proposed improvement - Avoiding Bi-directional mapping redundancies in JSON serialization:
I don't know if this is specific to my environment, but the most recent version of the ticket-monster GIT repository keeps throwing me on an infinite serialization loop, that eventually causes an exception when calling services that retrieve entities with Bi-directional relations (long sentence, sorry).
To reproduce this bug, one just needs to try and book a ticket for an existing Show. The ShowService will attempt to get the children entity Performances, which in turn is has a list of shows in its own definition. So the serialization class (a dependency of hibernate if I'm not mistaken: org.codehaus.jackson) will try and serialize the following:
Show1->Show1.[Set<performance>]->Show 1 (again)->Show1.[Set<performance>]->...infinite loop
I solved this issue in 2 different ways:
1 - adding a @JsonIgnore annotation on the Show member in Performance entity (Performance.java). Serializer class will ignore shows (might be bad when reusing).
2 - (appears more correct) adding @JsonManagedReference in the parent (Show entity, Show.java), before it's Set<performance> member, and then @JsonBackReference on the Show member of Performance.java. Since this is not available in the default version of the Jackson library for the project, I updated pom.xml to include the dependency:
<dependency>
<groupid>org.codehaus.jackson</groupid>
<artifactid>jackson-core-asl</artifactid>
<version>1.8.1</version>
<scope>provided</scope>
</dependency>
With both of them, the business logic appears to be correct for the booking page, but I didn't analyze it further so it might produce BL inconsistencies on whichever other page uses it. I would appreciate your input on this solution since I am using the same fix in my PostgreSQL imported model and services.</performance></performance></performance></servicename>
11:31 a.m., Friday May 31
Moderate this comment by email
Email address: tborba@outsoft.pt | IP address: 84.91.197.21
Reply to this email with “Delete”, “Approve”, or “Spam”, or moderate from the Disqus moderation panel.