http://dfaddons.com/ dfaddons en-us Wed, 25 Aug 2010 01:40:32 GMT 1440 CPG-Nuke Dragonfly dfa http://backend.userland.com/rss http://dfaddons.com/images/dfaddons.png http://dfaddons.com/ http://dfaddons.com/ForumsPro/viewtopic/p=198.html#198 Themes are ready to roll, there might be some minor detail that needs to be fixed. Other than that the theme are good to go. Wed, 25 Aug 2010 01:40:32 GMT http://dfaddons.com/ForumsPro/viewtopic/p=198.html#198 http://dfaddons.com/ForumsPro/viewtopic/p=197.html#197 LOL! Bring back old memories. Oh well. I hope we do not go that route again. Wed, 25 Aug 2010 01:37:36 GMT http://dfaddons.com/ForumsPro/viewtopic/p=197.html#197 http://dfaddons.com/ForumsPro/viewtopic/p=147.html#147 Always interested in alternative things, and time perception and the hyperchroniacs is one of them, anyone seen ravenous? 6/24/10 P-1 Webbot Clif High on Rense Radio Here is an interview and the entire show is available via mp3 audio and recommended for your listening enjoyment, if you have not heard yet, and/or you know about the web bot project and the research being done and how! [youtube]-XD0z-de2i4[/youtube] Tue, 06 Jul 2010 12:43:33 GMT http://dfaddons.com/ForumsPro/viewtopic/p=147.html#147 http://dfaddons.com/ForumsPro/viewtopic/p=110.html#110 try and see, it does not cause problems with the default forum and you can import that forum threads and posts into fpro. try it out and look at the configuration and you will see the enhanced options..just make it admin only and do not import anything at first, and keep it in a test mode for you and if you decided to go with it, then uninstall resinstall and import data from forums... Thu, 01 Jul 2010 11:40:54 GMT http://dfaddons.com/ForumsPro/viewtopic/p=110.html#110 http://dfaddons.com/ForumsPro/viewtopic/p=94.html#94 It, like almost all others is a work in progress, working on getting projects established more, so everyone and anyone can be more pro-active in them and their status, etc., This package containts 20 Languages (Basic) for many versions of DF, Please back up current language, directory, before installing. These are unzipped and compiled structure combined and then compressed back and ready for you to download and upload to your DF install, Estimated time: Download/Upload = 1 hr +/- If you notice any issues, please let us know! read more. Wed, 30 Jun 2010 14:43:11 GMT http://dfaddons.com/ForumsPro/viewtopic/p=94.html#94 http://dfaddons.com/ForumsPro/viewtopic/p=88.html#88 Porting Applications http://dragonflycms.org/Wiki/id=87.html Section 1: Database Queries Database queries are the heart of just about every application written for a CMS such as CPG Dragonfly CMS™, therefore they come first. SECURITY: Some applications will run without converting queries to the abstraction layer, however the abstraction layer adds a level of protection, error reporting, and debugging that is essential to the workings and security of CPG Dragonfly CMS™. Not converting queries is *NOT* an option when porting an app to DragonflyCMS™. Over the years, methods for accessing data in a database has changed drastically. Therefore, if the module you are porting is not kept current with current coding practices, this is where you will spend most of your time. CPG Dragonfly CMS™ uses the "database abstraction layer" method for querying the database, so every query must be converted to this newer method if it is not already coded that way. Other methods of querying data that you will more than likely see are what I will call the "mysql API call method" and the "DBI sql layer method." Conversions for these will be outlined below: Converting MySQL API Calls to the Database Abstraction Layer: Consider the following bit of code: PHP: mysql_connect("localhost", "mysql_user", "mysql_password") or die("Could not connect: " . mysql_error()); mysql_select_db("mydb"); $result = mysql_query("SELECT id, name FROM mytable"); while ($row = mysql_fetch_array($result, MYSQL_NUM)) { printf("ID: %s Name: %s", $row[0], $row[1]); } mysql_free_result($result); Now we see it rewritten using the abstraction layer: PHP: global $db; // $db is the abstraction layer access object. $result = $db->sql_query("SELECT id, name FROM mytable"); while ($row = $db->sql_fetchrow($result)) { printf("ID: %s Name: %s", $row['id'], $row['name']); } $db->sql_freeresult($result); For starters, we removed the mysql_connect() and mysql_select_db() calls as they are not needed when using the abstraction layer. After that, we give our application access to $db, the abstraction layer database access object. Since this object is in the global scope of the program, you will need to declare it global *IF* you are accessing it from within a function. Next, we converted the query to the $db->sql_query() format. This is fairly straight-forward. Notice how when we converted mysql_fetch_array() to $db->sql_fetchrow(), we only pass the $result parameter to $db->sql_fetchrow. The abstraction layer handles the rest for us. Finally, we converted mysql_free_result() to $db->sql_freeresult(). It's good coding practice to free the results once you are done as it returns resources temporarily used by the database query back to the operating system. Many applications you see will *NOT* free results. This is simply poor coding practices and should be corrected while porting apps to CPG Dragonfly CMS™. Converting DBI SQL Layer calls to the Database Abstraction Layer: Take a look at this code: PHP: global $dbi; $sql = "select com_id, userid, date, comments, score from ". $prefix."_MReviews_comments where rid='$rid' ORDER BY date DESC"; $result = sql_query($sql, $dbi); while(list($com_id, $uname, $date, $comments, $score) = sql_fetch_row($result, $dbi)) { echo "on $date, $uname left the comment $comments\n"; } Now see it rewritten using the abstraction layer and cleaned up a bit: PHP: global $db; // $db is the abstraction layer access object. $sql = "SELECT com_id, userid, date, comments, score FROM ". $prefix."_MReviews_comments WHERE rid='$rid' ORDER BY date DESC"; $result = $db->sql_query($sql); while ($row = $db->sql_fetchrow($result)) { $com_id = $row['com_id']; $uname = $row['uname']; $date = $row['date']; $comments = $row['comments']; echo "on $date, $uname left the comment $comments\n"; } $db->sql_freeresult($result); To convert this block of code, we started out by removing the global $dbi declaration and replaced it with $db. This gives us access to the $db abstraction layer object. Next, we cleaned up the query a bit by using upper-case letters for all SQL language directives used in our query. This makes the query easy to read as it is very easy to differentiate between SQL STATEMENTS and variables. We then converted the sql_query() call to $db->sql_query(). Notice how we removed the $dbi as the second parameter to the query. This is important as DragonflyCMS™ uses additional parameters passed with the query for debugging purposes. Now is where the fun begins. The original loop around the call to sql_fetchrow() reads (in english) something like "while you are getting a record from the database, please take the array returned by the sql_query call and use it to define these 4 variables: $com_id, $uname, $date, $comments." SECURITY: This works well in practice, however the more secure method of doing this is to always use "$row = $db->sql_fetchrow($result)" as seen in the rewrite. If, for some odd reason the query is able to be altered and alternate data is retrieved from the database, and attacker could easily use the list($variables) access method to retrieve information from your database and display it on the screen (or in the email, or whatever). Next, you will see that we add our own variable assignments from the $row[] array that is returned by the call to $db->sql_fetchrow(). Alternately, those lines could be removed and the echo statement could be changed to read: PHP: echo "on ".$row['date'].",".$row['uname']." left the comment ".$row['comments']."\n"; Either method is acceptable and is generally left up to the preference of the programmer. Database Conclusion: Now that we've seen the two most common methods of database access converted to the abstraction layer, here is a table that shows various commands under the different methods and how they would look using the abstraction layer: Code: +----------------------------------------------------------------------------+ | MySQL API Method | $db abstraction layer method | +----------------------------------------------------------------------------+ | mysql_query($sql) | $db->sql_query($sql) | | mysql_fetch_array($res, TYPE) | $db->sql_fetchrow($res) | | mysql_fetch_assoc($res) | $db->sql_fetchrow($res) | | mysql_numrows($res) | $db->sql_numrows($res) | | mysql_affected_rows($res) | $db->sql_affectedrows($res) | | mysql_num_fields($res) | $db->sql_numfields($res) | | mysql_field_name($res, $index) | $db->sql_fieldname($index, $res) | | mysql_field_type($res, $index) | $db->sql_fieldtype($index, $res) | | mysql_fetch_rowset($res) | $db->sql_fetchrowset($res) | | mysql_fetch_field($res, $index)| $db->sql_fetchfield($index, $rownum, $res)| | mysql_data_seek($res, $rownum) | $db->sql_rowseek($rownum, $res) | | mysql_insert_id($res) | $db->sql_nextid($res) | | mysql_free_result($res) | $db->sql_freeresult($res) | | mysql_error($res) | $db->sql_error($res) | | mysql_connect() | un-needed | | mysql_select_db() | un-needed | +----------------------------------------------------------------------------+ +----------------------------------------------------------------------------+ | DBI Layer Method | $db abstraction layer method | +----------------------------------------------------------------------------+ | sql_query($sql, $dbi) | $db->sql_fetchrow($sql) | | sql_num_rows($res) | $db->sql_numrows($res) | | sql_fetch_row($res) | $db->sql_fetchrow($res) | | sql_fetch_array($res) | $db->sql_fetchrow($res) | | sql_fetch_object($res) | $db->sql_fetchrow($res) | | sql_free_result($res) | $db->sql_freeresult($res) | +----------------------------------------------------------------------------+ As you can see, the $db method not only offers better security and debugging features, it is also more flexible than the DBI sql layer. Section 2: index.php, modules.php and admin.php vs getlink() and adminlink(). In CPG Dragonfly CMS™, the various entry points for your website are configurable via the $adminindex and $mainindex variables in config.php. Additionally, modules.php is no longer used. DragonflyCMS™ accomplishes this via two functions: adminlink() and getlink(). When porting an application, you should convert all references to "admin.php", "index.php", and "modules.php" to their CPG Dragonfly CMS™ function equivalents. getlink() is a function that returns the path to the main entry point of the website, usually "index.php". And since all "modules.php" traffic is now routed through "index.php", you use getlink() for that also. adminlink() returns the path and filename to your administration menu, traditionally "admin.php". By converting links to their functional counterparts, you are ensuring that your newly ported module will work properly under all configurations. These two link functions also accept additional arguments to be passed to the URL as a parameter. Some examples of link conversions follow: Code: Before: echo "<a href=\"index.php\">Return</a> to the main page.<br>"; After: echo "<a href=\"" . getlink() . \">Return</a> to the main page.<br>"; Before: echo "<a href=\"admin.php\">Return</a> to the admin section.<br />"; After: echo "<a href=\"" . adminlink() . \">Return</a> to the admin section.<br />"; Before: echo "<a href=\"modules.php?name=Your_Account&op=userinfo\">Your Account</a><br />"; After: echo "<a href=\"".getlink("Your_Account&op=userinfo)."\">Your Account</a><br />"; That last one requires a bit of explaining. As we noticed before, we used getlink() to direct the user at what is traditionally "index.php". Here we used the same function for "modules.php". Why? Because "modules.php" was removed from CPG Dragonfly CMS™ and all access passes though "index.php" now. Additionally, you'll note that there is no "name=" added to the extra URL parameters. That is correct as getlink() figures out what you are doing and silently prepends the "name=" parameter to the URL. Lastly, you'll notice that the "&" symbol was replaced with "&a mp;" (spaced so it won't parse). This is to ensure that your application creates HTML 4.01 Transitional compliant output. How about a more complex example (mixed HTML and PHP code)? Code: Before: <html><head>welcome to <?php echo $sitename; ?> </head></title> <a href="index.php">click here for them main page</a> After: <html><head>welcome to <?php echo $sitename; ?> </head></title> <a href="<?php echo getlink(); ?>">click here for them main page</a> While it may not be proper HTML coding, it works. There is no reason not to use getlink() and adminlink() in your code! Using getlink() and adminlink() instead of their hard-coded counterparts ensures that your port will continue to work as additional changes are made to the CPG Dragonfly CMS™ core system. These functions are located in "linking.php" in the CPG Dragonfly CMS™ /includes/functions/ folder. Since CPG Dragonfly CMS™ gives you the option to use LEO (Link Engine Optimization), the use of getlink() and adminlink() will also properly convert your links to either method (LEO or non-LEO links), without having to think about whether or not you're using LEO. LEO converts URL's into search engine friendly link, using .html extensions, rather than .php. Examples of LEO and non-LEO links are below. Code: Standard link: yoursite.tld/index.php?name=Forums LEO link: yoursite.tld/Forums.html Section 3: How to Make a CPG Dragonfly CMS™ Auto-Installer The modules section of the admin panel in CPG-Nuke has the option to automatically set up an installed module. This removes a lot of the frustration involved in installing a module and instead, turns it into a "click to install" process. To accomplish this feature, CPG Dragonfly CMS™ uses an installation file called "cpg_inst.php" that is located in the modules' main folder. For example: modules/MyApp/cpg_inst.php. A few things are necessary for Dragonfly to "see" this file. 1) an index.php file must also be present in the directory. 2) the directory for "MyApp" must be identical to the class/function in wording (see below for further explanation). A trimmed down version of a cpg_inst.php file is this: PHP: ###################################################### # File to install MyApp module # This file is called automatically by Admin->Modules ###################################################### if (!defined('ADMIN_MOD_INSTALL')) { exit; } class MyApp { var $radmin; var $version; var $modname; var $description; var $author; var $website; var $prefix; var $dbtables; // class constructor function MyApp() { $this->radmin = true; $this->version = '2.0.0.0'; $this->modname = 'MyApp'; $this->description = 'Use the MyApp Module (it was ported properly!)'; $this->author = 'AUTHOR_NAME'; $this->website = 'AUTHOR_SITE'; $this->prefix = strtolower(basename(dirname(__FILE__))); $this->dbtables = array('myapp_data'); } // module installer function install() { global $installer; $installer->add_query('CREATE', $this->prefix.'_myapp_data', " pid int(10) NOT NULL auto_increment, title varchar(64) NOT NULL default '0', PRIMARY KEY (pid)", ''); $installer->add_query('INSERT', $this->prefix.'_myapp_data', '1, "My Title"'); return true; } // module uninstaller function uninstall() { global $installer; $installer->add_query('DROP', $this->prefix.'_myapp_data'); } ?> The cpg_inst.php is actually a class containing three things: A description of the module, an install function, and an uninstall function. The $prefix is used to make it easier to have multiple instances of one module (if necessary). Your tablenames will have the module folder name (lowercase) as a prefix (e.g. "cms_modulefoldername_table2"). The $description is used to identify your module on the modules administration panel before it is installed. And guess what? The install and uninstall function perform the needed steps to install and uninstall the module. The $dbtables simply informs the backup system which tables are associated with this module. One thing is *very* important in this file. You'll notice that there are two statements, "class MyApp{}" and "function MyApp{}". Both of these statements should be changed to reflect your application's name. Also, remember that the directory name for your application should also be identical as well for Dragonfly to "see" the cpg_inst.php file. Generally, the installation process for a module will include creating some database tables and seeding them with some basic data. Traditionally, this would be handled by an ".sql" file that the user would need to use to manually update their database tables. DragonflyCMS™ allows this to be handled by the install process in the cpg_inst.php file and reduce the number of problems associated with end users not knowing how to manually run a database query. Section 4: File Locations, File Locations, and File Locations In CPG Dragonfly CMS™, the directories are protected so that direct access to executable (.php) files is not allowed outside of certain directories. If you're porting a module, you should know that modules/ is one of those directories. This basically means that at no point are you allowed to point a URL at the modules directory to run an application. For example, the URL: localhost/modules/MyApp/print.php?id=12 is not allowed. The CPG Dragonfly CMS™ Security Module does not and will not allow for it. It's a security thing and you're just going to need to deal with it as best you can. This is especially important as a feature of PHP-Nuke (not DragonflyCMS™!) is to include a file called "copyright.php" in each module's directory that will create a link on the modules' page to a copyright notice. Remember that if you are porting a document, you must leave the existing copyrights in place! In a pinch, you could simply add a link in the app you are porting to the URL listed above (http://.../modules.php?name=copyright) and you should be in good shape. 13.13.2: Part Two of Porting Applications Section 5: Cookies and Users It's common practice in PHP-Nuke modules to use the $cookie[] array to retrieve information about the currently logged in user. In DragonflyCMS™, this has been replaced with a very helpful variable: $userinfo[] (array). $userinfo[] contains the information from the user's entry in the cms_users database table. In many PHP-Nuke apps, the $cookie[] variable is first decoded to get the user's name, then a database query is run to extract information from the database on that user. Relax. It's already taken care of with $userinfo[]. Any field in the _users table is available in the $userinfo[] array. For Example: PHP: function getyourdetails() { global $cookie; cookiedecode($user); $name = $cookie[1]; $result = sql_query("select uid, name from ".$user_prefix."_users where uname='$check'", $dbi); list ($uid, $username) = sql_fetchrow($result, $dbi); echo "Your nick is $name, your user id is $uid and your name is $username\n"; } We would re-write that as follows: PHP: global $userinfo; // needs to be declared global if inside a function. echo "Your nick is " . $userinfo['name'] . ", your user id is " . $userinfo['user_id'] . ", and your name is " . $userinfo['username'] . "\n"; That's correct. No cookie decoding, no database queries... You just use the data as it is supplied to you. Simple, huh? There should be no need to touch the $user or $admin cookies in DragonflyCMS™ unless you ABSOLUTELY know what you are doing. Section 6: Basic Security Precautions One of CPG Dragonfly CMS™'s major advantages over other CMS's is security. Since you will be inserting what is probably someone else's code into someone else's website, this should be high up on your priorities list also. Some of the biggest avoidable security issues in CMS's today are: * SQL Injection. * Cross site scripting. * Full path disclosure. * Direct file access SQL Injection SQL Injection is relatively easy to avoid. You simply check all of your variables before inserting the into an SQL statement. To accomplish this, you simply need to know the type of data in the database fields and where that data is coming from in the application you are porting. Imagine a table with two fields, "pid" and "title". "pid" is a field of integer type, and "title" is of character type (char, varchar, text, etc...) Now we have a simple piece of SQL query: PHP: function get_title($pid, $title) { global $db; $sql = "SELECT title " . "FROM cms.MyApp_data " . "WHERE pid = $pid OR title='$title'"; $db->sql_query($sql); $row = $db->sql_fetchrow($result); return $row['title']; } What do we do here? Well, we know that pid is an integer value, so we should make sure that it is. Or perhaps die trying. We also know that title is a character value, so we need to make sure that it has all of it's quotes (" or ') properly "slashed" before it goes into the query. CPG Dragonfly CMS™ has a nice function for the latter of the two called "Fix_Quotes()". When invoked with one parameter, Fix_Quotes() will check to see if the current PHP environment has the setting "gpc_magic_quotes" set to "on." If it doesn't, it will "slash" the variable that it is passed for you. This is because when gpc_magic_quotes in "on", PHP will automagically slash quotes in variables coming from HTTP_GET, HTTP_POST, and HTTP_COOKIE variables. If you are *sure* that the variable is coming straight from a web page request into your query, you should run Fix_Quotes($variable); on that variable to assure proper quote handling. If you are unsure, or there is a possibility that the variable may be coming from several sources, you can always use the PHP function addslashes() and stripslashes(). We change the code to: PHP: function get_title($pid, $title) { global $db; $pid = intval($pid); // assure that $pid is an integer. // if (!is_numeric($pid)) { // die ("invalid pid parameter specified!"); // } $title = Fix_Quotes($title); // $title = addslashes(stripslashes($title)); // alternately, we could do this. $sql = "SELECT title ". "FROM cms.MyApp_data ". "WHERE pid = $pid AND title = '$title'"; $db->sql_query($sql); $row = $db->sql_fetchrow($result); return $title; } That's much better. We can either force $pid to be an integer with "$pid = intval($pid);" or check to see if it's an integer and scream bloody murder if it is not using the "if (!is_numeric($pid)) {" code. For the character variables, we chose to use Fix_Quotes() on the $title variable since we're sure that by the time we see $title in the function, it hasn't been changed elsewhere in the program. If we weren't sure, or just completely paranoid, we could do the slash-twins on the variable, but that would add extra overhead to the program that Fix_Quotes() does not. Cross-Site Scripting (XSS) Cross Site Scripting, or XSS, is essentially finding ways to inject HTML, Javascript, or whatever code into someone else's web browser. It's as simple as that. The fix is nearly as simple. In CPG Dragonfly CMS™, we have the function Fix_Quotes(). It actually accepts more than one parameter, the second of which is good for preventing XSS code from getting injected into your application. Imagine this micro module, called "Quote": PHP: <?php // the never ending quote application function addquote() { global $quote, $db; $db->sql_query("INSERT INTO ".$prefix."myquotes VALUES (0, '$quote')"); echo "your quote is in the database, thanks!<br>"; } function display_quote($id) { global $db; $id = intval($id); // we're not THAT stupid. $db->sql_query("SELECT quote FROM ".$prefix."_myquotes WHERE id = $id"); echo "Your quote is '" . $quote . "'<br>"; echo "Click <a href=\"" . getlink('&id='.$id+1) . "\">here</a> for the next.\n"; } switch ($op) { case "display": display_quote($id); break; case "add": add_quote(); break; }; In the quote_add() function, we are blindly adding the $quote variable both into an SQL query as well as the database itself. In the quote_display() function, we also simply toss the contents of the variable into the user's web browser. This is how XSS happens. To remedy this, we will use the Fix_Quotes() function again and change the add_quote() function to read: PHP: function addquote() { global $quote, $db; Fix_Quotes($quote, 1); $db->sql_query("INSERT INTO ".$prefix.:"myquotes VALUES (0, '$quote')"); echo "your quote is in the database, thanks!<br>"; } By adding the second parameter "1" to Fix_Quotes(), we are telling Fix_Quotes() that not only would we like variable slashed, we would also like to strip any HTML or PHP code. Fix_Quotes() does this using the strip_tags() function of PHP. Full Path Disclosure Full path disclosure, by itself, is not a security issue. However, allowing someone with evil intent to figure out where certain files reside on your web server can be used in conjunction with other attacks to open large security holes. Full path disclosure in PHP generally comes from warning errors. For example: Code: Warning: Division by zero in /home/www/html/tmp/foo.php on line 4 That would tell an attacker where on the server your web files are stored. Since it is quite easy to turn of error reporting in the configuration of PHP, this won't be covered much here. Simply, when debugging your ported app, run it with the "error_reporting(E_ALL);" function call and browse over the errors (chances are, there will be many). Silence those that you can. In the end, it is primarily the web developer's responsibility to make sure that error messages are not output to the users' screen on a production site. Direct File Access The problem with direct file access is exactly as it sounds -- letting people run PHP code on your website without first passing through the front doors (index.php or admin.php). In PHP-Nuke, this is generally accomplished with something similar to the following code at the top of each .php file: PHP: if (!eregi("modules.php", $_SERVER['PHP_SELF'])) die("Access Denied"); What that says (in english) is "if the current file being accessed when this chunk of PHP code is being run does not contain 'modules.php', then die." In practice, that almost works well. But there are ways around this that we will not discuss here. As a better security measure, DragonflyCMS™ defines some variables that may be checked to make sure that if a PHP file is getting executed, it's only being executed from within a proper section of the site, and definitely not being directly accessed. For example, we would re-code the above code snippet as: PHP: if (!defined("CPG_NUKE")) { exit; } You see, CPG_NUKE is defined() in includes/cmsinit.php. So... If your code is being executed and includes/cmsinit.php has not already been loaded, your code will halt execution. There is also another nice variable that is define()d when the administrator is working from the admin panel. That is ADMIN_PAGES. So... All of your adminstrator code should be protected like this: PHP: if (!defined("ADMIN_PAGES")) { exit; } Administrator code is generally located in the admin/modules folder. If the code you are porting is to be cross-ported (the same code running in DragonflyCMS™ as well as PHP-Nuke), this CAN be done without making your code DragonflyCMS™ specific. You would change the first piece of code to read like this: PHP: if (eregi("block-My_Block.php", $_SERVER['SCRIPT_NAME'])) die("Access Denied"); Notice we're using SCRIPT_NAME instead of PHP_SELF. We are basically saying "If the name of this file is in the full file/pathname of the script that is running, then die." This method is much more risky as a simple typo renders it useless (block-My_Block.php vs. block-My_Bolck.php). And just to "toot" DragonflyCMS's™ horn a bit, I should add that this is actually the second level of multi-tiered security against direct file access. On a properly installed and configured DragonflyCMS™ system, processing would never get this far. Section 7: Register Globals - Importing Data When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. CPG Dragonfly CMS™ runs with register_globals disabled. When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this. Let's demonstrate with an example misuse of register_globals: PHP: <?php // define $authorized = true only if user is authenticated if (authenticated_user()) { $authorized = true; } // Because we didn't first initialize $authorized as false, this might be // defined through register_globals, like from GET auth.php?authorized=1 // So, anyone can be seen as authenticated! if ($authorized) { include "/highly/sensitive/data.php"; } ?> When register_globals = on, our logic above may be compromised. When off, $authorized can't be set via request so it'll be fine. There is one caveat. By turning off register_globals, you can no longer access passed variables with their given name. They MUST be imported with either $_GET or $_POST, depending on where the data is coming from. $_GET is, generally, used with variables passed in links, while $_POST is used for variables coming from a posted form. For example, say we are trying to get data passed from a simple form. The old, PHP-Nuke way is to simply access the variables by their given name. PHP: // update the database with posted variables global $dbi, $prefix; $sql = "INSERT INTO ".$prefix."_mytable SET myphone='".$myphone."', myaddress='".$myaddress."', mybirthdate='".$mybirthdate."'"; $result = sql_query($sql, $dbi); With CPG Dragonfly CMS™ you must import these variables prior to using them, for reasons discussed above. We would rewrite the above as; PHP: // update the database with posted variables global $db, $prefix; $myphone = Fix_Quotes($_POST['myphone'], 1); $myaddress = Fix_Quotes($_POST['myaddress'], 1); $mybirthdate = Fix_Quotes($_POST['mybirthdate'], 1); $sql = "INSERT INTO ".$prefix."_mytable SET myphone='".$myphone."', myaddress='".$myaddress."', mybirthdate='".$mybirthdate."'"; $result = $db->sql_query($sql); $db->sql_freeresult($sql); Alternatively, you could re-write it like this, also mentioned above; PHP: // update the database with posted variables global $db, $prefix; $sql = "INSERT INTO ".$prefix."_mytable SET myphone='".Fix_Quotes($_POST['myphone'], 1)."', myaddress='".Fix_Quotes($_POST['myaddress' ], 1)."', mybirthdate='".Fix_Quotes($_POST['mybirthdate'], 1)."'"; $result = $db->sql_query($sql); $db->sql_freeresult($sql); The first method, in my opinion, is simply easier to read and work with. It is also easier to check whether these variables are set, before trying to assign them to another variable. For example, the routine could again be rewritten as; PHP: // update the database with posted variables global $db, $prefix; $myphone = isset($_POST['myphone']) ? Fix_Quotes($_POST['myphone'], 1) : ''; $myaddress = isset($_POST['myaddress']) ? Fix_Quotes($_POST['myaddress'], 1) : ''; $mybirthdate = isset($_POST['mybirthdate']) ? Fix_Quotes($_POST['mybirthdate'], 1) : ''; $sql = "INSERT INTO ".$prefix."_mytable SET myphone='".$myphone."', myaddress='".$myaddress."', mybirthdate='".$mybirthdate."'"; $result = $db->sql_query($sql); $db->sql_freeresult($sql); Basically, what this is saying (in English) is -- if the variable $_POST['myphone'] is set (contains data) THEN Fix_Quotes on the data in $_POST['myphone'] (and strip_tags) and assign it to $myphone, ELSE set $myphone to nothing (NULL). This also holds true to switches used within many modules. For example; PHP: switch($mode) { case "something": something (); break; case "somethingelse": somethingelse (); break; } With this code, $mode is never set, hence no function is called. The proper way would be; PHP: $mode = isset($_POST['mode']) ? $_POST['mode'] : 'something'; switch($mode) { case "something": something (); break; case "somethingelse": somethingelse (); break; } This is assuming that you have data being passed from a posted form. If you have a switch that will be used with both $_GET and $_POST, you could use the following; PHP: $mode = isset($_POST['mode']) ? $_POST['mode'] : (isset($_GET['mode']) ? $_GET['mode'] : 'something'); switch($mode) { case "something": something (); break; case "somethingelse": somethingelse (); break; } There are many ways to do this, above is just one example. Notice that I have chosen a default routine to run, if $mode is not set. You could also set a default case to run and set mode to empty if it is not set. PHP: $mode = isset($_POST['mode']) ? $_POST['mode'] : (isset($_GET['mode']) ? $_GET['mode'] : ''); switch($mode) { default: case "something": something (); break; case "somethingelse": somethingelse (); break; } References: Functions / special variables mentioned in this document and their source code/documentation: $userinfo[] - includes/cmsinit.inc getlink() - includes/functions/linking.php adminlink() - includes/functions/linking.php Fix_Quotes() - includes/cmsinit.inc addslashes() - www.php.net/manual/en/...lashes.php stripslashes() - www.php.net/manual/en/...lashes.php strip_tags() - www.php.net/manual/en/...p-tags.php Author: tuta Created: Saturday, November 05, 2005 (19:52:58) Last update: Thursday, November 17, 2005 (15:40:17) by tuta Mon, 28 Jun 2010 22:26:45 GMT http://dfaddons.com/ForumsPro/viewtopic/p=88.html#88