Missing request parameter when pretty request being forwarded.

Splash Forums PrettyFaces Users Missing request parameter when pretty request being forwarded.

Tagged: 

This topic contains 12 replies, has 3 voices, and was last updated by  Christian Kaltepoth 6 years, 2 months ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #17988

    erongd
    Participant

    I have a situation where I forward request to an destination URL with additional query string parameter. In the case at the destination page I can no longer retrieve the additional query parameter after introduce the prettyface fraemwork.

    For example:

    I have a URL mapped in prettyfaces as the following:

    <url-mapping id=”product1″ outbound=”false”>

    <pattern>/product1</pattern>

    <view-id>/check_login.jsp?a=b&requestedPage=%2fproduct.jsp%3fid=1</view-id>

    </url-mapping>

    In my check_login.jsp I verify if the user already logged in or not. If not we redirect user to a login page, if user already authenticated we forward the request to the destination specified in the “requestedPage” parameter. However in the case the destination URL would be “/product.jsp?id=1”. The problem is after the forward, in product.jsp I can no longer retrieve the parameter “id” from the request, it returns null.

    I am using WebLogic 9 and PrettyFaces 3.2.0. After some digger I realize the problem is in “PrettyFacesWrappedRequest” class in the “getParameterMap” method it only contruct the “allParameters” map once within a request which means the added parameter in the forward will not be in the “allParameters” map. Therefore it is not retrievable from request after forward.

    public Map<String, String[]> getParameterMap()

    {

    if (allParameters == null)

    {

    allParameters = new TreeMap<String, String[]>();

    allParameters.putAll(super.getParameterMap());

    allParameters.putAll(modifiableParameters);

    }

    return Collections.unmodifiableMap(allParameters);

    }

    I would like to know if this is by design or it is something that can be patched? I love the wonderful framework, but I am not in a position to change all the code to use setAttribute when forward.

    Thanks.

    #21138

    erongd
    Participant

    After some more debugging and digging, it looks like the parameter map in the request do change after request forward. As the J2EE runtime seems to merge the additional query string parameters in the forward URL into the parameter map of the http request being forwarded. Therefore I am not sure if the logic in the PrettyFacesWrapperRequest holds true that after the first time accessing the parameter map that it will not change therefore safe to cache them.

    In case of request forward it seems that depend on where you call the super.getParameterMap, you might get a different return from it when you call it before the forward and after the forward.

    I would love to get some insight in how to best handle or fix this problem. I won’t mind patch the code and submit to the framework.

    Thanks.

    Eric

    #21139

    Actually yes, I think this is a bug. It should not be calling super.getParameterMap(), it should be calling wrapped.getParameterMap() – I believe the request is mapped multiple times correctly, but that this is the actual problem.

    I’ll take a look :)

    #21140

    Nope, I was wrong, this looks right. But you should definitely not be having this problem. Firstly, you are using a somewhat older version of PrettyFaces, we are up to 3.3.0 now. Could you try upgrading?

    Second, how have you configured your web.xml / servlet forward? Third, if it comes to it, is there any chance you could make a little test app that reproduces this problem so we can take a closer look?

    Thanks,

    Lincoln

    #21141

    erongd
    Participant

    Actually the prettyfaces only map the first jsp. The first jsp will forward the request to the second jsp directly on the server side, in the case it adds a query string parameter to the second jsp.

    So the flow is this:

    /test -> prettyfaces -> /test.jsp -> forwardto -> /test1.jsp?test=1

    In this case, if I don’t call the getParameterMap on the request before hitting test1.jsp. Then everything works fine, I can retrieve the parameter “test” in “test1.jsp”. However if I ever call the getParameterMap on “test.jsp”, then I no longer can retrieve the parameter “test” in “test1.jsp”. This seems due to the fact that PrettyFacesWrapperRequst only calls super.getParameterMap() once when getParameterMap() method being called very first time. Afterwards, even though the super.getParameterMap() does return the parameter “test” when called in “test1.jsp”, the getParameterMap() method from PrettyFacesWrapperRequest does not as it no longer calling the super.getParameterMap() thus not getting the updated parameter map.

    Seems in most J2EE runtime like jetty, tomcat, they seems to handle forward request specifically by remap the query string just in case someone passing parameter to the forward url.

    I will produce a simple test web app that produces the problem.

    #21142

    erongd
    Participant

    Here is the testing app that reproduce the issue. https://github.com/erongd/test-project

    Run the application use “mvn jetty:run”.

    Without PrettyFaces.

    Access the url “http://localhost:8080/test.jsp?testa=b&#8221;. In the returned page you would see 2 parameter listed “testa” and “testb”. The “testb” is in add to the forward url “/test1.jsp?testb=value”.

    With PrettyFaces.

    Access the url “http://localhost:8080/test?testa=b&#8221;. In the returned page you would be able to see 2 parameter in the “query string” but only “testa” in the parameter list.

    Please let me know if you have any questions.

    Thanks.

    Eric

    #21143

    Ok, I do see the behavior you are seeing, and I agree with your assessment. Thank you for finding this issue! I’ve updated the code and the fix should be deployed in the next 15 minutes. If you could try out the snapshot when it builds, I would appreciate it!

    https://github.com/ocpsoft/prettyfaces/wiki/Snapshots

    #21144

    erongd
    Participant

    Sure I will give it a try.

    #21145

    This was a fantastic find, by the way. This is why I love open-source! Thank you!

    #21146
    #21147

    erongd
    Participant

    I totally agree, without the opensource nature of this framework I won’t be able to catch this issue at all. Thanks for providing such a wonderful framework as open source.

    #21148

    erongd
    Participant

    I tried with the latest snapshot (3.3.1-20110718.224049-7), I can verify the issue is fixed. Everything works as expected. May I ask when would 3.3.1 be released? My company would not allow snapshot lib into production, therefore I have to wait for the 3.3.1 release. In mean time I can use redirect in my specific user case to get around this issue.

    #21149

    We currently have no concrete plans for a 3.3.1 release. At least no plans I know of! :)

    Would it be an option for you to create an in-house release from the current snapshots? Is this allowed at your company? That’s what I’m doing if we have to release software that depends on snapshots.

    Essentially something like this should work:

    $ git clone git@github.com:ocpsoft/prettyfaces.git
    $ cd prettyfaces
    $ mvn -DnewVersion=3.3.1pre1 versions:set versions:commit
    $ mvn -DperformRelease=true -DaltDeploymentRepository=myrepository::default::http://repository.example.com/repository deploy

    You could also simply patch the 3.3.0 release with Lincoln’s fix:

    $ git clone git@github.com:ocpsoft/prettyfaces.git
    $ cd prettyfaces
    $ git checkout -b mybranch 3.3.0
    $ git cherry-pick 24adde374a3e90309766
    $ mvn -DnewVersion=3.3.0fix1 versions:set versions:commit
    $ mvn -DperformRelease=true -DaltDeploymentRepository=myrepository::default::http://repository.example.com/repository deploy

    Christian

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.

Comments are closed.