Using CMSBuilding Login
25 posts by 9 authors in: Forums > CMS Builder
Last Post: October 8, 2009 (RSS)
By andycal - August 20, 2009
Any help appreciated!
Re: [andycal] Using CMSBuilding Login
By gkornbluth - August 20, 2009 - edited: August 20, 2009
In the section access pulldown menu you can specify specific sections and restrict access that way.
If that's not what you're asking, let us know,
Best,
Jerry Kornbluth
Take advantage of a free 3 month trial subscription, only for CMSB users, at: http://www.thecmsbcookbook.com/trial.php
Re: [gkornbluth] Using CMSBuilding Login
By andycal - August 20, 2009
What I'm after is a way of knowing who my CMSB users are on none CMSB pages. For example, I have some pages on my site that are visible to all, but I want my CSMB admins to be able to view certain sections that are hidden from the general public.
Re: [andycal] Using CMSBuilding Login
1) Don't provide any public links to the versions of those pages with the private data.
2) Password protect the folder with those pages if you need the added security.
You can use a free password management program like Account Manager Lite by Site Interactive or just use .htaccess files.
Does that help at all?
Best,
Jerry Kornbluth
Take advantage of a free 3 month trial subscription, only for CMSB users, at: http://www.thecmsbcookbook.com/trial.php
Re: [gkornbluth] Using CMSBuilding Login
By InHouse - August 20, 2009
Basically this is the same method that Dreamweaver users by default in these cases.
J.
Re: [InHouse] Using CMSBuilding Login
Jerry Kornbluth
Take advantage of a free 3 month trial subscription, only for CMSB users, at: http://www.thecmsbcookbook.com/trial.php
Re: [gkornbluth] Using CMSBuilding Login
By InHouse - August 20, 2009
1 - Created a mulit-record table in CMSB called 'Subscribers'. Contains user info, password, contacts, and permission data. In my case the latter was a drop-down menu containing user level types. My client wanted to have viewers only see certain data so this table also had extra permission fields. i.e.: red stuff, blue stuff, green stuff.
2 - The client was signing up users manually, but you could have a sign-up form which populates that table. Moderator oversight may be required.
3 - On the login page. The user would enter their username and password. These are checked against the user table. If their account is in good standing, create session vars based on some kind of temp hash of their username and/or system time (or similar).
4 - On each subsequent page, at load, check the session vars and see if their reversed-hash info matches the valid account info from the CMSB table. If not, bounce the user back to page 1. If valid, read their data viewing permissions and display the content accordingly (i.e.: red stuff, blue stuff, green stuff,etc.). Users with certain levels of permission such as Admins or Mods might see multiple sets of data.
5 - For some critical bits of content, or with certain user actions, we send emails or append to a flat file log of what user took a given action. That way we know if they downloaded a given file or went to a particular page.
It must be noted that this site was just intended for non-commercial actions as this method is far from foolproof. But it does allow one to know which of your users came to your site, what pages they viewed, and permit you to show the right data to the right groups of users provided that none of them know enough about how to spoof the session vars or some of the page headers. Security is relative.
This site was originally built on CMSB 1.20 and I'm sure we might approach some things a little differently now.
Hope this helps!
J.
Re: [InHouse] Using CMSBuilding Login
By andycal - August 20, 2009
Re: [andycal] Using CMSBuilding Login
By InHouse - August 20, 2009
Back when I did this, and perhaps even now, I wasn't able to add extra fields to the user table on CMSB. Neccessity begat invention.
J.
Re: [andycal] Using CMSBuilding Login
By Dave - August 20, 2009
This isn't something that's supported by the software, but I'll try and point you in the right direction. We switched from cookies to sessions in a recent version, so upgrade if you haven't already.
Next, add this line in red before you load the viewer functions:
if (!defined('START_SESSION')) { define('START_SESSION', true); }
require_once "../lib/viewer_functions.php";
That tells it to start a session. Next, you can display an error message for users who are not logged in like this:
<?php if (!@$_SESSION['username']) { die("You must login first!"); } ?>
And you can see all the session variables available like this:
<xmp><?php print_r( $_SESSION ) ?></xmp>
Note that the program internals might change over time. Probably not for a long while, but be sure to test your custom code after future upgrades.
Hope that helps!
interactivetools.com