On Wed, Jul 18, 2012 at 10:47 AM, bhorvat <horvat.z.bo...@gmail.com> wrote:
> This configuration that Taha suggested seems to do the trick. The error is
> gone. I say seems because without it would work sometimes (not sure why
> though).
> The annotation however dont seem to work. Even if I put them they dont
> restrict the access to the method. Any idea why?
> @RequiresAuthentication
> @GET
> @Path("/{id}")
> public User getUser(@PathParam("id") Long id) {
> return systemManager.getUser(id);
> }
> Above is the example of the method.
Are you using T5.3? If so, your JAX-RS annotations (as mentioned in
http://tynamo.org/tapestry-resteasy+guide) won't work any better - you
have to add your annotations to the service interface.
> I have a question because I am not sure how should all of this work. In
> normal application when the user is authenticated he gets a token and then
> that token is used to check his credentials, am i right? When does he gets
> that token, presumably in a form of a cookie? Is Shiro responsible for that
> or tapestry?
Generally speaking, the container is responsible for maintaining and
validating your session. Shiro also has a feature called "native
sessions" but it doesn't fundamentally change how it works - it just
wraps the http session. Rest, non-rest doesn't matter, it's a normal
web application and you need the basic understanding of how servlet
containers manage users sessions. Read about the JSESSIONID cookie and
watch how it works.
> If I dont use the session, and I send the username/password each time, how
> should I format the url? Will I always have to use POST and not GET?
Read about HTTP BASIC authentication, the credentials are sent in the
header of a http request. The http method doesn't matter.
> If I use GET wont then my url be something like
> address/rest/username/passoword/project/all or something along those lines?
No. If you implemented another authentication technique, perhaps based
on generating one-time access tokens, yes, you could send the token in
the url. That'd be completely custom and could be in addition to BASIC
authentication or sessions.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
