Hi Paul,
Appreciate you giving priority on this. I will try this out.
Thanks,
Ashish
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Monday, August 25, 2008 8:14 PM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Problem with Filter
Ashish Raniwala wrote:
> We do not have GET requests so far in our System. This system is
enterprise
> application which will require custom integration and client will always
> make POST requests.
>
I have refactored ContainerRequest to have access to query parameters in
the latest 0.10-ea-SNAPSHOT. But it sounds like you need to use form
parameters and i do not want to dictate any design on you. What follows
is a possible solution, written of the top of my head, but hopefully it
will work.
The main problem is the filter does not know how the request body is
processed by other filters (if any) further in the filter chain and
resource methods of resource classes. So it should buffer the contents
before processing.
public ContainerRequest filter(ContainerRequest request) {
if (request.getMethod().equals("POST") && request.getMediaType().
equals(MediaType.APPLICATION_FORM_URLENCODED_TYPE)) {
byte[] buffer = request.getEntity(byte[].class);
ByteArrayInputStream baos = new ByteArrayInputStream(buffer);
request.setEntity(baos);
Form f = request.getEntity(Form.class);
baos.reset();
// Process form parameters
// throw WebApplicationException if an error response
// is required
}
return request;
}
Here is an interesting thought. I reckon it might be possible to
annotate sub-resource locators and resource methods an annotation that
is in turn annotated with a meta annotation that specifies a filter
class. Thus one could have more targeted filters.
Hope this helps,
Paul.
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Monday, August 25, 2008 5:36 PM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Problem with Filter
>
> Ashish Raniwala wrote:
>> Hi Paul,
>>
>> Our requirement is that each request need to send encoded token in
request
>> which need to be validated.
>
> Is that for GET requests as well as POST requests? If so how is the
> encoded token sent in a GET request? is that as a query parameter called
> "sessionToken" ?
>
>
>> This token cannot be stored in HttpSession for
>> various reasons but is stored in database. Something like ACEGI's
> Persistent
>> Token based approach for remember me. We have option to send this token
in
>> request (POST) or in Http Header but Http Headers are difficult with
plain
>> HTMLs so we are currently working with form parameters.
>>
>> Since all requests will have this validation required that's why we
> thought
>> about using Filters.
>>
>
> Where is this security token parameter obtained from?
>
> Sorry for all the questions as i really want to understand if it is
> really the right thing for you to use form parameters for security token
> parameters. It appears you may be implementing a variant of "classic"
> session-based management with specific use-cases for security token
> storage, and you may be able to use a cookie-based approach or a URI
> query parameter approach with GET/POST for the transmission of the
> security token.
>
> Paul.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net