[pmwiki-users] shopping cart cookbook - oscommerce vs PmWiki

[Crisses]

On Sep 20, 2006, at 12:28 PM, Ben Wilson wrote:

> The advantage of the wiki page approach is the ease of integrating a
> client's web site theme with the data. My biggest complaint with most
> CMS-type products is the impossible to manage theme. This is usually
> because the design either calls for too many templates or CSS markup.
> For example, I've tinkered with Vanilla Forum, but just changing the
> colors can be a royal pain. Contrast those with PmWiki's Incredibly
> Friendly Skin Format (IFSF).

It's not that it can't be done.  It's that people don't do it right.

If you work correctly with Smarty templating, for example, code is  
distinctly separated from template.  I'm trying to remember which  
projects used Smarty templating.  I'm using it in my own OSS software  
now.

Blogger also got it right -- skinning Blogger is an absolute dream.

So while PmWiki certainly raised the bar for me on how templating  
SHOULD be done, it doesn't mean that no one else has it right.

>> I'm almost done with my mysql authentication extension for PmWiki.
>
> As opposed to my mySQL authentication extension? Hmm, that was one of
> the Mini Summer of Code projects that didn't get finished. That is,
> there is something out there, but not entirely user friendly.

Before I started I asked the list if anyone had something that does  
what I needed.  I took the AuthUserDBase recipe and made a version  
that is stand-alone.  AuthUserDBase is great for single-sign-on with  
an established system, but has no user-sign-up features, no  
validation email authentication, etc.  I added all that in.  People  
can forget passwords, re-sign up, change their password and email  
address, etc.

It's done.  I can't show off the wiki it's on yet but I'll be  
uploading it to the cookbook very soon.  Once the wiki is done, I can  
show it off but in the meantime I may have to put up a wiki for  
demoing it.  Maybe I'll dust off my "crissbio" wiki, since user  
authentication FINALLY handles what I needed to have the tiered  
authentication I wanted wAAAAAAy back when...

One question on that though: Can AuthUser handle groups as members of  
other groups?  It would make life SO much easier.  I'll look it up.

> I put my wiki.d outside the web directory. So, while the directory
> permissions are wide open, they are harder to access. Additionally, I
> have a cron that keeps files 666. In an ecommerce context, I would
> think security demands moving wiki.d out of the web directory.
> Anything less in this day-and-age is tantamount to reckless behavior
> (i.e. knew the risk but ignored it).

666 will not stop someone who has legitimate business on your server  
from illegitimately trasversing your user directories.  I wasn't  
talking about the risk of accessibility of files to the web, but of  
files to your fellow-server-users in this day and age where some  
people are running on shared hosting servers.

Many hosting services expel people who do such things.  Some people  
aren't afraid of expulsion.

> The
> pain ends in December.

The best of luck!!

>> If the variable is stored IN the page text see note above about 777
>> permissions.
>
> Agreed, which is why I recommend moving wiki.d out and croning page
> permissions to 666. For what it's worth, I had a PmWiki running with a
> named PHP calendar program on a web server that had a non-hardened
> kernel. That site was hacked---because of the calendar program. Pm is
> pretty hard-core about fixing security issues as he becomes aware of
> them.

As long as the files are in a directory that people can get in --  
required for the webserver to find the files -- people can find your  
directory and look at your text.  Just not directly via the web.   
They can do it indirectly via the same web server you use, or by FTP  
change directories until they're in your directory.  (Chrooted users  
being an exception, but I've seen webhosts NOT set up CHROOTed.)

>> While not everyone has MySQL or other databases, there is a good
>> reason for them, especially in these contexts.  On a shared hosting
>> server you can't have files in the directory that are readable/
>> writable ONLY by the webserver or you can't clean your own webfiles.
>> You can't add yourself to the webserver group (which I do on my own
>> servers so I can 770 or 660...)
>
> I'm not saying _don't_ go mySQL, but as PmWiki is file-based, it would
> be nice to have an ecommerce recipe that fit in with file-base.

I never said to put the products in mysql.  Just the user info.

> When talking plaintext/cyphertext, we're talking a function of the web
> server, right? Again, I assume any ecommerce project would imploy SSL.

It's actually not really needed.  In the case of a service like  
PayPal, the user doesn't even need to log in to your site or give you  
shipping info -- PayPal can email that info to you when the order is  
completed. -- just match the order number to the invoice and shipping  
info.

> When talking user pages, isn't that also a matter of security? I mean,
> anybody could code an ecommerce mySQL project that allows customer
> 87623 to view customer 8675309 by changing the query string.

In theory, unless they check authentication for each transaction.

> It's when
> you add a checksum that says that only customer 8675309 (or an
> administrator) can view that customer's information that security is
> added.[1] We reach the same degree of security via PmWiki by setting
> the read, edit and admin variables of a page, and moving wiki.d out of
> the web directory. (Also, mySQL AuthUser to better manage hundreds of
> users.)

I didn't care as much about orders as customer info -- or customer  
info tagged to the order...for all those adult novelty stores that  
are certain to crop up out of PmWiki's shopping cart system ;)  (j/k)

> I once queried how to set it up so that group permissions are based on
> the user's name. Thus, user BenWilson could have a group BenWilson
> were page default permissions are restricted to him. Then, I could
> open up the wiki to my school's student body. It should be no small
> feat to do the same for a user.

That there FastData thing might work for something like this.   
Maybe.  That would be nice.

Actually maybe you can do it via config.php with something like  
(clean up as needed):

if (($Group != Site Main PmWiki (etc) ) && ($Author == $Group)) {
$DefaultPasswords['edit'] = "id=$Author";
} else {
$DefaultPasswords['edit'] = "@admins";
}
or does that open up a security problem.  Maybe preceeded by a if  
stating !Site !Main !PmWiki etc.


> [1]: Why is the ID 8675309? Think of the song . . . "Jenny, Jenny, who
> should I turn to? 8-6-7-5-3-0-nai-e-ain." Okay, maybe you only get it
> if you were in your teens or tweens in the early 80s.

I'm young enough to remember that.  Then again, my kids may even know  
it :P

Crisses


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20060920/3cff9094/attachment.html