Forum Discussion

jonathancrow's avatar
11 years ago

Passing parameters to an iFrame

Ok more than a little pleased with myself, since I am not a coder it was pretty cool when I saw this work.

 

The problem I had was that I had a form (using Eloqua but could be any form) posted in an iFrame on the site. The frame needed to autofill values (such as email address) that were passed in the query string via an email. The iframe was not passing the parameters and I couldn't use javascript in the article so I thought I was screwed.

 

Then I realized that if I added the javascript to the header of the skin wrapper it would work for any iframes that needed to be passed parameters via the query string, but if there were no paramters, it would just do nothing. So I added this code (from a guy on the Eloqua forum)  to my header wrapper:

 

 

<script type="text/javascript">
$(document).ready(function()
{
var loc = window.location.toString(),
params = loc.split('?')[1],
iframe = document.getElementById("trackFrame");

iframe.src=iframe.src + '?' + params;
});

</script>

 

 

Then in the article I added the parameter id="trackFrame"

so that the iFrame looked like this:

 

<iframe id="trackFrame" src="http://my.company.com/theurl" width="300" height="500" frameborder="0"></iframe>

 

Eh voila when I click the link in the email my email address prepopulates on the form.

  • PaoloT's avatar
    PaoloT
    Lithium Alumni (Retired)

    Hi jonathancrow 

     

    I would be careful with this approach - I think you may want to do a bit more validation on the value of the "params" variable to prevent possible XSS attacks to your pages. 

     

    If you know what kind of values your are expecting for the pre-filling then it should be possible to validate the parameters and discard them if they look suspicious.

     

    Hope that helps!

  • It's a clever solution. As Paolo said, there is a risk of XSS due to the lack of filtering on the URL. OWASP are a pretty good resource if you want to know more about this kind of thing:

    https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

     

    A couple of suggestions:

    * You could wrap the JavaScript in some FreeMarker so that it only appears on the pages you want.

    * If the user is logged in, you can retrieve the email address and other user info from FreeMarker, avoiding the need to extract it from the URL.

    * It's probably OTT for what you need, but you could look at encrypting the user's email address in the URL to avoid potential abuse.

  • Thanks guys. I will definitely look into this XSS issue more before going live.

     

    One more question I have though, I found that it worked fine when I was already logged into the community, but if I was redirected to the login page first it didn't work. Any thoughts on what I would have to do to get this working?

     

    I have SSO turned on. Do I need to do anything to the field "URL to login page"? It looks like the query string is getting removed when I get redirected to the login page.

     

    Thanks,

    Jonathan

    • nathan's avatar
      nathan
      Executive

      With SSO, Lithium redirects the user to an external URL (configured in Lithium admin). Lithium includes the URL of the original page (in the parameter return_url) so that the extenal site can redirect the user after they have logged in. However, the implementation of this is down to the external site.

       

      It's hard to know for certain without seeing the site, but I suspect that at some point during the redirection, the extra parameters are getting stripped out of the URL (probably when the external site redirects the user back to the community).

       

      If the user needs to be logged in to access the page with the iframe, it might be worth exploring the option of retrieving the email address from FreeMarker rather than the URL.