Disabled "File-Save As" and Right-button mouse

@creadmanDec 29.2002

I would like to find the JavaScript source to disabled the “File-Save As” and “Right-button” on mouse.

I know I can’t always protect the source code, but if it’s enabled, they won’t be able to see it.

What do I need to do to add it to my JavaScript coding?

What function do I use? Where do I look in my JavaScript books?

Is there something available…Freeware?

to post a comment

JavaScript

10 Comments(s) _↴

@Zach_ElfersDec 29.2002 — #Dave, do you know how to disable menu items, like Save As or View Source? I'm not sure if it can be done though.

@pyroDec 29.2002 — #[i]Originally posted by Dave Clark[/i]

[B]your source is still completely available to anyone and everyone who cares to look in their own Temporary Internet Files folder (cache) on their harddrive.[/B][/QUOTE]

Not entirely true. I believe you could avoid this with the following line.

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

I doubt there is any way to disable the File->Save As option in a browser, though...

Also, I really don't know why everyone is so set on protecting their source. Do you really think that you have made something that hasn't been done before or that someone else can't easily re-create? The beauty of HTML/JavaScript IMO is that it *is* available for all to see... :rolleyes:

@jeffmottDec 29.2002 — #[i]creadman[/i]

[b]I know I can't always protect the source code, but if it's enabled, they won't be able to see it[/b][/quote]

Those who do want to view your source will be mildly humored by your feeble attempt. And _everyone_ will be annoyed that you site has removed a menu that exists only for convienence.

@pyroDec 29.2002 — #[i]Originally posted by jeffmott [/i]

[B]And _everyone_ will be annoyed that you site has removed a menu that exists only for convienence. [/B][/QUOTE]
I certainly would be.

@Beach_BumDec 29.2002 — #the simple way to disable right click in IE6 and NS7 (don't know about other browsers) is:

<body oncontextmenu="return false">

no script needed. easy and gets you coverage for the vast majority of people.

@blufiveDec 29.2002 — #Pyro:Not entirely true. I believe you could avoid this with the following line.

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">[/QUOTE]That is not the preferred way to control browser caching. The HTTP/HTML specs make no guarantees about what browsers should do with it. You should use the cache-control HTTP header instead.

Dave Clark:Browsers have not been written (yet) that will render your page without storing that page (and its content) on the local harddrive. [/QUOTE]The "cache-control: no-store" header should prevent the page ever hitting the hard drive. To quote from the spec:

(RF2616, section 14.9.2):the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.[/QUOTE]Any browser that actually stores such information on disk is breaking the HTTP 1.1 spec. Which isn't to say that it doesn't happen, but I'd be surprised if any of the major modern browsers screwed it up. For the purposes of rendering, most browsers have a separate RAM-based cache, as hinted at by the spec - inspecting stuff in there is somewhat harder than browsing a folder on the hard drive.

I recommend reading these two documents for more details on caching:

http://www.mnot.net/cache_docs/

http://www.w3.org/Protocols/rfc2616/rfc2616.html (sections 13 and 14.9)

But, as everyone has been saying until they're blue in the face, you can't prevent people seeing the source. You can make it harder (and probably annoy users in the process), but you can't stop it. At the bottom line, the the browser has to have a copy of the page source in order to render it. And the browser works for the user, not you. If someone is REALLY determined, they can just knock up a very simple Java program (for instance) which will fetch a web page from a URL and show the source. Such programs are a standard tool for web browser developers.

@pyroDec 29.2002 — #[i]Originally posted by blufive[/i]

[B]That is not the preferred way to control browser caching. The HTTP/HTML specs make no guarantees about what browsers should do with it. You should use the cache-control HTTP header instead.

[/B][/QUOTE]
This is from section 14.9

[i]Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see section 14.32).[/i]

[i]Originally posted by Dave Clark[/i]

[B]All that statement does is tell the browser not to reuse what is in the cache.[/B][/QUOTE]
Maybe..I don't know for sure. Guess I'd have to check to be sure, but since I like my pages to cache... :p

@blufiveDec 29.2002 — #(http/1.0 caches, pragma: no-cache, and cache control headers)

Note that section 14.32 refers only to REQUESTS containing pragma: no-cache. Section 10.12 of the HTTP 1.0 spec (RFC 1945) similarly only refers to requests. The behaviour of a cache when presented with a Response (page) that includes pragma: no-cache is completely undefined. They could broadcast it on CNN without breaking the specification, so there's no guarantees about whether they cache it or not.

By now, most of the web servers out there support HTTP 1.1, as do modern browsers. AFAIK, the largest remaining obstacle to a total switchover is that some popular proxies still have difficulties.

(stuff being cached by IE despite no-store headers)

Colour me semi-surprised. Well, that's yet another bug in IE then.

@blufiveDec 29.2002 — #Don't know as I'd call it a "bug", for sure yet.[/QUOTE]If they don't implement HTTP 1.1 as per the relevant RFC, it's a bug in my book.
all of the current Netscape versions also cache as I've described[/QUOTE]If so, they are also wrong.
Can you provide me with a link to something that uses "no-store" so that I can specifically test it?[/QUOTE]Not at present, sorry.

@blufiveDec 29.2002 — #Dave, I'm beginning to see why some people around here react so negatively to you. Do you always want the last word on EVERYTHING?

While we're at it, RFC 2616 is the responsibility of the Internet Engineering Task Force (http://www.ietf.org/) NOT the W3C. It's a protocol for transmitting data, not a format for the data itself.

Many Requests For Comments go on to become full-blown Internet Standards. You mess with them, and you can't talk to the internet.

RFC 2616 is currently a Draft Standard. To quote from the Internet Standards Process, "A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered."

Any changes to HTTP 1.1 have the potential to be severely disruptive to the net at large. Nor is it merely the business of Browser manufacturers. It's used by proxies and web servers too. Anything claiming to work with HTTP or the Web should be designed to implement it correctly and in full. if it doesn't, then the DESIGN is bugged (yes, there can be bugs in design, too).

This goes WAAAAY deeper than any arguments about whether the W3C has the right to define HTML. Or perhaps we should play fast-and-loose with TCP/IP, too?

And now we've drifted a zillion miles off-topic. I've stated my case, which ain't gonna change any time soon, so I'm leaving it there. If you want to pick an argument, go do it with someone else.

Also in #JavaScript _↴

Content Warning Session Cookie What kind of menu is this?How do I display a simple if/then text message!

Success!

Help @creadman spread the word by sharing this article on Twitter...

Tweet This

Disabled "File-Save As" and Right-button mouse

10 Comments(s) _↴

Also in #JavaScript _↴

Success!

Social

Version

Disabled "File-Save As" and Right-button mouse

10 Comments(s) ↴

Also in #JavaScript ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

10 Comments(s) _↴

Also in #JavaScript _↴