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: FAQ server on 8 May 2010 19:00 ----------------------------------------------------------------------- FAQ Topic - 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. The complete comp.lang.javascript FAQ is at http://jibbering.com/faq/ -- The sendings of these daily posts are proficiently hosted by http://www.pair.com.
From: nick on 8 May 2010 21:32 > Anything that "protects" a page > other than the current one is definitely flawed. The current what? Page? That sounds a little confusing. Would something like this capture the intended meaning better? 'Any attempt to restrict access to a page using client-side scripting is definitely flawed.'
From: nick on 9 May 2010 02:35 On May 9, 1:22 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > FAQ server wrote: ----------------------------------------------------------------------- > > FAQ Topic - 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. > > I actually don't know what "level of support" means here. Yeah, the whole thing is awkward isn't it. > Can the answer be shortened to: > > | You can't. Access to a page can be restricted by requiring user > | authentication on the server. Maybe throw in a paragraph mentioning HTTP Digest Authentication and the optional 'user' and 'password' parameters for XHR.open (and a warning not to do that over a non-encrypted connection) for readers looking for something "ajaxy?"
From: David Mark on 9 May 2010 20:15 nick wrote: > On May 9, 1:22 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> FAQ server wrote: > > ----------------------------------------------------------------------- >>> FAQ Topic - 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. >> I actually don't know what "level of support" means here. > > Yeah, the whole thing is awkward isn't it. Yes, the explanation itself is definitely flawed. I couldn't make heads or tails of it.
From: Dr J R Stockton on 10 May 2010 13:09
In comp.lang.javascript message <hs5grk$507$1(a)news.eternal- september.org>, Sat, 8 May 2010 22:22:54, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >FAQ server wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - 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. >> >I actually don't know what "level of support" means here. > >Can the answer be shortened to: > >| You can't. Access to a page can be restricted by requiring user >| authentication on the server. No. Firstly, the meaning of "access" must be clarified. If the page is accessible at all, nothing purely client-side can prevent someone who wants to see the content from reading it, as served. At the other extreme, there's a significant proportion of authors who firmly believe that the code of a page can ONLY be revealed using the right-click menu. They are wrong; but disabling that menu will prevent any of them seeing the code of a page. Now consider a page consisting of two frames. One contains an ordinary "enter password" box, ten characters wide but accepting many more. The other frame contains the "meat" of the page, but in a hidden DIV encoded to the author's private key. To reveal the "meat", one needs the corresponding public key, which goes (in Hex, reversed) into the password box. Entering the "password" causes the encoded material be decoded by said public key and revealed on another DIV. And add a bit of distracting material in each page. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7) |