On 5/31/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Thu, May 31, 2007 at 09:11:41AM -0400, The Editor wrote: > > In fact, if Pm should only add to the core an option for ZAP's default > > login approach tied to encrypted password field in a users profile > > page. > > Out of curiosity, what happens to the encrypted password field > if someone deletes the user profile page? ;-)
That account would be deleted. Of course the pages could be edit protected to avoid that. > Also, what about user login identifiers that aren't valid page name > syntax? You would have to require it in whatever mechanism was used to create the login account. Or else the login would fail. Actually ZAP is a bit more sophisticated--it runs a page name formatting function on the member name input so if it's even close to a page name it will match and authenticate. The same function I use to convert the name they give when they register into an acceptable page name. Ben S. gave me the idea and it works like a charm. Also I' not suggesting it be the only authentication method used, just one that could be turned on and off--as a security feature--in a config file as desired. Probably what, two lines of code in PmWiki? On 5/31/07, Ben Wilson <[EMAIL PROTECTED]> wrote: > On 5/31/07, The Editor <[EMAIL PROTECTED]> wrote: > > In fact, if Pm should only add to the core an option for ZAP's default > > login approach tied to encrypted password field in a users profile > > page. It seems that's about all you would really need to replicate > > ZAP's basic member management system. Just a thought for those who > > don't really want all the fire power in ZAP. > > I have to disagree with this: PmWiki changing its core behavior to > adopt ZAP. First, you've already stated that ZAPWiki is to be an > improvement on PmWiki, but not a fork. What I'm reading is that you > want Pm to do the coding for your fork, which is unethical IMHO. > ZAPWiki is a fork.[1] I'm not suggesting PmWiki change it's core behavior, only that it add a useful extension--one that *already* works perfectly in ZAP (and for that matter ZAPwiki). I don't need the code for it--I was just thinking those who don't use ZAP could then take advantage of a really wonderful member management system. I don't need it for myself Ben--I've had it for months. And it is tops (the concept). Once you grasp how it works ou will begin to understand the implications of it. > Second, changing the core is supposed to follow a compelling reason. > If the entire community lobbied for a change, or if the change was a > logical progression of an implemented, core feature, then the core > should shift. AuthUser is the core user authentication mechanism. You > should be able to shoehorn your security hole^H^H^H protocol into > AuthUser rather than try to have PmWiki provide a new security > mechanism. Again, it's not a core shift, just a very simple extension. It has nothing to do with security, or any need I have. It's actually for the benefit of those too prejudiced against ZAP to give it a try! : ) Actually, I was just thinking, it is so easy to implement, it should be available in the core without having to load the entire ZAP engine to make it available to users. But if Pm doesn't think so, that's fine with me. > I'm afraid the "default login approach" is akin to the wiki clock.[2] No clue what you are talking about here. Sorry. You are over my head, friend. > What amazes me is you assert ZAPWiki is a 'floor-up' design, yet > you're basing it off of PmWiki, which suggests your "floor-up" starts > in the penthouse, not the foundation.[3] I should be releasing the code later today. When I do, you will see (if you care to look) that the whole underlying structure and more importantly the philosophy is radically different. Unless you are talking about concepts in PmWiki. But the code--it's virtually entirely new (and ZAP code of course). The entire download--code, documentation, wiki setup, and all) is just over 50 K. And it's fast! Do you really think I could tweak PmWiki enough to trim it all down to that? And yet increase many of its capabilities? It's only possible via a complete redesign of how the wiki works, from scratch. You see, the problem with PmWiki is its own success. It has generated so many powerful concepts and ideas, much of it's initial design really should be deprecated--but it can't be because it would break thousands of existing sites. Completely. If you start from scratch you can do things radically different--and reap a world of benefit. I'll post a separate thread on this topic later--but ZAPwiki really is indeed, entirely new. Let me add, I'm not recommending people switch from PmWiki. ZAPwiki is probably nowhere near ready for a production sites--though I'm using it already as such for myself... And Pm's mastery of the wiki world is the very best benefit of PmWiki, and a good reason to stick with it. Not to mention a great community--the best, and another valuable asset of PmWiki. On the other hand, if ZAPwiki challenges our thinking here at PmWiki and it results in improvements, it will be well worth it. Take ZAP for example. Perhaps it's not the best code--or at least didn't start out so great. But it did demonstrate how powerful a forms processor could be. So Hans took a stab at developing something better, and Fox was born. Now Pm, looking at both, is finally crystallizing his approach--no doubt better code still. Perhaps it would have happened without ZAP but I suspect ZAP stimulated ideas. Even those who never touch ZAP have thus benefited from it in this sense. Similarly, I don't anticipate droves flocking to ZAPwiki--nor do I want them. (Pm's donor base surely is pennies compared to the hours he puts into PmWiki. A shame really. And I don't have time or knowledge to support the kind of questions Pm does.). But if it challenges assumptions in PmWiki and PmWiki is strengthened, even a little, we're all better off. If I could get Pm to take over maintenance of ZAPwiki, I'd be happier still! But little chance of that. : ) I already asked... So, while I'm not sure at all what provoked your outburst Ben, in this case you strike me as completely off the mark in assessing the motives, or even the content of my suggestion. And perhaps it's these kinds of misperceptions that make a core feature like this most needed. Cheers, Dan _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
