10:31 a.m.
TBorba <tborba(a)outsoft.pt> wrote:
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/ 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/2.0.0.GA/userguide/html_single/#Securing_J...)
? 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]->Show 1 (again)->Show1.[Set]->...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 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:
org.codehaus.jackson
jackson-core-asl
1.8.1
provided
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.
IP address: 84.91.197.21
Link to comment:
http://redirect.disqus.com/url?url=http%3A%2F%2Fjboss.org%2Fjdf%2Fexample...
-----
Options: You can moderate through email. Respond in the body with "Delete".
Reply with "Like" to like this comment, or respond with anything else to approve
this comment and post your message as a reply comment.
Or use the moderate panel: http://jdf.disqus.com/admin/moderate/#/pending
Stop receiving notifications when new comments are posted:
http://disqus.com/account/#notifications