Jason Porter <lightguard.jp(a)gmail.com> wrote, in response to TBorba:
What I've typically seen being done is a token that's sent via a custom HTTP
Header. Those are first obtained via a login / auth function. You could also require a
username with that auth token. If you're using CDI you could create a security
interceptor to check those and deny / allow that way.
User's website:
http://lightguard-jp.blogspot.com
IP address: 63.248.81.177
Link to comment:
http://redirect.disqus.com/url?url=http%3A%2F%2Fjboss.org%2Fjdf%2Fexample...
TBorba 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/servicepath. So anyone can see the contents of my database.
How would one restrict the services for scenarios where privacy is key and authentic...
-----
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