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