Hi Paul,
Our requirement is that each request need to send encoded token in request
which need to be validated. 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.
Thanks,
Ashish
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Monday, August 25, 2008 4:50 PM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Problem with Filter
Ashish Raniwala wrote:
> Hi Paul,
>
> My Filter implementation requires access to Form parameters in POST
request.
>
Could you describe a little more why the filter requires access to form
parameters?
The reason i ask is is because usually form parameters are specific to
the resource that consuming such parameters via a POST request. Filters
operate generically so i am wondering why the form processing cannot be
done by a resource class itself.
Paul.
> Thanks,
> Ashish
>
>
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Monday, August 25, 2008 2:29 PM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Problem with Filter
>
> Hi Ashish,
>
> Ashish Raniwala wrote:
>> I also thought that JERSEY Filter is right choice for it though JERSEY
>> filter currently does not support access to query/form parameters so my
>> experiments did not work out.
>
> Does the filter require access to both query and form parameters or just
> query parameters?
>
>
>> This is almost showstopper issue for us
>> currently as we need to hook up sessionToken to wrap dev cycle. Can you
>> please let me know as soon as you wrap up the filter issue?
>>
>
> Will do.
>
>
>>
>>
>> I will explore authentication header option in the meantime. Do you
>> think filter will work fine with header?
>
> Yes, it could be done with the current API.
>
>
>> Do we have any example in
>> JERSEY distribution which use customize authentication header?
>
> Unfortunately not. The only current example is for HTTP method
> overriding for clients that do not support PUT/DELETE.
>
>
>> I know
>> that header can be set with client API but can it be done with HTML also?
>>
>
> Hmm... it is usually clients that know how to add the header e.g.
> browsers. But if you create your own auth mechanism then they will not
> know what to do. (I have wondered if it is possible to download some js
> that knows how to do the client side of the auth.) So i can see why you
> might want to use this session approach if you are not using a well
> known and implemented HTTP auth mechanism supported by a browser.
>
> BTW if you are deploying on servlet you might be able to save some time
> managing sessions. You can inject a HttpServletRequest on a filter then
> use the session obtained from that.
>
> Paul.
>
>
>>
>>
>> Thanks,
>>
>> Ashish
>>
>>
>>
>> *From:* Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
>> *Sent:* Monday, August 25, 2008 12:14 PM
>> *To:* users_at_jersey.dev.java.net
>> *Subject:* Re: [Jersey] Problem with Filter
>>
>>
>>
>> Hi Ashish,
>>
>>
>>
>> The problem is Servlet is broken. The method:
>>
>>
>>
>> request.getParameter
>>
>>
>>
>> does not differentiate between parameters that are query parameters in
>> the URI and parameters that are form parameters in the body of the
>> request. Further more if a parameter is of the latter, then servlet will
>> consume the body of the request message and anything that layers on top
>> of servet that is required to consume the form parameters in the request
>> body will fail, as you are observing.
>>
>>
>>
>> This is rather tricky to untangle by something sitting on top of servlet
>> that also tries to be independent of the HTTP container layer.
>>
>>
>>
>> IMHO the Jersey filter API would be the right place for this :-) but it
>> requires a little of bit of refactoring so you can get easy access to
>> the query parameters. I should be able to sort this out in a couple of
> days.
>>
>>
>> Note that it might be better to utilize the HTTP authentication header
>> with your own customization. That way the URLs are not modified with
>> "secure" and "sessionToken" information.
>>
>>
>>
>> Paul.
>>
>>
>>
>> On Aug 23, 2008, at 8:29 PM, Ashish Raniwala wrote:
>>
>>
>>
>> Hi Guys,
>>
>>
>>
>> I need to use filter for custom security implementation. Please refer
>> the SecurityFilter below for my filter implementation.
>>
>>
>>
>> I am facing strange issue with @FormParam. Value of variables with
>> @FormParam does not get injected with the filter while it works fine
>> without filter.
>>
>>
>>
>> I also observed that if I do not write any code in doFilterInternal
>> method like below, values gets injected fine.
>>
>>
>>
>> protected void doFilterInternal(HttpServletRequest request,
>> HttpServletResponse response, FilterChain chain) throws
>> ServletException, IOException {
>>
>> chain.doFilter(request, response);
>>
>> }
>>
>>
>>
>> I am not getting any clue of what is wrong here. Please help.
>>
>>
>>
>>
>>
>> public class SecurityFilter extends OncePerRequestFilter {
>>
>>
>>
>> @Override
>>
>> protected void doFilterInternal(HttpServletRequest request,
>> HttpServletResponse response, FilterChain chain) throws
>> ServletException, IOException {
>>
>> String url = request.getServletPath();
>>
>> boolean valid = false;
>>
>> int errorCode = -1;
>>
>> UserSession session = null;
>>
>>
>>
>> if (url.contains("secure")) {
>>
>> valid = true; //Exclude login request from session token
>> requirement
>>
>> }
>>
>> else {
>>
>> String sessionToken = request.getParameter("sessionToken");
>>
>> String ip = request.getRemoteAddr();
>>
>>
>>
>> if (sessionToken != null) {
>>
>> session =
>> getRestSessionManager().getUserSessionBySessionKey(sessionToken);
>>
>> }
>>
>> errorCode = RestSecurityUtil.validate(sessionToken, ip,
>> session);
>>
>>
>>
>> valid = (StatusConstants.COMMAND_OK == errorCode);
>>
>>
>>
>> if(valid &&
getRestSessionManager().isSessionExpired(session))
> {
>> errorCode = StatusConstants.INVALID_SESSION_TOKEN;
>>
>> valid = false;
>>
>> }
>>
>> }
>>
>> chain.doFilter(request, response);
>>
>> }
>>
>> }
>>
>>
>>
>> Thanks,
>>
>> Ashish
>>
>>
>>
>>
>>
>
--
| ? + ? = 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