Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5035

Special characters (latin, accent ...) are in error from an input (search, contact us ...)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: Trunk, 12.04.04, 12.04.05, 13.07.01
    • Fix Version/s: 14.12.01, 13.07.02, 16.11.01
    • Component/s: ALL COMPONENTS
    • Labels:
      None
    • Environment:

      trunk-r1384251

    • Sprint:
      Bug Crush Event - 21/2/2015

      Description

      When a user tapes a special character on a search field or a contact us field, OFBiz sends back a wrong character.
      Try on : http://demo-trunk.ofbiz.apache.org/ecommerce

      This error doesn't appear on old stable version : 10.04 & 09.04
      http://demo-stable.ofbiz.apache.org/ecommerce
      http://demo-old.ofbiz.apache.org/ecommerce

      Note that this is not an issue in the ecomseo webapp which has specifically fixed this issue.

      1. OFBIZ-5035.patch
        7 kB
        Jacopo Cappellato
      2. OFBIZ-5035.patch
        7 kB
        Jacopo Cappellato
      3. OFBIZ-5035.patch
        7 kB
        Jacopo Cappellato

        Issue Links

          Activity

          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I think you should already create a new Jira...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I think you should already create a new Jira...
          Hide
          iwolf Ingo Wolfmayr added a comment -

          When enabling "multitenant" in gerneral properties ofbiz completely fails with special characters (product name, glaccount names ...). I have tried to track it down - the wrong chars are generated before the above patch is applied. I will continue searching ... If someone has an idea please let me know or provide a fix

          Tested with current trunk ... starting the same environment with "multitenant" = "N" works.

          Show
          iwolf Ingo Wolfmayr added a comment - When enabling "multitenant" in gerneral properties ofbiz completely fails with special characters (product name, glaccount names ...). I have tried to track it down - the wrong chars are generated before the above patch is applied. I will continue searching ... If someone has an idea please let me know or provide a fix Tested with current trunk ... starting the same environment with "multitenant" = "N" works.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Thank you Hans!
          I am in Salt Lake City this week and will arrive in Austin on Sunday: see you there!

          Show
          jacopoc Jacopo Cappellato added a comment - Thank you Hans! I am in Salt Lake City this week and will arrive in Austin on Sunday: see you there!
          Hide
          hansbak Hans Bakker added a comment - - edited

          Good Job Jacopo, Thank you for your continued support of Apache OFBiz.
          Very much appreciated! See you in Austin, i will arrive Saturday.

          Show
          hansbak Hans Bakker added a comment - - edited Good Job Jacopo, Thank you for your continued support of Apache OFBiz. Very much appreciated! See you in Austin, i will arrive Saturday.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          This is now fixed with the following revisions:

          • trunk: 1672430
          • 14.12: 1672457
          • 13.07: 1672465
          Show
          jacopoc Jacopo Cappellato added a comment - This is now fixed with the following revisions: trunk: 1672430 14.12: 1672457 13.07: 1672465
          Hide
          jacopoc Jacopo Cappellato added a comment -

          This patch should fix the issue.

          Show
          jacopoc Jacopo Cappellato added a comment - This patch should fix the issue.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Hmmm... no, there are still some issues. I will investigate and provide a new patch.

          Show
          jacopoc Jacopo Cappellato added a comment - Hmmm... no, there are still some issues. I will investigate and provide a new patch.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Improved patch that should fix the issue.
          This new version fixes the NPE reported by Christian Geiser when visiting, for example:
          http://localhost:8080/ecommerce/tiny-gismo-GZ-1000-p

          Please help by reviewing, applying the patch and testing the system (both ecommerce and backend applications).

          Show
          jacopoc Jacopo Cappellato added a comment - Improved patch that should fix the issue. This new version fixes the NPE reported by Christian Geiser when visiting, for example: http://localhost:8080/ecommerce/tiny-gismo-GZ-1000-p Please help by reviewing, applying the patch and testing the system (both ecommerce and backend applications).
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Note: this error does not appear if you use
          http://demo-trunk-ofbiz.apache.org/ecomseo/submitAnonContact
          instead of
          http://demo-trunk-ofbiz.apache.org/ecommerce/control/submitAnonContact
          same for searches.

          So nothing to change in the ecomseo part

          Show
          jacques.le.roux Jacques Le Roux added a comment - Note: this error does not appear if you use http://demo-trunk-ofbiz.apache.org/ecomseo/submitAnonContact instead of http://demo-trunk-ofbiz.apache.org/ecommerce/control/submitAnonContact same for searches. So nothing to change in the ecomseo part
          Hide
          pfm.smits Pierre Smits added a comment -

          You are right. Don't have the issue in demo-trunk-ofbiz.apache.org.

          Must be a setting on my Mac that needs adjusting. My local dev is up-to-date (commit wise).

          Show
          pfm.smits Pierre Smits added a comment - You are right. Don't have the issue in demo-trunk-ofbiz.apache.org. Must be a setting on my Mac that needs adjusting. My local dev is up-to-date (commit wise).
          Hide
          jacopoc Jacopo Cappellato added a comment -

          I can only recreate the issue reported in this ticket (i.e. using the ecommerce application) and this is fixed when I apply my patch.

          Show
          jacopoc Jacopo Cappellato added a comment - I can only recreate the issue reported in this ticket (i.e. using the ecommerce application) and this is fixed when I apply my patch.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Pierre, are you able to recreate it in the public trunk demo? I am unable to recreate the issue you are reporting.

          Show
          jacopoc Jacopo Cappellato added a comment - Pierre, are you able to recreate it in the public trunk demo? I am unable to recreate the issue you are reporting.
          Hide
          pfm.smits Pierre Smits added a comment -

          The patch didn't work for me:
          In the Person entity I changed the firstName field of a Personrecord from Piërre
          to Piërre

          Updated the record and I got: Piërre

          Show
          pfm.smits Pierre Smits added a comment - The patch didn't work for me: In the Person entity I changed the firstName field of a Personrecord from Piërre to Piërre Updated the record and I got: Piërre
          Hide
          jacopoc Jacopo Cappellato added a comment -

          This patch implements one of Scott's solution and seems to fix the issue reported in the ecommerce component.
          I could't recreate the issue mentioned in other component, but it would be great if you could review and test this fix.

          Show
          jacopoc Jacopo Cappellato added a comment - This patch implements one of Scott's solution and seems to fix the issue reported in the ecommerce component. I could't recreate the issue mentioned in other component, but it would be great if you could review and test this fix.
          Hide
          pfm.smits Pierre Smits added a comment -

          The issue not only appears in ecommerce, but it seems in all apps/components.
          And it doesn't matter if it is from data entered through screen/form or uploaded via *Data.xml files.

          I will change components to all. And raise priority to critical.

          Show
          pfm.smits Pierre Smits added a comment - The issue not only appears in ecommerce, but it seems in all apps/components. And it doesn't matter if it is from data entered through screen/form or uploaded via *Data.xml files. I will change components to all. And raise priority to critical.
          Hide
          lektran Scott Gray added a comment -

          It looks like this problem popped up because of the introduction of the CatalogUrlFilter and ContentUrlFilter.

          The filters access the parameter map before the code in the RequestHandler gets the opportunity to set the request's character encoding to UTF-8, once the parameters are parsed on first access setting the character encoding afterwards has no effect. Because these filters are mapped to all path requests they also affect the normal /control/ path, which wouldn't have had this issue prior to their introduction.

          We need to find somewhere very early in the request handling to set character encoding to UTF-8. We can either add tomcat's SetCharacterEncodingFilter to all of the web.xml files or we can add similar code to the ContextFilter and ensure it is always the first filter to run.

          Show
          lektran Scott Gray added a comment - It looks like this problem popped up because of the introduction of the CatalogUrlFilter and ContentUrlFilter. The filters access the parameter map before the code in the RequestHandler gets the opportunity to set the request's character encoding to UTF-8, once the parameters are parsed on first access setting the character encoding afterwards has no effect. Because these filters are mapped to all path requests they also affect the normal /control/ path, which wouldn't have had this issue prior to their introduction. We need to find somewhere very early in the request handling to set character encoding to UTF-8. We can either add tomcat's SetCharacterEncodingFilter to all of the web.xml files or we can add similar code to the ContextFilter and ensure it is always the first filter to run.

            People

            • Assignee:
              jacopoc Jacopo Cappellato
              Reporter:
              eric13007 Eric de Maulde
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development

                  Agile