Restricted pages 1

[arlequin]

How can I deny permission to some users to navigate to my "fill-in form" page?<br>
I don't want all the users to reach this page, only the one who know the password, but I don't want then to see the source codo and watch for the password!!!<br>
<br>
Can anybody help me?

 

[rycamor]

In the end, there is no 'airtight' method for preventing someone from reading the code to a Javascript authentication dialog. You can make it a little harder by using &lt;script language="JavaScript" src="yourcode.js"&gt; but a determined person can get this easily.<br>
<br>
To truly protect the page, you have two methods if your hosting service gives you access to them:<br>
<br>
The easiest is to place the form page in a protected directory on the server that automatically prompts for a password. There is a good possibility that your web hosting service has an automated way for you to protect a directory. If not you might want to try another provider. (jumpline.net has worked well for me) Or if you are using the FrontPage extensions it's very easy.<br>
<br>
The second method is to create a CGI or ASP script (depending on your web server) that takes input from a small form and determines whether to redirect the user to the form page.<br>
<br>
Good luck

 

[steeleweed]

I use the following code:<br>
Entry page (index.html) contains:<br>
&lt;script language="JavaScript"&gt;<br>
var x = ".html"<br>
var y = prompt("Enter Password","null")<br>
var q = x + y<br>
window.location = q<br>
&lt;/script&gt;<br>
<br>
If user does not enter any password, he is taken to<br>
"null.html" which is a page that tells him he can't get in and what to do next.<br>
If user enters (for example) 'secret', he is taken to <br>
"secret.html", which is the protected page...unauthorized users would have to guess the name of the page. You should rename the page periodically and so inform your authorized users...<br>
G'luck<br>
RS

 

[rycamor]

I salute you for an elegant and simple solution. Clever.

 

[robherc]

only ONE problem.....what about the dork who's looking over someone's shoulder & sees that the url is: <A HREF="

http://www.whatever.com/something/secret.html"

TARGET="_new">

http://www.whatever.com/something/secret.html</A>

& just browses directly there???<br>
<br>
One way around this difficulty is the most effective JS password protection scheme I've seen yet. (aside from actively encrypting & decrypting that password data client-side)<br>
<br>
<i>&lt;script language=&quot;JavaScript&quot;&gt;<br>
var x = prompt(&quot;Enter Password&quot;,&quot;&quot;<br>
show(x)<br>
function show(url)<br>
{<br>
&nbsp;window.open(eval(x+'.html'),'authenticate')<br>
&nbsp;window.authenticate.pass=x<br>
}<br>
&lt;/script&gt;</i><br>
<br>
in the <i>x.html</i> page, load an image (<i>x</i>.gif) using the <i>pass</i> variable that you just passed the password to; if the image loads, have it print the protected page into itself via <i>document.writeln('blah blah blah')</i> statements; if the image doesn't load (i.e. <i>&lt;image onError=</i>) have the new window simply close itself before the user gets a chance to view source on it (using noStatusBar and noLocationBar attributes on the new window will greatly enhance this as the new window will then not give away the URL to even a determined user unless they dig through the whole of both codes. (including some junk setTimeouts & math computations/variable convertings throughout your completed code will also greatly enhance the security by making it harder to read only the important code amongst the huge amount of filler....<br>
<p>-Robherc<br><a href=mailto:robherc@netzero.net>robherc@netzero.net</a><br><a href= > </a><br>*nix installation & program collector/reseller. Contact me if you think you've got one that I don't