TOPIC:

When creating a custom web page, you can set it to Public, Members or Officer access. When you create a Unlisted Access page, it is always public. Yes, the page is hidden, but if someone was able to access the page with the link, there is no security around it. For example, an internal club page is created. A person, who is a member at the time, book marks the page. They then let their membership laps and are removed from the members only links. However, if they use their bookmark, they can still access the page. What I would expect is if they are not logged in, they would get some sort of error and be redirected back to the home page or a login page. This is a simple example, but I can think of many more that would be much worse then one person accessing the page.

I agree with this. I've often had reservations about making a member-only page hidden, for exactly these reasons.

If anyone would like a workaround, I came up with this javascript. It seems to meet about 85% of my needs so it is better than nothing.
<!-- Check Logged In -->
<script language="JavaScript">
function getCookie(cname)
{
var name = cname + "=";
var ca = document.cookie.split(';');
for(var i=0; i<ca.length; i++) {
var c = ca;
while (c.charAt(0)==' ') c = c.substring(1);
if (c.indexOf(name) == 0) return c.substring(name.length,c.length);
}
return "";
}

var LoggedIn = getCookie("FTH.MSID");

if(LoggedIn.length < 1)
{
window.location = "http://" + window.location.host + "/";
}
</script>
<!-- End of Check Logged In -->

Your test is flawed, since the actual test checks whether the cookie value matches what is in the db, not whether a cookie value exists.

A reliable method is to just check for the existence of element id memberlogout which is the member logout button. E.g.,
Of course, if I choose to change that ID, well, all bets are off...

Yes, I know this is a hack, which is the 85%. In all my testing, which I admit was somewhat limited, I always saw the session cookie (i.e. FTH.MSID) being deleted on logout.

Using the element ID make the code simpler as I don't need to parse the cookie. (As long as the ID does not change.) My one question is why the double exclamation points (i.e. !!) . Does this not just return the getElementById result?

New code (using Steve's concept)

<!-- Check Logged In -->
<script language="JavaScript">
if (!document.getElementById("memberlogout"))
{
window.location = "http://" + window.location.host + "/";
}
</script>
<!-- End of Check Logged In -->

!! is "bang bang" ... forces boolean result... It converts a "truthy" value to pure boolean. (look it up)
There are cases where a boolean result (and only a boolean result) is what is really needed.

Steve - could something be added to the system to provide an extra category for Private Unlisted pages?

Pam wrote:

Steve - could something be added to the system to provide an extra category for Private Unlisted pages?

It will not be done that way.

Keep in mind that I tend to think much faster than I can produce the code. I am essentially already 2 FTH versions ahead in my mind...

It is the code implementation, the testing, the maintaining and all the other stuff that takes up the real time. I tend to keep my ideas to myself so you guys don't kill me demanding everything be done tomorrow. hehe

I just need someone to invent a data download cap that I can wear...