[pmwiki-users] Request input on soon-coming FAST Data release

[The Editor]

Hi Crisses.  Here is some responses to your last three emails...

> On this note, what about FastData's security?

> If you have FastData enabled on an open-edit wiki, general people can create forms that > do all sorts of weird things.  Suddenly your website is able to be used to mass-mail
> spam to people in complete violation of anti-spam laws.  Or someone uses your site to
> send sms spam messages to cell phones.  Or....

If you enable FAST Data on an open-edit wiki, you would have problems.
 However, as the doc's recommend you can only enable the engine on
pages where you have forms, or a form group, and then password protect
those pages from editing. This is the most basic level of protection.

You could always delete the email functions if you were not wanting to use them.

The recipe can be set with a password in the local config file, so it
will not process unless a password is entered.

The "data" action can also be protected to certain users, just like
any other action (read, edit, upload, etc.), using PmWiki's page
attributes.

With version 3.0 I plan to add a ban/approve list--to allow/disallow
form submission.

> Is there some way to limit the recipe to a passworded group?  Only allow the admin to
> authorize FastData to parse the forms? (similar to approve_sites -- approve_form)

Yes, see above.

> If I programmed a shopping cart app in FastData, and I had a group as an open blog area,
> what's stopping someone from writing scripts in Blog/SandBax that alter data pages (at
> Data-MyShoppingCart/Item10839) for changes in price info by creating a custom form to > over-write actual item information on a data page somewhere?

First don't enable the recipe in your blog group.  Optionally, use one
of the other methods to protect locations where forms are enabled.

On my site, absolutely nothing is open to editing.  I prefer to give
my users "magic boxes" using FAST Data, so they don't have to worry
about leading spaces or line returns not working right.  I can also
restrict them from including directives in their pages (including FAST
Data forms).  It's simpler for the users, and safer for me.

> In other words, once people understand how FastData works, how much are we opening > up said data & functionality to hackers?

With best practices used (as suggested above and recommended in the
docs) there is little risk.  As some have noted, however, there is the
possibility of crackers forging form headers.  I've been working with
Pm offlist to come up with a solution that should close that loop.  It
basically uses session cookies, passwords and random numbers to
authenticate that a form submission actually comes from the proper
form.  Hopefully this will solve that vulnerability.

> How much of this is going to be a burden to the admin during setup?

It works seemlessly.  Actually the new markup will require less key
strokes but be more secure.  An optional $DataLock passcode can be set
in the config file.

> I'm not particularly interested in cut & paste code -- I'm VERY interested in coming up
> with new recipes, using it to customize data.

Part of my goal is to help those like me who don't know PHP but want
to be able to do all kinds of interesting things.  This recipe should
make that possible.  For those who want to hack the code, or use it in
different ways, I want to make the code easy to modify.  For example,
if I had been paying attention, I should have suggested you put the
simile wrapper actually as a simple conditional in the engine itself.
It would have been easier for you and been more in harmony with my
original design goal of extensibility.  I guess I should have
explained how to do this.

> One nice thing about the way similepedia.com is using FASTData is that it's NOT being
> used to retrieve data from pages.  Only to create the data pages.  I have one form that
> uses it.  I can easily restrict editing on the form page, and have PmWiki ONLY load
> FASTData when loading the one page... then my security is done...

Yes, I wonder if I still even need data retrieval capabilities with
the new text variables.  Very powerful. Same thing, soon, with the
logging features (commenting).  As more and more stuff gets added to
core, less and less may be required of FAST Data.  Which may solve the
length problem a different way.

> To me "ZipData" sounds to me like a recipe that allows me to .zip the contents (data) of > a number of pages in the wiki (not a bad idea for a recipe anyway!).

> i.e. "this recipe will zip your data."

Actually, I'm leaning more toward zipforms or zip engine or zip form
engine.  The data storage and retrieval may have been the initial
motivation behind the recipe, but it now involves much more than just
data. So I need something a bit more generic to forms.  This might
help clarify it's not a data zipper.

> Another thing that's important to keep in mind:  Namespace.  I've been trying to keep the > vast bulk of my (newer) cookbook recipes within a function or class.  The problem is that > every time you create a variable you risk bumping into conflicts between your variable
> name(s) and those of other recipes.  This also goes for function names.

Can you explain what you mean by classes?  I don't think you can
define functions within functions can you?  And to have values passed
between functions you pretty much need globals, unless you pass them
as function paramaters.  Is there much advantage to one or the other?

> The function name "Data" is not a good function name, I have to say.  If you kept
> "FASTData" and prefixed all your (global scope) variables and function names with "FD_" > then it would be much safer.  So another suggestion is to change scope even if you then > require a global statement to pull info in &/or rename global functions and variables to
> have ZD if you do name it ZipData -- or whatever.  It lessens the chance of conflict with
> other recipes.

> AuthUserDBase is using AUD_Function() and $AUDBase_Variable (etc) and when I
> wrote my extension, one reason I used XES in the name is because I am using XES in
> the actual program to be pretty darned sure I'm not going to conflict with other recipes or
> PmWiki's core variables/functions.

Good idea.  I'll try and rename at least most of the key global
variables as part of the 3.0 release.

> Once your function is defined, your namespace is local instead of global.  The same
> goes for objects/classes.  Much safer in a shared programming environment.

Again, I don't really know what you mean by namespace, though I've
heard the expression before.  Help?

> A good example of code that should be in an included file for your recipe is the
> FastData->Database functions.  I also highly recommend that you follow the discussion
> of encouraging cookbook cooks to use adodb instead of writing code for a single type of
> database.  In any case, not everyone is using a database, and the code may be pretty
> long.  If they don't have adodb called before your recipe, your recipe might even break
> because your database functions are calling on functions / classes that are not defined.
> If it's in an include, you can check that adodb was loaded AND that the code is needed
> before loading the database functionality.  That could save another 500 lines of code from
> being called.  ;)

I'm still chewing on whether I want to split up the recipe into
modules or keep it all together.  Haven't come to a conclusion yet.  I
tend to think the easiest is having those concerned about performance
simply delete any functions they don't need.  Perhaps a bit of help
explaining how to do this could be helpful.  ie, which functions are
required for which features.


Cheers,
Caveman