FAQ Topic - How can I prevent access to a web page by using javascript? (2010-05-09)
in [JavaScript]
|
Prev: THE LAST ONLINE CASINO SECURITY LINE
Next: FAQ Topic - How can I prevent access to a web page by using javascript?(2010-05-09)
From: Johannes Baagoe on 17 May 2010 05:44 VK : [Rostand, /Cyrano de Bergerac/, tirade du nez] > // original français Très bien, mais néanmoins (si j'ose dire) un peu court, jeune homme. In other words (pardon my French, but you can't say "nosetheless") : I cannot imagine Cyrano running away from matching his words with his deeds with the excuse that an INPUT element is not in a FORM element, or that IE chokes on the RFC4329-approved media type for ECMAScript files. (I have changed the extension of the script file from .js to .es, though. That is, as far as I can see, the only thing that wasn't completely kosher.) -- Johannes
From: VK on 17 May 2010 18:33 On May 17, 1:44 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > VK: > > [Rostand, /Cyrano de Bergerac/, tirade du nez] > > > // original français > > Très bien, mais néanmoins (si j'ose dire) un peu court, jeune homme. Si j'ose de dire, c'est completement beaucoup, monsieur. > In other words (pardon my French, but you can't say "nosetheless") : > I cannot imagine Cyrano running away from matching his words with his deeds > with the excuse that an INPUT element is not in a FORM element, or that > IE chokes on the RFC4329-approved media type for ECMAScript files. Any form element intrinsic event handler has to expose this.form property for further manipulations. Do you have any productive ideas what this.form should point to in the given case? Do you really want to know through what all different troubles producers had to go to - to accommodate this yet another one product of academical thinking about the Web full potential. > (I have changed the extension of the script file from .js to .es, though. > That is, as far as I can see, the only thing that wasn't completely > kosher.) Why not change it to .cpp right away? Doesn't make any difference: type for external scripts type is ignored as well as content-type: due to security issues one doesn't teach you in an academia. ;-)
From: Garrett Smith on 19 May 2010 14:41 Dr J R Stockton wrote: > In comp.lang.javascript message <hsncmp$c0$1(a)news.eternal- > september.org>, Sat, 15 May 2010 17:02:30, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: > >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hsi2vs$3no$1(a)news.eternal- >>> september.org>, Thu, 13 May 2010 16:46:01, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>> >>>> For purpose of the FAQ entry, I have shifted the focus on javascript >>>> being used to restrict access to a web resource. >>>> >>> Such a subject, for the readership that you should be aiming for, >>> will >>> merely add further disguise to whatever other meaning the item may be >>> intended to convey. >>> For a start, who is "I"? >> It is the hypothetical reader that appears in other entries, for >> example: "how do I format a Date object with javascript," "my element >> is named myselect[], how do I access it? > > That is what you think it means; that is what you want it to mean. And > in that case, there is no other reasonable distinct interpretation. Of > course, the FAQ reader may not want to do it himself, but to pass the > advice on. "Formatting a Date Object" is sufficient, since it is a > JavaScript FAQ. > So you want FAQ headings as subjects worded not in the form questions, but as titles of what the entry is about? An FAQ is a traditionally list of questions. A different format could probably work. Here are some other FAQs http://www.copyright.gov/help/faq/ http://subversion.apache.org/faq.html http://httpd.apache.org/docs/1.3/misc/FAQ.html (a roadsign with a close button? On Apache.org?) http://blog.pandora.com/faq/ Everybody seems to be using FAQ in question format. I'm all for progress, but the question format seems acceptable. I see the argument for omitting all the "How do I"'s. Then again, does it need to be changed? I'm not convinced that it does. I'll have to think about that. [...] > > You were asked to notify the group when new FAQ versions are produced, > with their version number and date. Please do so. > I do. That was probably a minor edit. RobG and nick recenty pointed a few mistakes out and it was a clear and obvious error. I said "thanks - fixed" and updated with a new date and same version. > I have on my disc "Version 30, Updated 2010-05-06, by Garrett Smith". > I also have a link to <http://jibbering.com/faq/index.html> which is > "Version 30, Updated 2010-05-13, by Garrett Smith". Same number, > different date - confusing. > I can't stay 30 forever? > Both versions say : > > This is the comp.lang.javascript meta-FAQ, 30. The latest > version is available at http://jibbering.com in HTML form. > Good catch! Fixed. The correct URL is: http://jibbering.com/faq/ Do you think that needs a new version? [...] > The page it links to is interesting, but it is not the FAQ. While it > may be OK to have a short form for access to a page when it will have to > be re-typed, a true link should always be as full as possible. If, as I > suspect, you have access at Jibbering only into the FAQ directory, then > the link should at least be to http://jibbering.com/faq/. Using > http://www.jibbering.com/faq/ would be nicer, because of the common > expectation that Web domain names start "www.". And, if you will ise > index.html for the FAQ, the link should be to > http://jibbering.com/faq/index.html, since that is a more robust form. > About that, I am afraid I'll have to disagree. "index.html" is meaningless as far as the resource goes and there is no reason for a www subdomain alias here. If the FAQ ever changes to PHP (or something else), then it would require extra effort to get the index.html to point to index.php. However, if it is left as a path, that is not necessary. Have we discussed this before? > > > > > The later version says > > 13.1 How can I prevent access to a web page by using javascript? > > In practice you can't. While you could create a suitable encryption > system with a password in the page, the level of support you need to > do this means it's always simpler to do it server-side. Anything that > "protects" a page other than the current one is definitely flawed. > > which says nothing about resources. > > It is also wrong. It cannot be "always simpler to do it server-side", > since there may be no, or very restricted, server-side support. > The FAQ does not go into detail about server side solutions here The entry should be linking to some resources for form-based authentication and rfc2617 for http authentication. If anyone has goo links for form-based authentication, please post them. > > The best way to prevent access to a page such as my "gullible.htm" is to > remove it from the server, returning 401. But copies should still be on > The Wayback Machine. > > Encryption only prevents access to the meaning of the page, not to the > actual content of the source file. If I put up a page advertised as the > full details of Al'Quohol but actually containing 30kB of random Hex, > then all the CIA's codebreakers may download a copy every day in the > hope of cracking the code (thereby amusing the BATF), and costing all of > my bandwidth. Yet they could think that there is content hidden from > them. > Right. You can't actually prevent access to a resource with javascript. > I do not want you all to use my js-quick.htm direct from the server > whenever you want to so arithmetic. So I use JavaScript to prevent a > copy from my server actually doing its work. Not really. > > So you should now see that "prevent access" has multiple applicable > meanings. > I see it may come from different goals; regardless, the word "prevent" is key here. Access to a web page cannot be prevented. Content can be encrypted, user access to a web page can restricted, but not securely with javascript. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: nick on 19 May 2010 15:38 On May 19, 2:41 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > I see it may come from different goals; regardless, the word "prevent" > is key here. Access to a web page cannot be prevented. Content can be > encrypted, user access to a web page can restricted, but not securely > with javascript. If the answer to the question is simply "no," maybe the wording of the question is too narrow. Maybe a more relevant question (to javascript) would be something like: "How can I use javascript to assist in user authentication or access control?" ....that's pretty much how I read the original question anyway, but wording it this way explicitly invites more interesting (and possibly useful) javascript-related answers... javascript doesn't have to be the complete solution, but can it be used as part of the solution?
From: Garrett Smith on 31 May 2010 02:49
On 5/20/2010 9:03 AM, Dr J R Stockton wrote: > In comp.lang.javascript message<63dcdc09-a1e0-4293-a07c-496b4651f554(a)y1 > 2g2000vbg.googlegroups.com>, Wed, 19 May 2010 12:38:44, nick > <nick___(a)fastmail.fm> posted: > >> On May 19, 2:41 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> >>> I see it may come from different goals; regardless, the word "prevent" >>> is key here. Access to a web page cannot be prevented. Content can be >>> encrypted, user access to a web page can restricted, but not securely >>> with javascript. >> >> If the answer to the question is simply "no," maybe the wording of the >> question is too narrow. Maybe a more relevant question (to javascript) >> would be something like: >> >> "How can I use javascript to assist in user authentication or access >> control?" > > The average questioner will not insist on using JavaScript. To be > helpful, the subject should be "User authentication and access control". > The answer should discuss only JavaScript methods, but if possible it > should include a link to other forms of control. Something found by a > Wiki or Web search for "Web User authentication and access control" > might suit. > An actionable conclusion does not appear to have been reached. Garrett |