FAQ Topic - How can I prevent access to a web page by using javascript? (2010-05-09)

[VK]

VK :

That is nice to know - a much simpler way to prevent unwanted access
to my pages


I shall bear it in mind if and when I intend to accommodate non-conforming
browsers.

Other words if ever decide to accommodate your solutions for more that
40%-45% of your Web visitors... I don't think it's a suitable approach
for c.l.j. Browser-specific tech forums in their intranet sections are
definitely the choice to post such solutions.

or (obsolete but more logical) language="JavaScript".

  language = cdata [CI]

  Deprecated. This attribute specifies the scripting language of the
  contents of this element. Its value is an identifier for the language,
  but since these identifiers are not standard, this attribute has been
  deprecated in favor of type.

Yes, I know - and I didn't tell you that you *had* to use it. Just
bear in mind that W3C opinions on anything as of the year 2010 are
negligible. One day I may tell you the whole story of that "standard"
type attribute and that "standard" text/javascript value. It is
interesting and funny. Yet again fill free to use type="text/
javascript"

There is no form, just an INPUT element. Which, being a %formctrl;
and therefore an %inline; is perfectly legal in a P element.

Irrelevant to me. I am the service customer you are benefiting from:
either by having your code QA'ed or by having my proven wrong and
stupid. You are the service provider - and in order to get "paid" you
gonna do what I want, and if I don't give a damn if the original
coding is allowed or not - you'll have to do the same. Or no
contract.

Pretty much like with Firefox guys and Bank of America director back
in 2006: they were singing for an hour of how autocomplete attribute
for text fields breaks standards, W3C's "Web full potential", personal
karmas etc. At the time limit end the BoA representative simply said:
"Thank you for all this interesting information. By this Friday
Firefox has to have autocomplete implemented exactly as it is in IE.
If yes, at Monday we are signing the contract. If not, at Monday we
are signing the contract with Microsoft. Thank you for your time."
That was the first really harsh lesson of the real life Mozilla had to
learn and I really enjoyed their faces at the moment... Also guess:
was autocomplete implemented as requested by that Friday or not? Check
it out ;-)

Nothing is wrong. Wanna bet ?

Do what your customer want first - without questioning his sanity,
intellectual level, professionalism and by keeping friendly smiling.
When will talk about the payment. :-|

 

[David Mark]

VK :


I cannot imagine a visitor who has no standard-conforming browser
and who would still be interested in anything I have to say.


I would argue exactly the contrary: comp.lang.javascript is about the
computer language javascript, which has nothing at all to do at with
browser-scripting except for a historical accident. Questions about
workarounds for buggy browsers should be discussed in the appropriate
vendors' forums. (Or, at the very least, be appropriately tagged in
the subject line.)

No, this is browser scripting central. That's what most JS is targeted
at. It's no accident.

If anything, it is the other way round - you offer a quality control
service I might be interested in. If serious, you should take the
job as it is, without demanding arbitrary alterations to suit your
habits. Just as I would if you decided to hire me as consultant.

But no contract. My opinion about your competence in cryptology was
made the moment you posted your nonsense about Shannon's Clairvoyant.

Don't encourage VK. Just ignore him (her?)

On the other hand, *you* asserted repeatedly that something is
impossible. Everybody who took the trouble to actually check came to
the opposite conclusion. The reflex of declaring it impossible (which
I shared, too, before Stockton first, and then Jorge made me rethink)
comes from considering only the terrible solutions that are implicitly,
but not explicitly, assumed in the FAQ, viz. obfuscating a password.
My solution does nothing of the kind.

I have now explained that three times. If you still do not want to
check and take the last chance of a graceful retreat, I shall not
additionally rewrite my page according to your whims to make you do
so. After all, the way you manage your reputation is your own concern.

VK's reputation is long-established (a nut-case).

 

[VK]

VK :

Johannes Baagoe :
I cannot imagine a visitor who has no standard-conforming browser
and who would still be interested in anything I have to say.

So you have nothing interesting to say or to propose to the Web...
That's a little bit sorry but totally acceptable. Just don't position
it as a right and the only right state for a Web developer.

Johannes Baagoe :
I would argue exactly the contrary: comp.lang.javascript is about the
computer language javascript, which has nothing at all to do at with
browser-scripting except for a historical accident. Questions about
workarounds for buggy browsers should be discussed in the appropriate
vendors' forums. (Or, at the very least, be appropriately tagged in
the subject line.)

And here you are deeply wrong. First of all there is a deepest
difference between i) Javascript implementation peculiarities - which
are in total no bigger that C / C++ implementation peculiarities - and
ii) DOM interface differences - which are nearly endless. Secondly the
only source of existence of this newsgroup instead of some fit all
microsoft.public.scripting.jscript etc. is that endless legions of
post-war developers - including your humble servant - kept
accommodating all different DOM interfaces in a single solution so
letting weak to get stronger and letting silly ones to eventually
abandon their silliness without loosing the market completely.

If anything, it is the other way round - you offer a quality control
service I might be interested in. If serious, you should take the
job as it is, without demanding arbitrary alterations to suit your
habits. Just as I would if you decided to hire me as consultant.

To take your proposal into consideration I am at the very least
entitled to demand that it would work for the majority of Web users.
By that I mean that out of 1000 visitors at least 500 can have *any*
experience out of your solutions, positive or negative. If you
consider this requirement as being overly strict then again you have
chosen a wrong NG to post your ideas.

I have now explained that three times. If you still do not want to
check and take the last chance of a graceful retreat, I shall not
additionally rewrite my page according to your whims to make you do
so. After all, the way you manage your reputation is your own concern.

Very true. And if I decide to go over the troubles explaining why
adding intermediary wheels C, D, E, F and by changing their shape to
another one still doesn't make wheel A turning wheel B and wheel B
turning wheel A - if I decide so I am entitled to see all wheels to
examine to be clean and the area swiped nicely.

 

[VK]

Don't encourage VK.  Just ignore him (her?)

VK's reputation is long-established (a nut-case).

THE VISCOUNT:
No one? But wait!
I'll treat him to. . .one of my quips!. . .See here!. . .
(He goes up to Cyrano, who is watching him, and with a conceited air):
Sir, your nose is. . .hmm. . .it is. . .very big!
CYRANO (gravely):
Very!
THE VISCOUNT (laughing):
Ha!
CYRANO (imperturbably):
Is that all?. . .
THE VISCOUNT:
What do you mean?
CYRANO:
Ah no! young blade! That was a trifle short!
You might have said at least a hundred things
By varying the tone. . .like this, suppose,. . .
Aggressive: 'Sir, if I had such a nose
I'd amputate it!' Friendly: 'When you sup
It must annoy you, dipping in your cup;
You need a drinking-bowl of special shape!'
Descriptive: ''Tis a rock!. . .a peak!. . .a cape!
<...>

http://pd.sparknotes.com/lit/cyrano/section5.html // English

http://fr.wikisource.org/wiki/Cyrano_de_Bergerac_(Rostand)#Sc.C3.A8ne_IV
// original français

 

[VK]

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. ;-)

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 15 May 2010 17:02:30, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Thu, 13 May 2010 16:46:01, Garrett Smith

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.

Indeed, consider a similar situation in a hypothetical newsgroup for
Web-only VBScript : "How do I find the offset from GMT using VBScript".
The true answer may well be "You cannot". A helpful response would be
more like "MS IE also knows JavaScript : after
<script type="text/javascript">
Offset = new Date().getTimezoneOffset()
</script>
a VBScript section can read Offset (in minutes)". That would be
appropriate in News - but in a VBScript FAQ that answer would call for a
matching Subject such as "How do I find the offset from GMT" or "Finding
the offset from GMT".

A question such as you propose could easily be
How so?

By speaking, in your presence, the words "How can I prevent access to a
web page by using javascript?". It's a perfectly reasonable question
from an office manager who has heard that browsers can be controlled by
script, and wishes to prevent the staff reading Dilbert when they should
be working. Your current answer would clearly be inapplicable to his
question.

----

You were asked to notify the group when new FAQ versions are produced,
with their version number and date. Please do so.

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.

Both versions say :

This is the comp.lang.javascript meta-FAQ, 30. The latest
version is available at http://jibbering.com in HTML form.

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.





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 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.

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. You can of course download
the page and use it locally (as it says); you can upload it to your
server, and it will work directly from there. I'm only interested in
protecting my bandwidth.


So you should now see that "prevent access" has multiple applicable
meanings.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 15 May 2010 17:02:30, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Thu, 13 May 2010 16:46:01, Garrett Smith
<[email protected]> 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.

 

[nick]

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?

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 19 May 2010 11:41:43, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Sat, 15 May 2010 17:02:30, Garrett Smith

Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Thu, 13 May 2010 16:46:01, Garrett Smith
<[email protected]> 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.

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.

I looked at a few found by a Google search for "FAQ". The question
format is common (and for many articles appropriate), but other forms of
Subject often appear. The subject should suit the contents, and not
merely adhere to a purported tradition.

You can always define in the FAQ the word Wyktma as "Will you kindly
tell me about", and put that at the beginning of Subjects where you
think it is needed.

"Wyktma controlling access to a Web page?"
"Controlling access to a Web page?" is better.

BTW, "controlling" is better than "preventing"; if it is a Web page,
there's a reasonable presumption that some form of access is to be
allowed.

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 can't stay 30 forever?


Good catch! Fixed. The correct URL is: http://jibbering.com/faq/

Do you think that needs a new version?

The version number should be changed whenever there is a significant
change. The date should change whenever the date (preferably UTC)
changes. You could number versions as 35.00 and increment the fraction
for merely cosmetic changes. But there should be no two versions
released with exactly the same version number.

Have we discussed this before?
Yes.




Not really.

Yes, really. Except maybe if JavaScript is disabled when the page is
fetched and enabled after that. Perhaps I can deliver the textarea as
readonly and script the removal of that. That will be better, since the
demos will then be visible.

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.

Note that there is a distinction between executing a Web page directly
from the server (which costs server bandwidth) and executing an
unmodified copy from the local disc or elsewhere (which does not). One
can allow use of a page, but limit mode-of-use, by testing
location.href.

 

[Dr J R Stockton]

In comp.lang.javascript message <63dcdc09-a1e0-4293-a07c-496b4651f554@y1
2g2000vbg.googlegroups.com>, Wed, 19 May 2010 12:38:44, nick

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.

 

[Garrett Smith]

In comp.lang.javascript message<63dcdc09-a1e0-4293-a07c-496b4651f554@y1
2g2000vbg.googlegroups.com>, Wed, 19 May 2010 12:38:44, nick


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