CGI and external JavaScript nightmare

[IamIan]

My website is built from a Python CGI and works great. I'm now
including Google Ads, which requires two pieces of JavaScript; the
first contains the display settings for the ads, and the second piece
is a very lengthy garbled js file at http://pagead2.googlesyndication.com/pagead/show_ads.js

The first piece of JavaScript works fine and the ads display
correctly, however the second file throws an "unterminated string
literal" js error. Looking at it you can see a healthy amount of both
single and double quotes, which is where my problem lies.

What is the best way to get the second js file into a nice printable/
usable format? cgi.escape? xml.sax.saxutils.quoteattr? String
substitution? I could use some guidance.

Thank you!

 

[IamIan]

bump

 

[Istvan Albert]

is a very lengthy garbled js file athttp://pagead2.googlesyndication.com/pagead/show_ads.js

The first piece of JavaScript works fine and the ads display
correctly, however the second file throws an "unterminated string
literal" js error.

the javescript code above is fine. you must be making some other
error(s)

 

[File Grok]

What's your URL for an example page that is having this error? Trying to
figure out Google's JS is usually an example of self abuse.

 

[Paul Boddie]

My website is built from a Python CGI and works great. I'm now
including Google Ads, which requires two pieces of JavaScript; the
first contains the display settings for the ads, and the second piece
is a very lengthy garbled js file athttp://pagead2.googlesyndication.com/pagead/show_ads.js

Shudder! I don't think I'm even going to look at that.

The first piece of JavaScript works fine and the ads display
correctly, however the second file throws an "unterminated string
literal" js error. Looking at it you can see a healthy amount of both
single and double quotes, which is where my problem lies.

Are you including the JavaScript inline or using a script element in
your HTML?

What is the best way to get the second js file into a nice printable/
usable format? cgi.escape? xml.sax.saxutils.quoteattr? String
substitution? I could use some guidance.

If you're just referencing the JavaScript using a script element, you
don't need to think about encoding, escaping or quoting it since the
browser will read it as text/x-javascript or something like that.
Otherwise, if you have a desperate need to include the JavaScript
inline (actually embedded in the HTML page), then it may help to
include it in a CDATA section. I recall various tricks that may be
necessary, especially when dealing with Internet Explorer brokenness,
but not having to serve Windows users any more (particularly those who
also like ActiveX and think it's part of the Web) means that I don't
care about or recall those tricks readily. Pretending that IE doesn't
support lots of standards usually sets you off on the right foot,
though.

Paul

 

[IamIan]

Thank you for the replies. After a lot of research I tracked down the
issue. I was using the CGI to build all of the pages for the site,
then filling in content with .innerHTML= as users clicked on tabs.
Since I wanted to place the Google Ads in different parts of each
page, the Google Ads JavaScript was in each page chunk being
dynamically placed with .innerHTML.

It turns out that JavaScript isn't executed when it is placed in a
page via .innerHTML. I tried some tricks to execute it after it was
added to the page (eval, appendChild) but it still didn't work. The
Google Ads JavaScript is very touchy and their agreement is very
strict; it wasn't even clear that what I was doing was in line with
it, so I broke the site up into multiple CGI pages and now it works
fine.

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

 

[IamIan]

Thank you for the replies. After a lot of research I tracked down the
issue. I was using the CGI to build all of the pages for the site,
then filling in content with .innerHTML= as users clicked on tabs.
Since I wanted to place the Google Ads in different parts of each
page, the Google Ads JavaScript was in each page chunk being
dynamically placed with .innerHTML.

It turns out that JavaScript isn't executed when it is placed in a
page via .innerHTML. I tried some tricks to execute it after it was
added to the page (eval, appendChild) but it still didn't work. The
Google Ads JavaScript is very touchy and their agreement is very
strict; it wasn't even clear that what I was doing was in line with
it, so I broke the site up into multiple CGI pages and now it works
fine.

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

 

[IamIan]

Thank you for the replies. After a lot of research I tracked down the
issue. I was using the CGI to build all of the pages for the site,
then filling in content with .innerHTML= as users clicked on tabs.
Since I wanted to place the Google Ads in different parts of each
page, the Google Ads JavaScript was in each page chunk being
dynamically placed with .innerHTML.

It turns out that JavaScript isn't executed when it is placed in a
page via .innerHTML, it is inserted as text hence the unterminated
string literal error. I tried some tricks to execute it after it was
added to the page (eval, appendChild) but it still didn't work. The
Google Ads JavaScript is very touchy and their agreement is very
strict; it wasn't even clear that what I was doing was in line with
it, so I broke the site up into multiple CGI pages and now it works
fine.

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

 

[IamIan]

Thank you for the replies. After a lot of research I tracked down the
issue. I was using the CGI to build all of the pages for the site,
then filling in content with .innerHTML= as users clicked on tabs.
Since I wanted to place the Google Ads in different parts of each
page, the Google Ads JavaScript was in each page chunk being
dynamically placed with .innerHTML.

It turns out that JavaScript isn't executed when it is placed in a
page via .innerHTML. I tried some tricks to execute it after it was
added to the page (eval, appendChild) but it still didn't work. The
Google Ads JavaScript is very touchy and their agreement is very
strict; it wasn't even clear that what I was doing was in line with
it, so I broke the site up into multiple CGI pages and now it works
fine.

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

 

[allen.fowler]

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

Not sure I fully understand the question.

Can you post the CGI code here?

 

[IamIan]

Thank you for the replies. After a lot of research I tracked down the
issue. I was using the CGI to build all of the pages for the site,
then filling in content with .innerHTML= as users clicked on tabs.
Since I wanted to place the Google Ads in different parts of each
page, the Google Ads JavaScript was in each page chunk being
dynamically placed with .innerHTML.

It turns out that JavaScript isn't executed when it is placed in a
page via .innerHTML. I tried some tricks to execute it after it was
added to the page (eval, appendChild) but it still didn't work. The
Google Ads JavaScript is very touchy and their agreement is very
strict; it wasn't even clear that what I was doing was in line with
it, so I broke the site up into multiple CGI pages and now it works
fine.

One CGI question - since all of my CGIs are spitting out HTML is their
source code safe? wget and linking to the source deliver the output
HTML. Are there any other methods of trying to steal the source CGI I
need to protect against?

Thank you.

 

[Steve Holden]

Not sure I fully understand the question.

Can you post the CGI code here?

That's funny.

The OP's problem is that he suffers from the delusion that people want
to steal the source code for his CGI script.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

 

[Paul Boddie]

allen.fowler wrote:

[Quoting IamIan...]

[...]

Not sure I fully understand the question.

Can you post the CGI code here?

That's funny.

Yes, there's no point in employing sophisticated technical mechanisms
for security when they are all undermined by some good old-fashioned
social engineering. ;-)

The OP's problem is that he suffers from the delusion that people want
to steal the source code for his CGI script.

The solution being that of ensuring that the Web server settings tell
the server to always run CGI scripts and never serve up the scripts
themselves as content. Additional security, such as file permissions,
access to the server, and so on, are beyond the scope of casual Usenet
advice with the level of detail provided by the inquirer.

Paul

 

[IamIan]

The OP's problem is that he suffers from the delusion that people want
Why is assuming someone may try to get my source CGI delusional?

I'm on a shared server (Dreamhost). The CGI itself has 755 permissions
to execute, but what about folder permissions, etc? If you could
expand on "access to the server, and so on" that would be great.

 

[Istvan Albert]

Why is assuming someone may try to get my source CGI delusional?

I'm on a shared server (Dreamhost). The CGI itself has 755 permissions
to execute, but what about folder permissions, etc? If you could
expand on "access to the server, and so on" that would be great.

- as far as accessing through the web goes this is a matter of
webserver configuration, set up your webserver in a such a way that it
will not return the source code for your scripts

- regarding shared webhosting services, you may not be able to deny
access to people who have shared accounts (and shell login) on the
same server as you do. It all depends on how the shared accounts are
set up.

i.