problem javascript disabled

[sooty2006]

i got a website that needs javascript for the page to function otherwise it creates problems,how can i create a pop-up etc using php to redirect them to a page saying they need to have there javscript enabled to visit the page?if u can im not sure?any help will help me alot!thanks scott!

[Ingolme]

PHP is not an alternative to Javascript. It can not open popups and it can't detect if Javascript is disabled.You can do something like this on your page to indicate to the user that they need java script:

<div id="noscript">You need Javascript to view this page correctly</div><script type="text/javascript">document.getElementById("noscript").style.display = "none";</script>

[sooty2006]

PHP is not an alternative to Javascript. It can not open popups and it can't detect if Javascript is disabled.You can do something like this on your page to indicate to the user that they need java script:

<div id="noscript">You need Javascript to view this page correctly</div><script type="text/javascript">document.getElementById("noscript").style.display = "none";</script>

ok thanks alot mate it works

[Jesdisciple]

Can't you also use <noscript> like so?

<noscript>You need Javascript to view this page correctly</noscript>

[boen_robot]

Can't you also use <noscript> like so?

<noscript>You need Javascript to view this page correctly</noscript>

Some proxies strip out JavaScript. In these cases, the browser doesn't render <noscript> tags' contents, as from the browser's point of view, JavaScript is not disabled - it simply isn't present.The above method doesn't suffer from this problem. If JavaScript is stripped out, the div is displayed as normal. The same goes if JavaScript is disabled.

[Jesdisciple]

I hope this isn't too far off topic, but... Isn't that a violation of the HTTP standard, because the proxy is actually altering the communication between client and server? EDIT: Also, why would a proxy do that?

[boen_robot]

I hope this isn't too far off topic, but... Isn't that a violation of the HTTP standard, because the proxy is actually altering the communication between client and server? EDIT: Also, why would a proxy do that?

Why do you think HTTPS was developed? Exactly to avoid this "man in the middle" security flaw.Infact, there doesn't need to be a special "proxy" the browser must be adjusted to. An ISP can redirect all requests to a processing script on an HTTP server, letting the HTTP server fetch the real content and do whatever manipulations it wants... heck, I have actually done exactly that for my local network. We planned to allow free ad driven access to the internet. We'd fetch an HTTP page, inject a div in it with the ad, and let it slide. Eventually, we (me really) realized that there aren't enough ad suppliers and for many people, an ad driven internet would be enough => there wouldn't be any profit.For when I have a little more free time, I plan to again do some HTTP manipulation, this time easing the experience of the average users on our network (similtaniously decreasing external traffic => giving our hardware some time to "take a breath") - highlighting torrent files that have already been downloaded by someone from our network, so that everyone else on the network will know they can download this torrent file with a lightning speed. (Doesn't it sound cool?)Yet, if I was a BOFH, I could store users' passwords to any non HTTPS protected web sites, and maybe later try them on to HTTPS protected ones (hmmm....)Why would a proxy strip JavaScript you ask? Well, beats me... they just do. If I was a system administrator of such a network, I'd rather push upgrades and completely deny access to any web page when people have not upgraded. Seems more cruel at first sight, but it's better in the long term.Corporate proxies strip JavaScript as an attempt to make web surfing in their network more "secure". Again, if you ask me, that's not really much of a security. Nowadays, there are very few JS security issues, and when such are found, they are fixed in a timely manner by the affect browser vendor(s). Such vulnerabilities get exploited only after they are found and fixed, so essentially, "hackers" rely on you not upgrading => keep upgrading and you'll be safe.

[Jesdisciple]

Then would it be wise to use HTTPS when JavaScript (or noscript) should be seen by the client whether the proxy likes it or not? (In this hypothetical situation, there is no login or other kind of form that conventionally requires HTTPS.)

[boen_robot]

Then would it be wise to use HTTPS when JavaScript (or noscript) should be seen by the client whether the proxy likes it or not? (In this hypothetical situation, there is no login or other kind of form that conventionally requires HTTPS.)

On a corporate network, they'd either disable HTTPS sites and/or allow certain whitelisted ones (eg. a login form to a specific site that is used within the company). Unless you think your site deserves to be explicitly whitelisted, you shouldn't force everything on HTTPS. Also, note that HTTPS resources are not cacheable by proxies, and (I think) neither by browsers.Besides, it's not very performance wise to use HTTPS on pages that don't gather sensetive data. The verification process of each session (i.e. the request and response of each image, script, stylesheet, page, etc.) increases the time it takes to download and render the page. You can especially notice this on slow internet connections and old computers. And if you decide to mix HTTPS and HTTP, users will get a warning message that some of the page content is not secure (I personally hate this warning).

[justsomeguy]

I hope this isn't too far off topic, but... Isn't that a violation of the HTTP standard, because the proxy is actually altering the communication between client and server?

The proxy is the client.

Also, why would a proxy do that?

Check out Proxomitron, the interface looks like an acid flashback but it lets you do some pretty cool things, you can strip out whatever tags you want or modify the response that comes back before the browser gets it. It also has some debugging features like looking at the raw requests and responses.

[Jesdisciple]

The proxy is the client.

Yes, I understand that. But doesn't HTTP require (except in special cases) that a proxy refrain from modifying the (the upstream server's) data before passing them on to the next client computer?

Check out Proxomitron, the interface looks like an acid flashback but it lets you do some pretty cool things, you can strip out whatever tags you want or modify the response that comes back before the browser gets it. It also has some debugging features like looking at the raw requests and responses.

I didn't mean to ask for a reason for a proxy to modify data in just any way... Why would it modify it by removing <script> and (particularly) <noscript> tags? But boen already gave one valid case (of a corporate proxy). (I guess some bug with the <noscript> tag makes it a security risk just like the other?)

[boen_robot]

I never said <noscript> tags get stripped. They aren't. It's just that the browser won't show them.Imagine this, you have your original page with this code:

<html>...<body>...<script type="text/javascript">...</script><noscript>You must have JS enabled.</noscript></body></html>

After the proxy gets it, it changes it to

<html>...<body>...<noscript>You must have JS enabled.</noscript></body></html>

and gives that to the true client.The browser of the true client has JavaScript turned on. By specification, <noscript> is an element who's content is rendered by user agents only if they don't support any scripting or if such scripting has been disabled. Since IE does support JavaScript and it is enabled, the contents of the <noscript> never gets rendered. At the same time, the script element was stripped by the proxy already, so you have no JavaScript either.As for proxy being in violation of the HTTP protocol, it isn't. As said, it's the client. HTTP describes how the communication server/client proceeds. Once the data reaches the client, the client can do whatever it wants with the data. What a proxy does is to accept a request (like an HTTP server), request the page from the real server (like an HTTP client), receive it (like an HTTP client), alter it and send the response back to the browser (like an HTTP server). You still have one client/server pair at a time. It's just that there are two clients and servers in the way.

[justsomeguy]

But doesn't HTTP require (except in special cases) that a proxy refrain from modifying the (the upstream server's) data before passing them on to the next client computer?

The definition of the protocol doesn't include how the client is allowed to use the response, it's just a set of rules that 2 computers follow when communicating with each other.

[shadowayex]

Well the last 9 posts have nothing to do with the original question. So, since I've read those posts over and over and still made little sense of them, I must ask: do <noscript> and the other way both work in the case of proxies and whatnot (all that stuff you guys were talking about). Or did you sceintifically disprove one or both and I totally missed it. Because if <noscript> works at all times, I'd rather use that. It's less typing .

[Synook]

No, <noscript> won't work if the JavaScript code is stripped from the document before it is received by the client.

[shadowayex]

So the other method will? or will not?

[Synook]

Yes, the division with instant JavaScript CSS modification will work.

[shadowayex]

Ok, thanks. Have fun with you proxy VS http VS https royal rumble.

[Jesdisciple]

OK, now I understand what you're saying about the noscript tag and proxies. And as for HTTP as it regards proxies, I see that I was understanding it backwards; in certain cases it requires that the proxy not modify/remove headers, but modification of the content itself is never addressed.Thanks! (And sorry, ragae! I actually thought you were done here.)

[boen_robot]

OK, now I understand what you're saying about the noscript tag and proxies. And as for HTTP as it regards proxies, I see that I was understanding it backwards; in certain cases it requires that the proxy not modify/remove headers, but modification of the content itself is never addressed.Thanks! (And sorry, ragae! I actually thought you were done here.)

Actually no. Headers are part of the content too. Proxies could also alter headers if they want to. Most don't though.Use a tool like Fiddler to see the "raw" HTTP request and responses - THAT is what the proxy deals with. Actually, now that I've mentioned Fiddler, Fiddler is (in it's essence) a proxy, and you can notice it's able to edit anything in the requests or responses (automatically, or taking them on hold for you to manually fiddle them).

[Jesdisciple]

Most such restrictions only apply to "transparent" proxies, but non-transparent ones are also subjected to a few. Here are the only three that I found with a simple Ctrl+F search for "modify."

A proxy MUST NOT modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: - Content-Encoding - Content-Range - Content-Type A non-transparent proxy MAY modify or add these fields to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the message (see section 14.46).

A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server.

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).