This is a simple way to protect various pages by limiting the number of times an unregistered user can view them and may intice those that "lurk" to login or register at your site.
This will set a cookie that counts protected page views and when the maximum limit is reached it will inform the viewer to login or register to continue. This is not to be considered as a way to secure your site as anyone can delete their cookies and continue. Those who have cookies disabled will be unaffected as well.
Just thought I would add that this could be made to work with .threads database and store IP addresses with the number of views. This would be much more secure than using cookies but would add about 2-3 additional queries to protected pages if done the way I think it could be done.
I guess it depends on cases, what you need. I think cookies is just fine. Would it be easy to set the cookie to expire after 24 hours? That is, allowing unregistered users to view, for example, 20 pages per day?
If I use this for myself I'll probably put in a database table to track by IP as it's more secure. I thought about using the "whos online" table with a few new fields to track the information since IP addresses are stored there already but this would require many more scripts to be modified.
I'm still debating if having 2 extra queries is worth it. lol (I thought 3 may be needed but have trimmed it down to 2 while thinking about it)
Personally, for me, it wouldnt be worth adding 2 queries to track it by IP. Most have dynamic IPs, so the best, to me, would be just cookies. True it is not the "most secure" system, but enough for me. Yes you can delete cookies, but is it worth two queries more? A very small minority would delete them, maybe one out of every 100, if at all. Not worth it to me. I dont mind a few finding their way through, its not that big of a deal.
Same here. The way that I implemented it, I have protection on every page with the exception of login.php, newuser.php, and ubbthreads.php. I didn't set it on those pages because doing so would prevent anyone from logging in, or registering as a new user in the event they had reached the maximum number of page views. As for ubbthreads.php, I don't mind if people look at the main index for the board and see the forums we have to offer.
It works great. I logged out and browsed around. After 10 page views I was taken to the screen prompting me to either login or register. I have the cookie set to 1 year right now, but I may change that. It doesn't really bother me that people can get around it by clearing their cache of cookies.
Yes those with dynamic IP addresses will be able to disconnect from their dial up service and come back with possibly a different IP address. One of the reasons I had thought about using the "whos online" table was that I think I could get the number of queries down to one extra. If I find myself looking for something more to mess with I'll probably work on this. lol
Hi Dave, this is a hack I had trouble to install. (Maybe it is because I use THREADS 6.01)
If I put the hack as instructed, the following else statement refers to the hack and unregistered users see no content any more, appart from the registered and the unregisterd nav bar at the same time.
If I move the hack BEFORE the last closing } of the regular code it works. But then I get this, If I am not logged in:
Warning: Cannot add header information - headers already sent by (output started at /homepages/21/d24400447/htdocs/php/forum/templates/default/ubbt_header.tmpl:23) in /homepages/21/d24400447/htdocs/php/forum/ubbt.inc.php on line 485
(Line 485 is the line with the setcookie command).
I have the same system working on my site http://www.extremebikini.com - I track IPs of people throughout my site and they show up in whose online (and I report the number of users online in the front page).
I'm sorry extremebikini, I figured those looking at this were coming from the thread where you mentioned it and I said I'd do it for Wraith. But yes, you are in fact the one that suggested the idea.
I haven't looked at your site as far as examples go though. The tracking by IP wasn't for a "whos online" but to avoid using cookies as they are not fool-proof. I figured with some work the "whos online" table could be modified along with some other scripts so the IP addresses could be used from that table rather than creating a new table to store IP information and related page views in it. That way when a certain IP address reached it's page view limit they could be presented with the "login or sign up" screen.
Once again though, Thanks for the cookie protection idea.
I thought about tracking IPs at one point (been using this setup for over a year when I had the same integration with UBB5); but the problem was that it isnt much more reliable than cookies. I get a significant amount of traffic from AOL, which as you probably know uses proxies with rotating IP addresses.
I get an occasional user who doesnt accept my cookies and complains (however, recent polls show less than 1% of internet users use cookie control); but I didnt plan my solution to be a "secure" system; just something to get people signing up (I get about 100+ signups a day now).
No harm, I posted my example and the roadmap for what I did in the event anyone else was interested in the concept. You just put something together faster than I could for posting.
I manage some chat servers. AOL is a pain. LoL When dalnet banned AOL users I thought it was toooo funny.
hmmm actualy, msn users with hotmail accounts that filter the emailed password they are sent at signup are more of a pain especially when they send me an email complaining that they never recieved it. arrrgggg!
By the way, I use this kind of protection thoughout my site, not just the message boards - I make people register for an id to view images and videos on my website (they get 10 free image views).
You can easily add this to your site by adding code to check for your cookie and increment the counter if they dont have an id.
i.e. If user a belongs to Group -1- allow them to view the page. But if that user does not belong to that group stop processing the page so the contents of the page never go across the wire?
If someone was looking for a way to secure a certian page on their website using UBB.threads security would this be the best way to do it? ( I understand the goal you are trying to accomplishing above.)
Warning: Cannot add header information - headers already sent by (output started at /homepages/21/d24400447/htdocs/php/forum/templates/default/ubbt_header.tmpl:23) in /homepages/21/d24400447/htdocs/php/forum/ubbt.inc.php on line 486
Warning is still there. Line 486 is the line with the cookie instructions. - I wonder why you all got the hack working and not me
I tried adding in the extra bracket, but I ended up with a parse error in ubbt.inc.php on line 1600 and something. Basically it was waaaaaaay down in the file. My suspicion is you maybe closed out one to many if/else statements.
if ($protected && !$user['U_Username']) { if (!$postviews) { $postviews = 0; } $postviews++; $exptime = time() + 86400;// the cookie will expire in 24 hours $maxviews = 10;// this is the maximum number of views before login is required setcookie("postviews","$postviews",$exptime,"{$config['cookiepath']}"); if ($postviews > $maxviews) { // no loitering ;) include "$thispath/templates/$tempstyle/ubbt_no_loitering.tmpl"; $this -> send_footer(); exit; } } } // Otherwise they are logged in so they get the special menu else {
Yep, that fixed it. I didn't really look at the instructions, so you'll want to make sure that you're replacing enough of the code that you eliminate that problem.
Otherwise, it works great. No more double headers.
Has anyone really TESTED it as a not logged in User? I wonder what that "HEADER already sent" warning has to do with the setting of the cookie, and why it appears at all. (I am using Threads 601 and yes, I have the {} set right as instructed )
I'm not sure but is it possible that there may be a space at the end of your ubbt.inc.php script after you edit it? I think Rick mentioned once that if ther is a space after ?> at the end of the script it could cause this error.
This hack is pretty simple. I can hardly believe it's causing so much trouble... lol
Carl could you email me your ubbt.inc.php file and I'll have a look. Thanks.
Dave, thank you for posting this. This is exactly what we were looking for when I asked about a month ago if anyone knew how we could show our forums without letting people actually read the posts (until they register.) We decided limiting it to 10 views per day would be a great compromise (although I know I could change that number to anything.)
I have it installed and it is working fine. I only put the [:"red"]$protected = 1;[/] in showflat.php and showthreaded.php. I couldn't really think of any other pages we'd need to restrict -- guests don't have access to Who's Online, User List, Member Profiles, etc., anyway. Am I missing something major? (Too many kids, too little sleep -- makes the mind slow. )
posted by caymuc: Has anyone really TESTED it as a not logged in User?
Actually, I have. Which is how I first discovered that multiple navigation menus were being sent to anonymous users, which was a problem for me since I greatly restrict what is displayed on the menu to unregistered guests. With the modifications Dave posted, it is working just fine.
You're more than welcome to test it out by visiting my website. The address is: http://www.terranbbs.com Browse around in the various threads, etc and you'll see that after 10 page views you're automatically directed to the page requesting that you either login or register.
Lisa:
I added it to every page with the exception of newuser.php, login.php, ubbthreads.php, and index.php. That way even if someone has reached their maxiumum, they can still register or login as well as view the website entrance or the main index. If you use a text editor like EditPad Pro (http://www.editpadpro.com) then it is a simple matter to open all of the files and do a global search/replace. It took me about 5 minutes to add it to all of the files.
[] I'm not sure but is it possible that there may be a space at the end of your ubbt.inc.php script after you edit it? I think Rick mentioned once that if ther is a space after ?> at the end of the script it could cause this error. Hi Dave,
I did the hack over again on my unhacked UBBT 6.01 (only template changes) and checked for spaces at the end. I followed your instructions exactly! Same errors:-(
if ($protected && !$user['U_Username']) { if (!$postviews) { $postviews = 0; } $postviews++; $exptime = time() + 86400;// the cookie will expire in 24 hours $maxviews = 10;// this is the maximum number of views before login is required setcookie("postviews","$postviews",$exptime,"{$config['cookiepath']}"); if ($postviews > $maxviews) { // no loitering ;) include "$thispath/templates/$tempstyle/ubbt_no_loitering.tmpl"; $this -> send_footer(); exit; } } }
// Otherwise they are logged in so they get the special menu else {
// ------------------------------ // Update the who's online screen
Now to protect a specific page you need to add this variable to it:
code: $protected = 1;
Place the above variable just above the line that requires the main.inc.php file into the script.
Here is a showflat.php example:
On line 21 and 22 you will see this:
code: // Require the library require ("main.inc.php");
change that to this:
code: $protected = 1; // Require the library require ("main.inc.php");
Now your showflat.php script is protected.
Another example:
To protect your showthreaded.php file you will change the following code, located on lines 22 and 23:
code: // Require the library require ("main.inc.php");
to this:
code: $protected = 1; // Require the library require ("main.inc.php");
Hi, thanks for your help, Dave. I appreciate that very much.
I did excactly follow your instructions, and in 6.0.1, but for some reason a header is sent here before the cookie is written. But obviously I am teh only one with that problem. ...Maybe some of the other hacks? I need to investigate further... too bad.
Just a thought, have you modified the no_loitering.tmpl file? Or, if pulling a full page in with the include you may get the "header already sent" error. Also, if useing 'header ("Location: http://www .blahblah. com");' to take the user to a different page when they go over the limit will cause this error when a page that uses it has already sent it's own header.
I have no idea whether it didn't worked here but obviously worked with anybody else..
I solved it by dividing the hack into two parts:
a)
find
code: // ----------------------------- // Grab any personal preferences $FrontPage = $user['U_FrontPage']; $Privates = $user['U_Privates']; $Status = $user['U_Status']; $ubbt_language = $w3t_language; if (isset($user['newlanguage'])) { require ("{$config['path']}/languages/{$user['newlanguage']}/generic.php"); }
Place thereafter:
// Pageprotection HACK A if ($protected && !$user['U_Username']) { if (!$postviews) { $postviews = 0; } $postviews++; $exptime = time() + 86400;// the cookie will expire in 24 hours $maxviews = 10;// this is the maximum number of views before login is required setcookie("postviews","$postviews",$exptime,"{$config['cookiepath']}"); } // Pageprotection HACK ende
// Pageprotection HACK B if ($protected && !$user['U_Username']) { if ($postviews > $maxviews) { // no loitering include("$thispath/templates/$tempstyle/ubbt_no_loitering.tmpl"); $this -> send_footer(); exit; } } // Pageprotection HACK ende
The hack is inside the Send Header code of threads. Obviously at a time where a header has been sent already. That is needed for the includes. But is conflicting with the sendcookie that has to be placed BEFORE any HTML.
Now, that it works, I added features to Daves wonderful hack:
* Language redirection: individual ubbt_no_loitering pages per language * display ot a message in the not-registered menu: nn more free actions today, without beeing registered. * Locking for special forums de-activated (I run a forum: INFO FOR GUESTS with a message "Why should I register" thatI want people to see) * Cookie set back after a succesful login, so that a registered user can surf unregistered for a while again
Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.
Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.