[pmwiki-devel] database tools and hacks in PmWiki
gmane at auxbuss.com
Sun Dec 10 12:13:59 CST 2006
> ... on the "database library" that you thought I was building: I
> will be working on a couple add-ins for AuthUserDBase (admin panel &
> group management too!). I think keeping users' private information in
> a database is pretty important, but I LOVE the PmWiki flat-file
> system for many reasons. So I will be sticking with flat-file as
> much as I can in my recipes, even though I look forward to seeing
> other people's wonderful database recipes.
Just to be clear, I'm certainly only working on db access via PmWiki and
nothing else. I agree with what you say. My need is driven by the fact
that most folk I deal with have dbs already, and the last thing anyone
would want to do is replicate that data.
Getting to that data and displaying it, and manipulating it is so easy
with PmWiki that it's simplifying a lot of functions I'm coming across.
I'm sure you know the type of thing: chunks of data embedded in
spreadsheets, or worse, in Access databases dotted all over the place.
> I have thought through the product/service end of the shopping cart,
> but not the order storage end. Storing credit card/bank information
> in flat files is absolutely out of the question for me
This isn't necessary. All the payment gateways I've used don't require
it and it's better to steer clear of the legal issues. Repeat payment
mechanisms are almost always available too. Even if you wanted to
collect CC info to pass through on a secure connection, there's no need
to store it.
> one reason I
> love PayPal from a liability/programming point of view -- absolutely
> no need to store financial information on the system.
Well, I loath PayPal - and enjoy a steady stream of work moving folk
away from them :-) - but collecting payment info prior to commencing the
payment transaction is not a requirement with any of the payment
gateways I've used.
> The moment the
> shopping cart system requires working with other merchant processing
> systems that require the shopping cart to handle sensitive financial
> information, we're entering very mucky territory in the way PmWiki
> handles data. You must store the customer's credit card in case of a
> product return, or needing to issue a credit, etc.
This isn't how it works, in my experience. The payment gateway provides
an interface that allows you to access the transaction and either refund
or make a part repayment. At no point do you need the credit card
> But you can't store it in a text file.
Why not? Technically, I mean, since I don't this either.
> You can't one-way encrypt it.
Not very useful.
> Do we use GPG? That doesn't work, because the web server would need
> access to the keys. It's a pain, and so far a database is the best
> answer I have.
You could store the key outside the web space and include the file.
More information about the pmwiki-devel