On Sat, Feb 20, 2010 at 6:42 AM, Kevin <[email protected]> wrote: > The weather site using BW uses a lot of included PHP files to get it's > stuff. > > Up until this point, I've been creating plugins to do this for each section > that uses external scripts to obtain and display data, but this doesn't seem > to be a good way to do this. Especially down the road when other > non-programmer types start using it. > > I've been thinking about creating a plugin that allows the BW admin to > include PHP files directly, something along the lines of > > [(phpinclude php_page mode=0)] > > Where mode = 0 for no markup, and 1 (or not there) for BWWiki Markup. > > An example of how this would be used would be like on a page like: > > http://cumulus.tnetweather.com/forecast > > All of the forecast data actually comes from a self-maintained PHP script > that goes out, gets the forecast data, parses it and then displays it. It > even has it's own caching system. The output however, needs to be no markup > or it ends up looking terrible. > > Up to this point, I've created a plugin to do this for each included script > that I use (there are many). However, the plugin like in this case really > doesn't do much but call an external script and return what it got so that > it can be returned back to BW for display. > > http://cumulus.tnetweather.com/advforecast2.php > > Actually, it is not really called this way, as this way outputs HTML headers > and stuff... Instead it looks for a preset variable and outputs everything > but the headers when it is called. > > Basically, the plugin is doing (An example of using output buffering as > well): > > // Set Mode to 0 (Escape Mode) > $mode = 0; > > // Turn on output buffering > ob_start(); > > // Tell the script I want to have it output data > // This also tells the script to output the data without the HTML headers > $doIncludeNWS = true; > > // Include the script (which causes it to output its data > include("/...path_to_script.../advforecast2.php"); > > // Put output buffer into $result > $result = ob_get_contents(); > > // Turn off output buffering > ob_end_clean(); > > // If mode =1 return as is, otherwise return as escaped > if ($mode) { > return($result); > } else { > return BOLTescape($result); > } > > I keep hesitating doing this because of the possiblity that I would be > creating a security issue. > > However, I don't think that I am in the sense that when this is used, it > will be used only on a site where there is an admin, and no users, or at > least no users that allowed to create pages. If only the admin can create a > page and use the phpinclude plugin, there would really be no more of a > security issue than if the same admin uploaded any other PHP script to their > website. > > Just wondering if I am wandering into to trouble that I'm not seeing or if > what I plan on doing makes sense. > > Of course, if there is already a way to do this within BW, I'd be interested > in that as well. It wouldn't be the first time.
Sorry for not replying earlier. Just busy with things, as usual. :) But I think you are right--it should be safe so long as there are no useable editable pages. Including sandbox pages, comment boxes, even things like a title action--as you could put a function in any of those. Even a get field that gets posted somewhere that could be hacked into. Of course, you could limit where this plugin is used to specially protected pages, such as just one group of pages. You have to be careful, but if no one is editing anything it is probably ok. And in this case, I don't think this is something BoltWire can do. Probably a bit risky for a core feature! :) Cheers, Dan -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
