Password Protected Sites Options

[IGP]

This is hopefully an easy question.

If you have a password protected site, how do you keep people from learning a URL address of a page past the password page and just typing it in their browser? Asked differently, is there a way to keep a page from being accessed by typing it's URL into a browser, so the only way to get to it is to navigage to it from within a website?

[Darin McGrew]

If you have a password protected site, how do you keep people from learning a URL address of a page past the password page and just typing it in their browser?

You protect the whole site, and not just the entry page.

See also the FAQ entry How do I password protect my web site?

Asked differently, is there a way to keep a page from being accessed by typing it's URL into a browser, so the only way to get to it is to navigage to it from within a website?

That's a different question. Are you trying to implement password protection, or are you trying to prevent deep linking?

[IGP]

If someone who has knowledge of code could respond, I'm looking for code to include in my page that will prevent anyone from getting to it by typing the URL into their browser. I want them to have to get to it by navigating my site. Detailed, specific reference to commands is what I'm hoping for. Thanks.

[Darin McGrew]

I'm looking for code to include in my page that will prevent anyone from getting to it by typing the URL into their browser. I want them to have to get to it by navigating my site.

That is generally a bad idea. See also Deep Linking is Good Linking

But if you insist, you can attempt it. The details vary depending on the server software you're using. For example, if you're running Apache and have access to mod_rewrite, then see the "Blocked Inline-Images" example in the Apache URL Rewriting Guide

[IGP]

I'm looking for code to include in my page that will prevent anyone from getting to it by typing the URL into their browser. I want them to have to get to it by navigating my site.

That is generally a bad idea. See also Deep Linking is Good Linking

But if you insist, you can attempt it. The details vary depending on the server software you're using. For example, if you're running Apache and have access to mod_rewrite, then see the "Blocked Inline-Images" example in the Apache URL Rewriting Guide

thanks, but none of what you are providing is relevant to what I'm trying to do.

[Darin McGrew]

thanks, but none of what you are providing is relevant to what I'm trying to do.

Okay, so what are you trying to do?

[Darin McGrew]

I'm looking for code to include in my page that will prevent

This is the part of your request that can't be done. You can't "include code" in a page to protect it. You can only configure your web server to protect pages.

[IGP]

I'm looking for code to include in my page that will prevent

This is the part of your request that can't be done. You can't "include code" in a page to protect it. You can only configure your web server to protect pages.

Thanks, really, but you don't have much skill in relaying your real or perceived knowledge of such things. Nothing you've offered so far has ANYTHING to do with my original question. In the future, if you want to be taken seriously by those who post here, you must learn to carefully READ AND COMPREHEND their question before replying.

Good luck to you.

[Peter1968]

Darin told you the answer. There is *no code* that can be entered into any given page that will prevent someone from going straight to a page if directly typed in. Javascript will not cut it, as it can be disabled and referrer redirecting, another kludge used to prevent deep-linking or direct access via typing a URL, is easily gotten around as well.

The only way to remotely get what you're after to work is to use a server-side solution, such as authentication or scripting, and that involves a lot more than simply entering "code" on a page.

Do you understand that? Darin knows what he's talking about and I'm afraid you simply don't like the (correct) answers that you are receiving.

You need a server-side solution and that goes above and beyond any help this forum (a HTML and CSS forum, no less) can really offer you.

[Darin McGrew]

Nothing you've offered so far has ANYTHING to do with my original question.

Okay, I'll bite. What is the original question, and in what way do my previous responses not address what you're trying to do?

[IGP]

Nothing you've offered so far has ANYTHING to do with my original question.

Okay, I'll bite. What is the original question, and in what way do my previous responses not address what you're trying to do?

In a former life, probably before you were born, I was one of the foremost computer system designer and coder in America. It was in that life where I developed the brilliance that allows me to judge your menial ability. Although I don't participate in that world anymore, I do still occasionally "tinker" with small projects for my own use. Such spawned the question that began this thread.

Read the question I asked again, now, and then I will educate.

I have identified 3 plausible solutions. Here is the one I ultimately chose and then learned how to code. There is a tool in your world known as a "cookie." There was no such animal in my world. It's closest predecessor would have been a COM area being passed between 2 CICS programs. Anyway, I have coded a password page where I send someone and have them enter a password by responding to a PROMPT. The way I've coded this, they can't view the source while the page is displayed. I have learned, however, that they can just disable Javascript, then look at the source, and then enable Javascript and enter the password that they were able to retrieve from the code. In your world of "open code", such is unavoidable (at least with a client-side solution.)

When they enter a valid password, I set a cookie on their box with a value that identifes which of several valid passwords they entered. The expiration date on the cookie is set for 45 seconds from the time it's set. I then use a "window.location" command to send them to the protected page. When the protected page loads, it first checks for the existence of the cookie. If none is found, they are not coming into the page from the password page. They've typed in the URL into their browser. If this is the case, I don't want them in the page. I send them back to the home page of the site. If I find the cookie, I know they're coming from the password page that has just sent them here. I let them stay. If this user copies the URL address while here, and then comes back in an hour and pastes the URL into their browser, the protected page will no longer find the cookie (it expired after 45 seconds) and it will send them back to the site's home page.

Read the original question again. The above, while not fool proof, will certainly defeat the novice user. Even the best server-side solutions are not 100% fool proof. I've already coded this and it works well. The hardest part was finding a source of Javascript command syntax that clearly shows all of the available options for all possible commands. In my day, such reference books were readily available. Today? Using the browser of your choice, try to find an online source that completely shows Javascript command syntax. One of the biggest problems is the freedom of the Internet has allowed "would be" experts a forum to post less-than-accurate information. This site could be an example. I suppose a trip to the nearest Borders Bookstore may have provided a more reliable source of info.

Anyway, back to my earlier post in this thread. Read the question and don't manufacture in your mind what they "really" are asking. Just answer what they've asked.

I have now educated.

[Peter1968]

I don't know about Darin McGrew, but if you posted such crap on any website I ran, it'd be the last time you did it.

This is Darin's house (et. al) and like anyone who has a house, someone coming inside and then shitting on their carpet isn't appreciated.

You came here for help, nobody came to you. I'm sorry you think the world owes you something.

[Darin McGrew]

The way I've coded this, they can't view the source while the page is displayed. I have learned, however, that they can just disable Javascript, then look at the source, and then enable Javascript and enter the password that they were able to retrieve from the code. In your world of "open code", such is unavoidable (at least with a client-side solution.)

As the FAQ explains, JavaScript password scripts provide only a facade of security. If you verify the password with a server-side program and have that server-side program set the cookie, then you'll have a more secure system.

When they enter a valid password, I set a cookie on their box with a value that identifes which of several valid passwords they entered. The expiration date on the cookie is set for 45 seconds from the time it's set. I then use a "window.location" command to send them to the protected page. When the protected page loads, it first checks for the existence of the cookie.

Okay, so you've tried to protect the content itself, rather than just the entry page. That's good. But by the time "the protected page loads", it's too late. Using JavaScript to redirect them afterwards provides only a facade of security.