Tapestry
  1. Tapestry
  2. TAPESTRY-1099

Current snapshot of 4.1 has HTTPS DoJo problem, having trouble updating DoJo

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1
    • Fix Version/s: 4.1.1
    • Component/s: JavaScript
    • Labels:
      None
    • Environment:
      Internet Explorer 6

      Description

      The development version of DoJo included with the current packaged 4.1 release contains DoJo bug #550 (http://trac.dojotoolkit.org/ticket/550). IE shows a mixed-content warning loading DoJo from a page accessed via HTTPS.

      DoJo 3.1 has this problem fixed, even though the above issue doesn't indicate it.

      However, when I tried pointing my @Shell component to a DoJo source directory containing the dojo-0.3.1-widget package (and modifying the dojo.js to require packages not packaged in the T4.1 dojo.js), I get no widget prompt with validation errors on form submit. Form submit fails, and the dojo and tapestry JS objects appear to be defined and complete, but I get no feedback.

      When I leave the Shell component to it's default parameters, I get the IE warning, but if I OK the operation, then I see the validation errors prompt.

      If the packaged T4.1 build contains an updated DoJo, that should work with HTTPS, but I'm still trying to figure out what's up with my configuration to use a custom DoJo source and path with @Shell.

        Activity

        Greg Woolsey created issue -
        Hide
        Greg Woolsey added a comment -

        Found it. DoJo 0.3.1 has a different implementation for

        dojo.uri.Uri()

        which tries to ensure that URI components passed in end in forward slashes ("/") except for the last one. However, Tapestry 4.1 is outputting an Asset URL for the dojoPath with the slashes URL encoded. DoJo sees the base path doesn't end in "/", but in "%2F" instead, it's hex equivalent. It then walks back up the URI until it finds an unescaped "/" and just uses that portion.

        The older DEV version of DoJo doesn't do that.

        Since DoJo resides on the class path instead of web root for our project, the templates are not found. This error is not logged propery by Tapestry form validation, by the way. dojo.log.exception() doesn't report anything even when the DoJo log level is set to DEBUG.

        So, next question - fiddle with Tapestry's Asset URI encoding or DoJo's baseURI processing?

        Show
        Greg Woolsey added a comment - Found it. DoJo 0.3.1 has a different implementation for dojo.uri.Uri() which tries to ensure that URI components passed in end in forward slashes ("/") except for the last one. However, Tapestry 4.1 is outputting an Asset URL for the dojoPath with the slashes URL encoded. DoJo sees the base path doesn't end in "/", but in "%2F" instead, it's hex equivalent. It then walks back up the URI until it finds an unescaped "/" and just uses that portion. The older DEV version of DoJo doesn't do that. Since DoJo resides on the class path instead of web root for our project, the templates are not found. This error is not logged propery by Tapestry form validation, by the way. dojo.log.exception() doesn't report anything even when the DoJo log level is set to DEBUG. So, next question - fiddle with Tapestry's Asset URI encoding or DoJo's baseURI processing?
        Hide
        Greg Woolsey added a comment -

        Workaround for the URL problem: turn on friendly URLs for the Asset service:

        http://tapestry.apache.org/tapestry4.1/UsersGuide/friendly-urls.html

        This makes the base path look like a plain URL path with no parameters.

        However, I'm still gettting mixed-content warnings from IE. I'll try a servlet filter to see what's coming through as HTTP instead of HTTPS.

        Show
        Greg Woolsey added a comment - Workaround for the URL problem: turn on friendly URLs for the Asset service: http://tapestry.apache.org/tapestry4.1/UsersGuide/friendly-urls.html This makes the base path look like a plain URL path with no parameters. However, I'm still gettting mixed-content warnings from IE. I'll try a servlet filter to see what's coming through as HTTP instead of HTTPS.
        Hide
        Andreas Andreou added a comment -

        I think Jesse updated dojo a week ago to something-resembling a pre-0.4 version - don't know if that resolves things.
        BTW, aren't you using 4.1.1-SNAPSHOT ? The maven repo is at http://people.apache.org/repo/m2-snapshot-repository

        Show
        Andreas Andreou added a comment - I think Jesse updated dojo a week ago to something-resembling a pre-0.4 version - don't know if that resolves things. BTW, aren't you using 4.1.1-SNAPSHOT ? The maven repo is at http://people.apache.org/repo/m2-snapshot-repository
        Hide
        Greg Woolsey added a comment -

        Yes, I'm using 4.1.1 lastest snapshot (20060827.214823-24). It still includes an old dev build of DoJo, pre-0.3.x.

        At this point I'm fine with requiring friendly URLs for assets to make it work with DoJo 0.3.1. My Tapestry issue is resolved with that configuration change. HTTPS still has problems with IE and background IFRAME objects due to a DoJo bug:

        http://trac.dojotoolkit.org/ticket/548

        The end result (long, long thread) setting the IFRAME src="javascript:false" is the correct solution, and works for me to avoid HTTPS mixed content warnings in IE6.

        Show
        Greg Woolsey added a comment - Yes, I'm using 4.1.1 lastest snapshot (20060827.214823-24). It still includes an old dev build of DoJo, pre-0.3.x. At this point I'm fine with requiring friendly URLs for assets to make it work with DoJo 0.3.1. My Tapestry issue is resolved with that configuration change. HTTPS still has problems with IE and background IFRAME objects due to a DoJo bug: http://trac.dojotoolkit.org/ticket/548 The end result (long, long thread) setting the IFRAME src="javascript:false" is the correct solution, and works for me to avoid HTTPS mixed content warnings in IE6.
        Hide
        Jesse Kuhnert added a comment -

        Yeah sorry about that.

        I didn't release the "early release" of dojo into the snapshots yet because I had an outstanding issue with date validation.

        Tom has definitely fixed the IE security warning issue so you should be all set in a day or two when I do another update - and hopefully this time a new snapshot.

        BTW, to use your own dojo version you need to override the "ajaxDelegate" attribute of Shell...It's just a bean that happens to have a IRender interface on it is all.

        Even though the @Shell allows overriding the default bundled version - it's certainly not guaranteed that the rest of system will work with that version.

        Show
        Jesse Kuhnert added a comment - Yeah sorry about that. I didn't release the "early release" of dojo into the snapshots yet because I had an outstanding issue with date validation. Tom has definitely fixed the IE security warning issue so you should be all set in a day or two when I do another update - and hopefully this time a new snapshot. BTW, to use your own dojo version you need to override the "ajaxDelegate" attribute of Shell...It's just a bean that happens to have a IRender interface on it is all. Even though the @Shell allows overriding the default bundled version - it's certainly not guaranteed that the rest of system will work with that version.
        Jesse Kuhnert made changes -
        Field Original Value New Value
        Assignee Jesse Kuhnert [ jkuhnert ]
        Hide
        Jesse Kuhnert added a comment -

        Oops...Almost forgot to answer the question about asset paths..

        This is a "known issue" within dojo. I have my own version of dojo.uri.Uri that I include with Tapestry that correctly handles the path issues you saw.

        I didn't have enough time to make the changes required for this fix in dojo directly for the 0.4 release (we're on feature freeze now) , but it'll definitely be in 0.5..

        Show
        Jesse Kuhnert added a comment - Oops...Almost forgot to answer the question about asset paths.. This is a "known issue" within dojo. I have my own version of dojo.uri.Uri that I include with Tapestry that correctly handles the path issues you saw. I didn't have enough time to make the changes required for this fix in dojo directly for the 0.4 release (we're on feature freeze now) , but it'll definitely be in 0.5..
        Hide
        Greg Woolsey added a comment -

        I don't see anything in AjaxShellDelegate that would need modification for me - am I missing something? Unless I radically change (or use a snapshot of a major update to) the dojo API I don't think I need a new delegate. I just need to watch for behavioral changes like the base URL handling one.

        As for the asset URL notation, that shouldn't be a big deal to people as long as it is noted somewhere prominent. I like the deprecation warnings the new Tapestry code generates to help me see what I need to update to migrate to 4.1.

        I wouldn't have embarked on a 4.1.1 migration if I didn't think I could hack it as needed. Overall, I think it's well-crafted and a welcome replacement for the (closure leaking) JavaScript in T4.

        Show
        Greg Woolsey added a comment - I don't see anything in AjaxShellDelegate that would need modification for me - am I missing something? Unless I radically change (or use a snapshot of a major update to) the dojo API I don't think I need a new delegate. I just need to watch for behavioral changes like the base URL handling one. As for the asset URL notation, that shouldn't be a big deal to people as long as it is noted somewhere prominent. I like the deprecation warnings the new Tapestry code generates to help me see what I need to update to migrate to 4.1. I wouldn't have embarked on a 4.1.1 migration if I didn't think I could hack it as needed. Overall, I think it's well-crafted and a welcome replacement for the (closure leaking) JavaScript in T4.
        Hide
        Jesse Kuhnert added a comment -

        Awesome, I'm glad someone is liking the new way of things. There are probably still a few rough edges but I'm sure it'll get worked out soon enough.

        Show
        Jesse Kuhnert added a comment - Awesome, I'm glad someone is liking the new way of things. There are probably still a few rough edges but I'm sure it'll get worked out soon enough.
        Jesse Kuhnert made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 4.1.1 [ 12312021 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12385721 ] Default workflow, editable Closed status [ 12567892 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12567892 ] jira [ 12591814 ]

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Greg Woolsey
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development