Selective Public Access for Sites Requiring Login

From TNG_Wiki
Jump to: navigation, search

Summary

If your site prevents anonymous users from seeing your data, but you want to provide SOME teaser information, to enourage signup, or to allow folks to get some idea of what they would receive if they provide you with login information, here's how to do it. You will be able to easily control which pages can be viewed by anonymous folks.


Example Sites

1FamilyTree
Try the cemeteries page. It would normally be restricted to anonymous users, and redirect them to the login/registration page. With this feature implemented, you, the anonymous user, have access.
Farnham&ParadiseOhana
On this site login is required for all functions other than "Search", "Find: Surnames", "Find: Places", "Find: Search People" and "Help:".

Morss/Craig Genealogy

Login is required for everything except Places, Surnames, What's New, and TNG Addons

Current Environment

Your site is restricted to logged in users only

Admin --> Setup --> General Setting --> Privacy --> Require Login = YES


Objective and Requirements

  • Create an exception list, of those pages that can be viewed by anonymous users, or folks who just haven't logged in yet
  • List of exceptions should be easy to maintain, not a "core hack"
  • If a user is logged in, their status doesn't change as they go from free to restricted pages
  • Anonymous users can see the links to restricted pages, and if they click, they get redirected to the login/registration page
  • Any core hacks should be minimized so as to make future upgrades possible


The Code

In human English, what are we trying to do?
If the person wants to look at a page on my exception list, let them look at it, even if they are not logged in.

  1. For some list of files, set needlogin=no
  2. If needlogin = no, and you aren't logged in, skip the login check

Now translate those two steps into a language that the server understands


1. Exception list - CUSTOMCONFIG.PHP

Add this to your customconfig.php file, anywhere in the file, inside of PHP processing. In this example, the exception files are acknowledgements.php, searchform.php, surnames-all.php and places.php
(bfp uses the exception files places.php, search.php, searchform.php, surnames.php, surnames-all.php, and surnames-oneletter.php on Farnham&ParadiseOhana )

// for certain files, don't require login
    /* case "filename" :
        is the line you would add, remove, or change
        "filename" is the name of the php file, before the ".php" part
        suggest alphabetizing the list for ease of maintenance
    */
$file = basename($_SERVER['PHP_SELF'] ,'.php');
switch ($file) {
    case "acknowledgements":
    case "searchform":
    case "surnames-all":
    case "places":
        $needlogin = 'no';
        break;
    default:
        $needlogin = 'yes';
    }

Explanation

  • The name of the php file that the user is requesting is stored in the $file variable. The ".php" part is stripped off, so it's just "acknowledgements" or "searchform" or "surnames-all", even though the user clicked on "http://mysite.com/genealogy/searchform.php" or whatever
  • Documentation of the switch statement in PHP language can be found at PHP.Net or W3 Schools
  • The "switch" function will look at the $file variable, and if it matches the CASE, then the value of the variable $text['needlogin'] is set to "yes"
  • As the PHP manual says: The statement list for a case can also be empty, which simply passes control into the statement list for the next case. That means that you can "stack" the list of files that you want to all have a value of "no"
  • Certainly there are other ways to look at a list of files and set a variable, there are also fancier ways to use the case statements, some of which I have deployed, but that's really beyond the purpose of this article
  • The file has to be in your TNG root directory, if you're using this code

2. Core hack - CHECKLOGIN.PHP

  • This change to checklogin.php is the only modification that would be overwritten in an upgrade.
  • Created for v8.1.1 by lp. Modified and most recently tested on v10.0.2 by bfp.
  • I've included the comment style that I use, with my intials - use your own system that will help you to find your customizations later

Insert the following beginning at line 10

//lp modified 2011-June
    /* allows an anonymous user to view those pages designated with no login needed
        works in conjunction with code in customconfig.php, setting the $needlogin variable
    */
    global $needlogin;
    if (($needlogin == "no") && !$currentuser) {
        return;
        }
//lp end modification

Explanation

  • REALLY simple - if the needlogin variable is set to no, and the person isn't logged in, quit what you're doing and go back to the file that called this checklogin file
  • The reason it needs to be on line 10 is so that the $currentuser variable has been defined

Follow on notes

  • Maybe at some point in the future, this capability could become part of the program, with a nice list of pages and checkbox for the ones you want to be viewable by anonymous
  • My own site and 1familytree.com have both been designed using my "theme" setup, so for us, the variables and file names are a bit different. This article has been written for a standard installation
  • I'd love to see ideas for improvement, this article is, of course, editable!


Additional Modification

I love this tip and have it successfully implemented on my site at Wonson Genealogy. However, I wanted to ‘tease’ out just a little bit more information than places, surnames. etc
This modification can also be seen in action on Farnham&ParadiseOhana

New Objective

How to return a list of names from a search, but keep all other details 'private'?

In other words, if an anonymous user performs a search for a particular name or surname, have the search return results, but limit those results to displaying names only. All other information returned by the search to remain 'private'.

But, if a registered user performs a search for a particular name or surname, have the search return all details as normal.

Hopefully by revealing names, an anonymous user may be more inclined to register, especially if the returned names are also found in their own research work.

Implementation

Follow the above instructions and implement the code changes to restrict access for anonymous users to all pages except those in your exclusion list. For this new additional modification to be successful, ensure you have the following two pages in your exclusion list : search.php & searchform.php

1. Code Addition - New text variables

Add the following lines to the \languages\English\cust_text.php file :

//Used in search.php to hide dates and places returned from 
// a search performed by anonymous users
$text['regonlydate'] = "Registration required to view date";
$text['regonlyplace'] = "Registration required to view place";

(Note: Feel free to change wording to suit your own requirements.)

2. Code Modification - search.php

  • Created and tested in TNG version 9.0.1
  • Insert the code modifications in the following two places within search.php

Insert the following at about line 328,

//Start Modification 
/*Displays names but hides dates and places from search results
    when the search is performed by anonymous users.*/
if ($currentuser) {
//End Modification

or under these lines :

$row['allow_living'] = $rights['living'];
$row['allow_private'] = $rights['private'];


Insert the following at about line 367,

//Start of Modification 
}
else {
     $birthdate = $text['regonlydate'];
     $birthplace = $text['regonlyplace'];
     $deathdate = $text['regonlydate'];
     $deathplace = $text['regonlyplace'];
     }
//End of Modification

or under this line :

else
    $prefix = $suffix = $title = $nickname = $birthdate = $birthplace = $deathdate = $deathplace = "";

Explanation

So, how does it work?

The first modification checks if the visitor is a registered user and encloses the lines that displays the dates and places returned by a search in an IF...ELSE statement block.

The second modification closes out the IF block and provides the alternative lines of code required to hide the dates and places returned by the search in the ELSE block.

When a registered user performs the search, the $currentuser variable is true, so the statements enclosed in the IF block are processed and the dates and places are returned for the user to view.

If a non registered user performs the search, the $currentuser variable is false, so the statements enclosed by the ELSE block are processed instead. Dates and places returned by the search are now replaced by our new cust_text variables.

Example of how the search results are returned for anonymous users:

Search results returned to anonymous users

When the anonymous user clicks on a name they are then presented with the log in screen, where they have the option to register for a user account.

Caveat Emptor - Let the buyer beware

The above code modifications were tested and implemented on my site where I have the following privacy settings:

  • Require Log in --> Yes
  • Restrict access to assigned tree --> Yes
  • Show living data --> Depending on user rights
  • Show Names for Living --> No
  • Show Names for Private --> No

Your privacy settings may differ, so ensure you fully test the code changes before implementing on your live site. This will ensure that the returned search results are displayed as expected.

View example : search

Extra Tip

You may find the columns on the search result page a 'little tight' when displaying the new cust_text variables :

Tight columns....not nice!

It's a bit tight here....


If so, add a few non breaking spaces to the end of the text variable lines:

$text['regonlydate'] = "Registration required to view date   ";
$text['regonlyplace'] = "Registration required to view place  ";

Nicely spaced columns....Great!

Now you have a nicely spaced column!!