Thanks for the lengthy reply Pm, much appreciated. I posted a few comments below, but tried to keep it short, for everyone's sake.
On 6/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Fri, Jun 01, 2007 at 09:17:52AM -0400, The Editor wrote: > > > [...] Heck, it would > > > be more fun to write a program that would allow me to completely > > > overwrite your index.php at will with a user submitted post. [...] > > > > What you fail to mention however is that this line is never run unless > > there is also a POST field with the proper password value--a user > > defined password, stored on the server and fully encrypted. So yes, if > > some hacker could get that password, and they then forged a POST > > submission, they could get control of your wiki. But then again why > > bother forging a post if they have password? > > I think Ben's point is not that an attacker could get control of the > wiki, but rather that they could use this to get control of the > server. There's a vast difference between the two. Ok, I guess I still don't see how that could be done, but I'm likely missing something. I'll put some kind of pattern check on the post value to try and secure that line of attack. Just ordered a recommended book strictly on PHP security from Amazon. Hopefully it will point out other potential holes. > > Or better yet, since this thread really is supposed to be about > > PmWiki, why not answer ZAPwiki's conceptual challenges: > > Okay, I'll answer the "challenges". But I do have to point > out that I've already answered them _many times_ before. Yes, I know you answered some of them with me before. Still my hope was when others saw what could be done it might inspire more desire for it. It's one thing to talk about it hypothetically, another to see it working. > > 1. A simple script for auto installing farm fields. How many questions > > do we get about farm configuration issues? > > I've already answered this one, several times. If we have an > auto-install script of some sort, then how does it get executed? > If it's executed from a web browser, then any .php files it creates > will have to be owned and/or writable by the webserver account. > To me, that presents too many possible security vulnerabilities > for the server, and so I've rejected anything that opens the > possibility to webserver-writable PHP scripts, and I have made > this reason clear in the past. ZAPwiki doesn't present any new > concepts here that I haven't already covered, nor does it > answer the objections I've raised. Fair enough, I don't understand really anything how apache works so I'll have to take your word on this. But still, PmWiki could have a backup/extraction mechanism that could make it very easy to prepare pre-bundled wikis. And for the one config file PmWiki would need to write, couldn't the permissions could be reset once they are created. Or the ownership of it? Or is that not possible? > One alternative is to not use .php files for field configuration -- > i.e., make all configuration done by something other than PHP code. > While I've considered this in the past, and PmWiki uses non-PHP > files for configuring subsystems such as authuser, notify, intermap, > etc., I think it will always be the case that the flexibility > desired by site administrators and required by disparate PHP > environments will mean that there will always have to be _some_ > manual configuration performed. Agreed, there should be an option for that. But in ZAPwiki for example, there's very little need for that kind of configuration, or for skins, plugins, css, whatever, because that can all be done within the wiki on the fly. It's very simple structurally. > > 2) An optional, simpler page format? Ok, you addressed this one, but > > your point was a dud. > > I've already answered this one as well. My points aren't duds. No, Ben's point that there were special plugins that could simulate direct text editing was not very convincing, not your points. In fact, after my original idea of separating text from data, I came around to your view point they should be together on the page. > First, the ability to use a simpler page format is _already_ an > option in PmWiki -- simply come up with a recipe that provides > PageStore objects that have the layout you want. If it ever > becomes popular enough, it can become a candidate for the core. Unfortunately, I have no clue how to do this in PmWiki. But I definitely like the feature. > Second, I simply have a design preference that all text and > metadata (passwords, history, attributes) for a page be stored > in a single unit that can be easily moved from place to place. > I'm not a fan of designs where we have to be concerned with > keeping multiple files for the same object (page) in sync with each > other. Agreed. Byt my idea was these can be done more flexibly using admin defined data values rather than hardcoded attributes. ZAPwiki is actually not so different in that it stores data on the same page, but invisible in the source--(much like PmWiki's attributes). But because it's data driven, admin's decide what data they want to save right within the wiki and can change it instantly for any page they want. Full flexibility, and simpler code. I should note my timestamping system, the alternative to diffs, is stored elsewhere, but it works great in terms of undeletes, etc. Plus I get to decide when and where and by who, diffs get stored (actually full timestamped roll back versions). It's all controlled within the wiki. And my main read pages stay small--like 2-3 K instead of 20-30 K or much more. Not sure what the speed impact is but it's gotta save time to not have to load all that stuff up you don't need. > Lastly, it seems to me that the ability to edit files directly > on disk is of benefit primarily to the wiki administrator, or > people that have login/ftp privileges on the account. It doesn't > help the typical author (except for those environments where the > administrator _is_ the typical author, and likes to use text > editors on files). > > So, this feature is one that appears to have relatively low demand. > (I'll grant that people who really want this feature may be choosing > other wikis that provide it, such as Dokuwiki. Still, it doesn't > appear to be a make-or-break feature for PmWiki adoption.) Maybe so, but I find it quite valuable as an admin. And unlike Dokuwiki I keep the data with the page. So I can manually edit it as well, at the same time. > > 3) Moving skin control to within the wiki. > > I don't have a need for this -- as a skin designer I prefer > to be able to specify the HTML and CSS directly in files and > not have to go through wiki markup to do it. This would also > seem to require enabling HTML and CSS in wiki markup , or > providing wiki markup sequences for everything that one might > want to do in HTML and CSS. I'm not a fan of either. Actually, I do use straight html and css pages in ZAPwiki. No markup involved other than simple markups for things like insert page section here (zone). What I do is have a list of page types that are automatically "escaped", such as html or css. So when you create the page they display exactly as typed, and can be edited directly. Using a slightly different zone markup causes them to be imported without using the markup engine. So I can easily create a different skin for every group, or edit my styles right on the fly--easy. Only those with admin authority can edit these pages of course, otherwise the < char gets escaped and it invalidates the code. > Beyond that, I don't think there's anything in the current design > that would prevent someone from developing a skin that does > _all_ of its layout within the wiki. But as I said, I personally > don't need it, and I don't hear a large demand for it. I _do_ > hear frequent demands for being able to get very precise > skin control outside of what is typically possible in wiki > markup, or to integrate PmWiki with pre-existing templates > and sites that have their own skins. There's little demand, I suspect, because people haven't tried it. Once I began toying with it, I found it incredibly liberating. Add and drop zones wherever you want, full hierarchical powers (like Hg). It's incredible. Get a few souls to get a taste of what it's like, and there might be more demand for it in PmWiki. I can't imagine who wouldn't want it. > > 4) How about a real form processing engine in PmWiki and a way to use > > it instead of hardcoded site actions. Until you've toyed with this > > some you have no idea how liberating (and efficient) ZAPwiki's > > approach is. > > But, as we've amply demonstrated in the past, this also comes with > its fair share of security risks. And forms processing has never > been PmWiki's primary purpose, although that may change over time. > The PmForm module I'm working on is intended to provide forms > processing capability. However, I'm not looking to supplant what > we have now. > > By advocating a "real form processing engine" instead of "hardcoded > site actions", what you're really saying is that we should > discard an awful lot of existing infrastructure (core code and > recipes) upon which PmWiki has been built. That may be a valid > approach, but in the overall scheme of things I don't yet see > the benefits of that approach as significantly outweighing the > drawbacks. First of all, it's only partially true I'm advocating dismantling a lot of PmWiki infrastructure. It *would* make a lot of infrastructure completely unnecessary, but both could continue to be available. Not very efficient, but the required changes, if any, to PmWiki would be so minimal it would be a shame not to at least explore the possibilities a bit. It may even already be possible--I just don't know. I really envision it opening up tremendous avenues for PmWiki, and it needn't break a single site. I'd love to see it happen for PmWiki's sake. This is another real example of once you try it you fall in love with it. In fact this was the primary conceptual inspiration behind ZAPwiki. I discussed it with you months ago, when ZAP's potential began to dawn on me. But now it is working, and amazing. It's piddling code to have 30 or 40 or 50 powerful, fully customized site actions--running off a tiny wiki engine. I can instantly change every facet of how ZAPwiki works by simply editing a ZAP form. Forget the need for scores of different recipes to "work around" limitations in the core functionality. I just build what I want right in the wiki, and it can do about anything I can imagine. And it's easy... > I also know that many times in the past you've claimed that ZAP > is intended for "non-programmers", but really much of what ZAP has > done is simply introduce its own programming "language" and > constructs, which people must learn to write in before they can > use it. Or, they rely on other people to write the ZAP code, > but that's essentially the "recipe" approach that PmWiki uses. > Yes, the ZAP language may be somewhat simpler than PHP, Perl, Java, > or other traditional languages, but just because it isn't one > of those languages doesn't mean it's not "programming", or that > it's substantially more accessible to non-programmers for the > level of capability provided. Pm, you are exactly right. This is the precise issue. ZAP (and moreso, ZAPwiki) is really a scripting language. It's not a plugin. But in terms of ease of learning, there's no comparison between it and PHP, Perl, or Java. Esp in ZAPwiki where I was able to avoid a good number of complexities required to get ZAP forms in PmWiki to do what I want. ZAPwiki makes it all a breeze, and simpler code is stabler code. Try it and see. If we could just catch a vision for the potential of incorporating a really good "scripting language" into PmWiki over time (ie Pm's version, not necessarily ZAP), the results would be fantastic. > > To the rest of the list: if you try ZAPwiki--try it so you can see > > what you're missing in PmWiki and then make a request PmWiki do > > something similar. Use it to make PmWiki better. > > I'm all in favor of people trying other products and saying > "I really like this feature and wish we could add it to PmWiki". > For the most part I've tried to develop PmWiki so that even > if someone wants a feature that I'm not interested in pursuing > myself, it's possible to do it in PmWiki. Yes, and this is the reason PmWiki is such a success, and even that something like ZAPwiki could come along. ZAP would have never come into existence if you hadn't designed such a flexible engine. But whole new realms are opening up even in PmWiki. And we are still stuck in old ways of thinking and programming. We mustn't look backward, we must look forward. ZAPwiki's not the future, but it may well be a glimpse of the future. > However, if the purpose of "ZAPwiki's conceptual challenges" is > to get me to shoulder the burden of developing and/or supporting > features that I don't need, don't seem to have much popular > demand, and that I philosophically disagree with from a long-term > design and security perspective, then I don't have much to add > beyond what I've said in the past. In many previous messages > I've already addressed these challenges, and cited the drawbacks > that I see from the approaches advocated here. ZAPwiki doesn't > really address the drawbacks I've raised -- it just ignores them > or treats them as being insignificant. Actually I'm not asking anything right at the moment but an open discussion of several new conceptual possibilities for PmWiki--in light of a radically different proof of concept wiki showing some of the possibilities of what PmWiki might be able to become one day. If we're all happy where we are that's fine. But other wiki's are sitting still either I'm sure. And to stay vibrant we at PmWiki may need to think a bit about our future. Lack of demand for something we've never seen is not convincing to me. I'm not asking for any help developing anything for me. ZAPwiki is great for my limited needs. But if there is interest in anything ZAPwiki has to offer, I'm all for helping work together to port things into PmWiki. No interest, no problem. > Hope this helps, > > Pm Very helpful, and thanks again for the respect you've shown in seriously addressing my challenges. I'm happy to accept whatever conclusion you come to about exploring ideas from ZAPwiki further. Cheers, Dan _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
