Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2 Beta
    • Fix Version/s: 1.2 Final
    • Component/s: Spring
    • Labels:
      None
    • Environment:
      ICEmobile

      Description

      QR code generation on JSP should work via REST: the full data for the QR code should be encoded in the URL as with the JSF version, such as this URL which returns the QR code for "ICEmobile":

      http://mobileshowcase.icesoft.org/mobileshowcase/javax.faces.resource/qrcode:ICEmobile.jsf

        Activity

        Hide
        Greg Dick added a comment -

        Spring MVC request mapping annotations don't seem to allow the mapping to include portions of the URL that isn't included in the mapping value. What that means is that a declaration like:

        @RequestMapping(value = "/qrcode")
        public void doImageRequest( HttpServletResponse response,
        HttpServletRequest request,
        @ModelAttribute("QRScanBean") QRScanBean model)

        doesn't map the request /qrcode:xxxyyyzzz

        Spring does have a nice structure for exactly this type of thing, with request parameterization, a mapping such as:

        @RequestMapping(value = "/qrcode:

        {theMessage}

        ")
        public void doImageRequest( HttpServletResponse response,
        @PathVariable String theMessage,
        HttpServletRequest request,
        @ModelAttribute("QRScanBean") QRScanBean model)

        Unfortunately, this structure seems to invoke some Spring code that rationalizes the URL. I found that /qrcode/www.icefaces.org
        is correctly mapped, but the value that is in "theMessage" only winds up being "www.icefaces" and not the full string. Hence, the need to pass the request object into the mapping and retrieve the request URI with the entire QRCode string.

        There is still an issue with being able to generate some strings with characters that break the technique, even with double URL encoding the content. It is possible to break the mapping as well, meaning the GET request fetching the image doesn't get mapped to the controller properly. It works fine for most cases, including www.icefaces.org. In 1.3, we should implement a base64 encoding method to cover all characters submitted to the server.

        We have a Base64 encoding class in the mobi world, but no decoding class other than the one in sun.misc, (which is apparently a private API which may be removed at any time) so in 1.3, we should implement a decoder and pass the argument that way.

        Show
        Greg Dick added a comment - Spring MVC request mapping annotations don't seem to allow the mapping to include portions of the URL that isn't included in the mapping value. What that means is that a declaration like: @RequestMapping(value = "/qrcode") public void doImageRequest( HttpServletResponse response, HttpServletRequest request, @ModelAttribute("QRScanBean") QRScanBean model) doesn't map the request /qrcode:xxxyyyzzz Spring does have a nice structure for exactly this type of thing, with request parameterization, a mapping such as: @RequestMapping(value = "/qrcode: {theMessage} ") public void doImageRequest( HttpServletResponse response, @PathVariable String theMessage, HttpServletRequest request, @ModelAttribute("QRScanBean") QRScanBean model) Unfortunately, this structure seems to invoke some Spring code that rationalizes the URL. I found that /qrcode/www.icefaces.org is correctly mapped, but the value that is in "theMessage" only winds up being "www.icefaces" and not the full string. Hence, the need to pass the request object into the mapping and retrieve the request URI with the entire QRCode string. There is still an issue with being able to generate some strings with characters that break the technique, even with double URL encoding the content. It is possible to break the mapping as well, meaning the GET request fetching the image doesn't get mapped to the controller properly. It works fine for most cases, including www.icefaces.org. In 1.3, we should implement a base64 encoding method to cover all characters submitted to the server. We have a Base64 encoding class in the mobi world, but no decoding class other than the one in sun.misc, (which is apparently a private API which may be removed at any time) so in 1.3, we should implement a decoder and pass the argument that way.

          People

          • Assignee:
            Greg Dick
            Reporter:
            Ted Goddard
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: