Output CSS font colour as variable

[Axehack]

Is there any way to output the colour of a font as a variable?

We have 1 page (lets call it Parent) containing a style sheet(same domain) and an iframe (Cross Domain).

The Parent style is dependant on the user logged in, each user has custom branding.

The only thing that needs to change within the iFrame to conform with the parent, is the font colour.

I was thinking if the parent could say:

<iframe width="915" scrolling="auto" height="1500" frameborder="0" marginwidth="0" marginheight="0" src="<IFRAME URL HERE>?<FONT COLOUR VARIABLE HERE>" id="screenerFrame" name="screenerFrame"> </iframe>

Then we could just use:

$font=$_GET['variable'];

Thats my thoughts anyway, But how do we go about outputting the font colour to append to the URL in the 1st place?

If you can think of a better way to do this, Im all ears! Thanks!

 

[office politics]

this may help

JavaScript Help: How to access parent elements from a child window or frame

 

[Baez]

Are you using any sort of javascript library?

 

[Axehack]

Sorry Office Politics, But I doubt that will help as we are working cross-domain.

Baez, We are using Javascript and Jquery, if you can come up with something that will work x-domain, then im all ears, I was just hoping it could be retrieved with PHP. If you use javascript, then It cannot be output as a php variable.

 

[Baez]

Well my understanding is not outputting the variable that's your problem but retrieving the variable from the original CSS property correct?

 

[office politics]

Sorry Office Politics, But I doubt that will help as we are working cross-domain.

they covered that aspect


quote:
So, how can we fix these kinds of problems? Here are some suggestions for getting around cross-domain same origin policy issues:

1.Same domain -- Well, first off, -IF- you can get everything on the same domain, that's the optimal scenario--because it's the simplest; everything will "just work" automatically.
2.Proxy -- Since same-domain is usually not feasible you may want to create a proxy to basically fool the browser into thinking the content comes from the same domain (while this sounds nefarious, sadly this is common-place in many AJAX applications today pending a better solution).
3.JSONP -- If you have access to both domains, you may be able to set up a scenario in which the output of your requests basically get wrapped in a mechanism that causes them to be instantiated in such a way that the same origin policy doesn't get applied. Personally this situation has been rare for me so I don't use this, however, you can find more info about JSONP here.
4.Try/Catch error handling -- If none of these fit the bill, and you are willing to accept that sometimes your scripts will work and sometimes they wont, then you may want to use TRY/CATCH with your script in order to control and gracefully handle the behavior when something goes wrong and an error occurs. This can be complicated if you aren't accustomed to building code in anticipation of unexpected failures--pretty common in my experience.

 

[Axehack]

Yes Baez, Thats right. The thing is, I suppose it doesnt actually have to be from the CSS, if there is a way to grab it from the live document, that would be fine.
To be honest, im shooting in the dark as we have no access to the parent document, although any changes we require to make the styling work can be made for us.

I 'believe' they are using sessions, So I am hoping there is style information held within the $_SESSION variable, then that could just be passed accross with somethign like:

$fontcolor = $_SESSION['fontcolour'];

<iframe src=www.google.com?fontcolor=<?$fontcolor?> id="screenerFrame" name="screenerFrame"> </iframe>
------------------------------------------------------------------------------------------------------------------------------------------------

I Know thats a long shot, but we do also have access to the CSS, infact the iFrame is running on a local copy of it, so if they actually just sent the session data, shouldnt we be able to use that to refer to the style sheet anyway?

 

[Axehack]

Office Politics,

Same Domain - Impossible, or there would be no need for an iframe in this instance.
Proxy - Impossible, Sensitive documents.
JSONP - Dont really have access to both domains, the developers of the parent may look at this for passing the variable's though.
Try/Catch - I dont really see how this helps? I know the scripts I have dont work, from what I know about try / catch is -:

TRY
Questionable code goes here
If it works: You get this: "Confirmation / processing code"
If it doesnt work you get: "Error Code"
So if I already know my code isnt going to work, Try / Catch is just going to give me a message that I define saying that it didnt work, when I already knew that before i wrote the code.

And to top it off, none of these (as far as i am aware) helps with retrieving the CSS / Style information.

Thanks for the input tho, I appreciate the effort.

 

[office politics]

found this interesting hack; linked below. it looks like they are updating the src of their bottom frame, picking up the new location via the top frame, and extracting the info they need.

Enabling cross-site scripting XSS via an iframe - Code Couch

 

[Axehack]

Nice Idea, although very hacky, we did look into this a while back, but it doesnt work either.

This is fine for re-sizing an iFrame (although its not needed as there is a proper way to do it now)
Which is passing info from the child to the parent, We need info from the parent to the child.

I have so far come up with 2 solutions which have been refused for their "Hacky" nature, but considering we are trying to bypass a security policy... anything we doo will likely be considered "hacky"