Shindig
  1. Shindig
  2. SHINDIG-1509

Strange frameset rendered within javascript

    Details

    • Type: Question Question
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.0
    • Fix Version/s: None
    • Component/s: PHP
    • Labels:
      None
    • Environment:
      Windows7, XAMPP 1.7.4 [PHP: 5.3.5]

      Description

      Hello,

      I have shindig running as a virtual host. Name 'shindig' mapped to 127.0.0.1 in the hosts file.
      When I use "http://shindig/gadgets/ifr?url=http://www.labpixies.com/campaigns/todo/todo.xml" I found the following strange frameset inbetween the rendered javascript part:
      ...
      function _IG_AddDOMEventHandler(src, etype, func)

      { gadgets.warn("_IG_AddDOMEventHandler not implemented - see SHINDIG-198"); }

      <frameset rows="100%,*" frameborder="no" border="0" framespacing="0">
      <frame src="http://www.shindig.com/?fp=F4DZth3CTXk6TL3aXOVfx6KeDDx4%2BfpwCUHi2kxCwyD3PM7GZJL1s6yW19fj5znr%2BH7Qdw6vNxpIp4iwiKynDA%3D%3D&prvtof=aiVUCn7CCaCNLPMu7TGydJ9WL8sIBwiLOLpO4AcsNaRdqLnhP4AmrBkRW7rxeADeKLFsAxEPU06jwlvypVSitB7nFluoWrO4kGjGV2jjpN3Vgp6Rpl3n8GQr9lnL%2B12x&poru=I2tOFFTNOpyvdk81PAJ3YH0qIt2qcBiFwmmhgyqTA%2BVW6Z592rsWQJSfp1k4PJ2r1Ay9nkEiFK4IwW%2F9s2Ag5ptUNXC8xf9bicjyU8F7WqMsNEPXF5m5hjjuY4TgAwHk&">
      </frameset>
      <noframes>
      <body bgcolor="#ffffff" text="#000000">
      <a href="http://www.shindig.com/?fp=F4DZth3CTXk6TL3aXOVfx6KeDDx4%2BfpwCUHi2kxCwyD3PM7GZJL1s6yW19fj5znr%2BH7Qdw6vNxpIp4iwiKynDA%3D%3D&prvtof=e3T%2B8TBsHWD9s96kniyFJnQdeu%2FjQ9SuHmTcvEh3pIdxBa3a3v%2FaONhEj5gc%2Fm9A3POXosYkitE0545be9OGf1rGXlo38ezJ6kSXa2oZrsO8VuWaiUmvRa2MfNX57Dd6&poru=Kdz9XHLXCGdYRV63tzLDiFHdZK91FMIAk6BDg55lsdrV36KzI5sN0rJWlrrEFM2640s0fZXb2a1EHceooizICzqFFJJoWuIdAera9b%2BwTtoi%2F0uwfFIRbuhfV0dJloRk&">Click here to proceed</a>.
      </body>
      </noframes>
      /*

      • Licensed to the Apache Software ...

      As this is no javascript it causes a syntax error and makes the whole gadget unusable showing javscript errors. I was unable to find where that html snippet is coming from. However it is inserted in between the js from legacy.js and dynamic-height-util.js. As a bad work around I openend a comment /* at the end o f legacy.js and closed it in in the beginning of dynamic-height-util.js. With that hack the gadget above is working. But that is of course not a solution. With other gadgets e.g. SocialHelloWorld (http://shindig/gadgets/ifr?url=http://shindig/samplecontainer/examples/SocialHelloWorld.xml) it seems to insert the same frameset, but this time it produces "Error parsing gadget xml:...".

      I tried to check container.php if there is anything looking like a bad reference, but nothing seems to show an indication where that strange frameset is coming from.

      It would be nice if anyone could help me understand what is wrong here.

      Kind regards,
      Thorsten

      1. container.php
        12 kB
        Thorsten Erlewein
      2. RenderedSocialHelloWorld.htm
        34 kB
        Thorsten Erlewein
      3. RenderedTodoExample.htm
        571 kB
        Thorsten Erlewein

        Activity

        Hide
        Thorsten Erlewein added a comment -

        The errors with uncompressed javascript. Look for frame or frameset in the htm.

        Show
        Thorsten Erlewein added a comment - The errors with uncompressed javascript. Look for frame or frameset in the htm.
        Hide
        Thorsten Erlewein added a comment -

        I just installed wireshark and found that the frameset is the content of the follwoing request made from the apacher server:
        GET http://www.shindig.com/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js HTTP/1.1
        I will check for the sanitizer now.
        To be continued

        Show
        Thorsten Erlewein added a comment - I just installed wireshark and found that the frameset is the content of the follwoing request made from the apacher server: GET http://www.shindig.com/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js HTTP/1.1 I will check for the sanitizer now. To be continued
        Hide
        Bastian Hofmann added a comment -

        There seems to be a configuration error somewhere. The script should normally be loaded like this:

        http://shindig/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js

        Show
        Bastian Hofmann added a comment - There seems to be a configuration error somewhere. The script should normally be loaded like this: http://shindig/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js
        Hide
        Thorsten Erlewein added a comment - - edited

        Good point. As my apache sits behind a proxy I have maintained the 'proxy' in container.php. Is it possible that the dns resolution would ignore my local etc/hosts file where shindig is set to 127.0.0.1 and try the proxy? In that case I would need to configure exceptions when not to use the proxy. Something like in IE "Do not use proxy for addresses....". Is that possible with Shindig?

        Thanks for the comment.

        Show
        Thorsten Erlewein added a comment - - edited Good point. As my apache sits behind a proxy I have maintained the 'proxy' in container.php. Is it possible that the dns resolution would ignore my local etc/hosts file where shindig is set to 127.0.0.1 and try the proxy? In that case I would need to configure exceptions when not to use the proxy. Something like in IE "Do not use proxy for addresses....". Is that possible with Shindig? Thanks for the comment.
        Hide
        Thorsten Erlewein added a comment -

        By renaming my virtual host in shindig.local.company.com I don't get the frameset any longer. Simply because
        request URI: http://shindig.local.company.com/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js
        will just return a 404 as it still looks to be routed to the proxy.

        >Network Error (dns_unresolved_hostname)
        >Your requested host "shindig.local.company.com" could not be resolved by DNS.
        >For assistance, contact your network support team.

        The same URL in the browser works perfectly. Can I somehow configure proxy exceptions for shindig?

        Show
        Thorsten Erlewein added a comment - By renaming my virtual host in shindig.local.company.com I don't get the frameset any longer. Simply because request URI: http://shindig.local.company.com/gadgets/resources/com/google/caja/plugin/html-sanitizer-minified.js will just return a 404 as it still looks to be routed to the proxy. >Network Error (dns_unresolved_hostname) >Your requested host "shindig.local.company.com" could not be resolved by DNS. >For assistance, contact your network support team. The same URL in the browser works perfectly. Can I somehow configure proxy exceptions for shindig?
        Hide
        Thorsten Erlewein added a comment -

        Allright. I did some changes in \htdocs\shindig\src\common\sample\BasicRemoteContentFetcher.php that make it work for me. I changed the function initCurlHandle($url). There is the code:

        $proxy = Config::get('proxy');
        if (! empty($proxy))

        { curl_setopt($handle, CURLOPT_PROXY, $proxy); }

        So if proxy is set, it always uses it. I wrapped that code pragmatically in:
        if (! strpos($url, '.local')) {
        $proxy = Config::get('proxy');
        if (! empty($proxy))

        { curl_setopt($handle, CURLOPT_PROXY, $proxy); }

        }

        But this is of course just quick workaround. Better would be to define an array of exception patterns in container.php. E.g.:
        'proxy_exceptions' => array('.company.com','.local'),
        and evaluate that exceptions in function initCurlHandle. When ever it finds a match for the URL in the exceptions it should not set the proxy.

        Show
        Thorsten Erlewein added a comment - Allright. I did some changes in \htdocs\shindig\src\common\sample\BasicRemoteContentFetcher.php that make it work for me. I changed the function initCurlHandle($url). There is the code: $proxy = Config::get('proxy'); if (! empty($proxy)) { curl_setopt($handle, CURLOPT_PROXY, $proxy); } So if proxy is set, it always uses it. I wrapped that code pragmatically in: if (! strpos($url, '.local')) { $proxy = Config::get('proxy'); if (! empty($proxy)) { curl_setopt($handle, CURLOPT_PROXY, $proxy); } } But this is of course just quick workaround. Better would be to define an array of exception patterns in container.php. E.g.: 'proxy_exceptions' => array(' .company.com',' .local'), and evaluate that exceptions in function initCurlHandle. When ever it finds a match for the URL in the exceptions it should not set the proxy.
        Hide
        Ryan Baxter added a comment -

        Can we close this? Does anyone have any interest in fixing this?

        Show
        Ryan Baxter added a comment - Can we close this? Does anyone have any interest in fixing this?
        Hide
        Ryan Baxter added a comment -

        Moved PHP to attic so we are closing this issue for now

        Show
        Ryan Baxter added a comment - Moved PHP to attic so we are closing this issue for now

          People

          • Assignee:
            Unassigned
            Reporter:
            Thorsten Erlewein
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development