Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On Wed, May 02, 2007 at 07:39:06AM +0200, [EMAIL PROTECTED] wrote: > On Tue, 1 May 2007, Patrick R. Michaud wrote: > > >On Tue, May 01, 2007 at 09:59:45PM +0200, [EMAIL PROTECTED] > >wrote: > >> > >>PS. Regarding security issues (as with Zap for instance), would it make > >>sense to have a list for those kinds of announcements? > > > >We have pmwiki-announce for that. > > That's a public list, isn't it? So the vulnerability is publicly > announced - I thought some people would object to this? In general it's considered good etiquette to contact a package's maintainers privately about potential vulnerabilities before making a public announcement. This is intended to give the maintainers an opportunity to determine if the vulnerability actually exists in fact, evaluate the potential ramifications, and to come up with mitigation strategies before it's widely known among people who might exploit it. > Hmm.. what about this problem with Zap (or recipes in general) > - is that something to announce? It's already been announced on pmwiki-users -- I'm leaving it to others to decide if a message should also go to pmwiki-announce. Anytime someone wants to make an announcement, security-related or otherwise, it can be posted to <[EMAIL PROTECTED]>. That's a moderated list, but I'll generally approve the post unless it's really off-topic for that list. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Recipe stability (was: Why all this zapping?)
On Tue, 1 May 2007, Patrick R. Michaud wrote: On Tue, May 01, 2007 at 09:19:42PM +0200, kjettil wrote: My assessment of ZAP is now clear - thanks to the contributions over the last 36 hours! But normally, it's a time consuming process to find out which ones are in the rough. I agree that it is very difficult to split the cookbook into "stable" versus "beta" groups, and it would also be difficult to move them from one group to another. Why not use categories? We could tag stable recipes with... 'recipe-stable' or something? OTOH, I think the 'status' attribute ought to work as well. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On Tue, 1 May 2007, Patrick R. Michaud wrote: On Tue, May 01, 2007 at 09:59:45PM +0200, [EMAIL PROTECTED] wrote: PS. Regarding security issues (as with Zap for instance), would it make sense to have a list for those kinds of announcements? We have pmwiki-announce for that. That's a public list, isn't it? So the vulnerability is publicly announced - I thought some people would object to this? For the record, I don't mind. Hmm.. what about this problem with Zap (or recipes in general) - is that something to announce? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] experimental - pagelist conditionals
I'm experimenting with a couple of new features, and looking
for feedback.
1. Extension to (:if date ... :)
Currently the 'date' conditional can only be used to test
that the current time is in a range of dates. For example,
to display some text only if the current date is between
March 15 and May 2 inclusive, one can write:
(:if date 2007-03-15..2007-05-02 :)
I've added an extra parameter to the 'date' conditional,
so that times other than the current time can be tested.
For example, to check if the current page's name is
in the month of May 2007, one can write:
(:if date 2007-05-01..2007-05-31 {*$Name} :)
Thus, this would evaluate to true for pages with names
like "20070512" or "2007-05-31", but false for pages
with names like "2007-04-30" or "2008-05-15".
Also, date ranges now understand phrases like "today",
"tomorrow", "now", etc.
2. if= option to (:pagelist:)
I'm also looking at the possibility of adding a new
if= option to pagelist. The contents of any if= option
are treated as a conditional markup (same as the "(:if:)"
directive) to be evaluated; only pages that evaluate
to "true" are kept in the pagelist. Thus, combined with
the above, one can write:
(:pagelist if="date today.. {=$Name}" :)
This returns a list of all pages with names that
correspond to dates today or later. Some other
examples that become possible with this:
- Display all pages with names in the current month
(:pagelist if="date {(ftime %Y-%m)} {=$Name}" :)
- Display all pages in PITS that were created in 2006
(:pagelist group=PITS $:Created=?* if="date 2006-01..2006-12 {$:Created}" :)
- Display only pages for which the visitor has edit permission
(:pagelist if="auth edit {=$FullName}" :)
Of course, using if= in (:pagelist:) will be somewhat
more efficient than (:if:) conditionals in a pagelist
template, and it also makes it easier to add count=
and other conditions on the resulting list.
Examples also appear at
http://www.pmwiki.com/wiki/Test/PageListIf
Comments welcomed.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] ZAP security vulnerability...
On Tue, May 01, 2007 at 08:02:01PM -0400, The Editor wrote: > I suggested one possible (probably easy) fix off-list that could > provide that back door. Allowing a simple string replacement array to > be processed before doing markup processing on an imposed page. I'm not sure exactly what you mean by "imposed page", but it sounds as though you mean "any page where the markup is coming from somewhere other than the current one." If that's correct, then essentially you're saying that recipes should be able to disable certain markups if they're coming from an included page or section, a pagelist template, GroupHeader, GroupFooter, page text variable, SideBar, or any other feature where we're doing any sort of "templating". I think that many admins and authors would find such limitations to also be confusing and overly constraining -- i.e., I can't generate a page containing a ZAP form and then just (:include:) it on multiple other pages? Or certain directives aren't allowed to be used in pagelist templates? Or I can't use form processing directives in a SideBar? So, while this might be a fix, I think it comes with its own set of negative issues and confusion for authors/admins that are probably best avoided. All of this is just a way of saying that I think we need a different overall solution to the problem here -- i.e., being able to bypass edit to write to *any* page is too blunt an instrument for what we're trying to achieve. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] ZAP security vulnerability...
On May 1, 2007, at 8:02 PM, The Editor wrote: > I won't argue with you on this as PmWiki is your program and you can > of course decide what is a feature and what is a problem. > Still--making it possible for a user to impose wiki markup on a page > (via a template) for which he has no write permissions seems a glaring > vulnerability to any recipe trying to do anything significant with a > form. Especially when there's no mechanism for a recipe writer to > escape markup, or modify in any way how that imposed markup is > processed. Hi, Everyone here is adults. There's a problem. Fix it. Stop pointing fingers. Nuff said. Either you fix it together, or you don't fix it together. That's the choice given mature people. But pointing fingers is a horrendous waste of time, and we all only have a finite amount of time. Stop wasting time. Think, do, fix. Thanks, Crisses ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] ZAP security vulnerability...
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Tue, May 01, 2007 at 06:26:37PM -0400, The Editor wrote: > > Pm has been kind enough to study the ZAP code and found a serious > > security vulnerability. We are still looking for a solution. > > > > Basically the problem is in PmWiki's ability to impose page content > > from an editable page onto a page that is not editable and load that > > page as if it were in the source code. You could argue this is a > > PmWiki vulnerability, (which allow users to insert a ZAPform onto a > > page they cannot edit) but regardless it will need to be fixed. > > Yes, you could argue this is a PmWiki vulnerability but > you'd be wrong. :-) > > Here PmWiki is functioning exactly as it has been designed to > function, and the features that the ZAP exploit uses do not, on their > own, impose any security risks to sites not running ZAP. It's only > when coupled with a recipe that allows page modifications >>outside > of PmWiki's normal edit authorizations<< that the potential for > problems occurs. > > Indeed, the features that the exploit is using are arguably > some of the most popular features in PmWiki at the moment: > >(:include:) templates >pagelist templates >page text variables >group header, group footer > in skin templates >sidebars, page actions, etc. > > So, unless we want to try to "fix" all of these features, I don't > think we can consider the problem a PmWiki vulnerability. Instead, > it appears to be a mistaken assumption on ZAP's part about being > able to rely on rendered markup (which can come from many sources) > to authenticate write access outside of the normal page permission > structure. I won't argue with you on this as PmWiki is your program and you can of course decide what is a feature and what is a problem. Still--making it possible for a user to impose wiki markup on a page (via a template) for which he has no write permissions seems a glaring vulnerability to any recipe trying to do anything significant with a form. Especially when there's no mechanism for a recipe writer to escape markup, or modify in any way how that imposed markup is processed. I take responsibility for not realizing how flexible PmWiki was and that it could do this kind of thing. It's a cool feature--but without a back door for recipe writers it seems a good many recipes could be exploited exactly the same way--though admittedly, not many to the extent ZAP could be. There are several obvious solutions, but all of them in my opinion seem onerous to the end user. And I definitely DO want write access to pages users cannot edit... 1) Set up a custom ZAPwrite permissions (in addition to its ZAPform permissions) and then require every write function in ZAP to check this permission. This means an admin would have to manually open the lock on every potential target page... 2) Set up a ZAPtarget config page (like the current ZAP config page limiting commands)--and manually identify allowed target pages for various commands or pages. 3) Simply limit the groups that can be written to in a config file--like I believe Fox does--which does not really solve the problem, only minimizes the potential damage. That is, a malicious user could perhaps create a Fox form very different from that intended by the admin even if it doesn't have site wide repercussions. All of these require extreme care and sophistication on the part of the admin to avoid the possibilities of some strange conbination doing damage. Imposing some markup on a page with some zap command enabled, then using it to paste malicious content to yet another page that has zap write permissions, then embedding that dangerous script on yet a third page via a page variable or whatever. Few admins will be able to sort out all the possible permutations this PmWiki flexibility allows--no matter how carefully a recipe writer tries to lock its code up. I suggested one possible (probably easy) fix off-list that could provide that back door. Allowing a simple string replacement array to be processed before doing markup processing on an imposed page. I hope you'll consider it... Or there may be a way to set some kind of flag or something automatically when markup has been imposed on a page. Even a config variable that simply allows/disallows forms to be imposed on another page. I know we're only talking a line or two if the strategic places could be found in the PmWiki code. It need also break no existing wikis. ZAP can and will be tightened down dramatically as soon as I get some time, but I believe the only way to have any kind of reasonably elegant soluton, would be for PmWiki to offer a safety hook for recipe writers who want to do things with forms. Otherwise the best any of us could do would reqire significant overhead on the admin, be complex, and still potentially risky. Thanks again Pm. Only the highest respect intended by this post in terms of your wonderful wiki, and yo
Re: [pmwiki-users] ZAP security vulnerability...
On Tue, May 01, 2007 at 06:26:37PM -0400, The Editor wrote: > Pm has been kind enough to study the ZAP code and found a serious > security vulnerability. We are still looking for a solution. > > Basically the problem is in PmWiki's ability to impose page content > from an editable page onto a page that is not editable and load that > page as if it were in the source code. You could argue this is a > PmWiki vulnerability, (which allow users to insert a ZAPform onto a > page they cannot edit) but regardless it will need to be fixed. Yes, you could argue this is a PmWiki vulnerability but you'd be wrong. :-) Here PmWiki is functioning exactly as it has been designed to function, and the features that the ZAP exploit uses do not, on their own, impose any security risks to sites not running ZAP. It's only when coupled with a recipe that allows page modifications >>outside of PmWiki's normal edit authorizations<< that the potential for problems occurs. Indeed, the features that the exploit is using are arguably some of the most popular features in PmWiki at the moment: (:include:) templates pagelist templates page text variables group header, group footer in skin templates sidebars, page actions, etc. So, unless we want to try to "fix" all of these features, I don't think we can consider the problem a PmWiki vulnerability. Instead, it appears to be a mistaken assumption on ZAP's part about being able to rely on rendered markup (which can come from many sources) to authenticate write access outside of the normal page permission structure. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] ZAP security vulnerability...
Pm has been kind enough to study the ZAP code and found a serious security vulnerability. We are still looking for a solution. Basically the problem is in PmWiki's ability to impose page content from an editable page onto a page that is not editable and load that page as if it were in the source code. You could argue this is a PmWiki vulnerability, (which allow users to insert a ZAPform onto a page they cannot edit) but regardless it will need to be fixed. Unfortunately there is no immediate good solution (I've explored several). ZAP users should therefore use extreme caution about enabling ANY pages on a ZAP enabled site for editing--even if ZAP is only enabled on one page. ZAP should still be safe on sites were editing is not enabled anywhere except by untrusted users. My apologies to the community for this problem, and my commendations to Pm for finding it. I will be posting some stopgap fixes as soon as possible--but I'll be leaving out of town for a week and may have limited internet access while away. Hopefully I can find some time to work on this... Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] FoxForum & ForumX
Tuesday, May 1, 2007, 10:57:20 PM, [EMAIL PROTECTED] wrote: > I can read in Fox pages on the pmwiki site, Hans, that a new version is > in dev. Can you tell us when ? Can you tell us if new cookbooks will be > compatible with old data ? It will be a very different forum, using display templates, so the messages will be saved without formatting. I think it will not be compatible with the existing forum. Maybe old forum pages can still be viewed as now. I have not tested this. As to when: I am not sure at the moment, as I have stalled work on Fox. I have run into a few problems I find no answers at present. Questions about posting security, about integration of extension filter scripts, and about message handling. And I am reluctant to release any new forum till this is sorted out. I think it is better to use a Fox forum as an experiment at present, till PmWiki 2.2.0 comes out of beta and the new form processing features are there. Only then can some serious forum development happen. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] FoxForum & ForumX
Hello, I can read in Fox pages on the pmwiki site, Hans, that a new version is in dev. Can you tell us when ? Can you tell us if new cookbooks will be compatible with old data ? Thanks. marc -- http://www.malexism.com/ ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Recipe stability (was: Why all this zapping?)
I like the idea of endorsements! -Martin --- "Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: > This does bring up another thought... as opposed to > having "ratings" or "voting" on recipes [1], what if we > called them "endorsements"? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Recipe stability (was: Why all this zapping?)
On Tue, May 01, 2007 at 09:19:42PM +0200, kjettil wrote: > My assessment of ZAP is now clear - thanks to the contributions over the > last 36 hours! But normally, it's a time consuming process to find out > which ones are in the rough. I agree that it is very difficult to split the cookbook into "stable" versus "beta" groups, and it would also be difficult to move them from one group to another. This is also why we have the "Status:" line for each recipe. This does bring up another thought... as opposed to having "ratings" or "voting" on recipes [1], what if we called them "endorsements"? [1] http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/41611 Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmWiki and PDF
Jason Frisvold schrieb: > Greetings, > > I'm wondering if someone can help me out. I've tried both the > GeneratePDF and pmWiki2PDF recipes and while both do, in fact, > generate a PDF file, they both seem to leave something out. > > If I use GeneratePDF, the PDF seems to come out ok, but centering doesn't > work. > > As far as I know you don't have much influence on the renderer. You be able to configure the output via the comandline- command in the generatepdf.php. you can look here: http://www.easysw.com/htmldoc/docfiles/8-cmdref.html what is possible grz nos > If I use pmWiki2PDF, the PDF comes out ok, centering works, but page > breaks don't seem to work at all. Additionally, if I enclose > something in a div (to provide the page break), it runs together.. > > Honestly, all I'm looking for here is a way to generate a PDF file as > with GeneratePDF, but allow text to be centered like pmWiki2PDF. It > would be wonderful if I could add color in there as well, but that's > definitely not a requirement at this point. > > Can anyone help me out with this? > > Thanks, > > ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On Tue, May 01, 2007 at 09:59:45PM +0200, [EMAIL PROTECTED] wrote: > > PS. Regarding security issues (as with Zap for instance), would it make > sense to have a list for those kinds of announcements? We have pmwiki-announce for that. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On Tue, 1 May 2007, Tegan Dowling wrote: > Seems there might be a place for starting up a pmwiki social group on > FaceBook to handle this sort of 'thing'. There's also 'google groups' which would work well. Or create a custom "social networking" site (similar to myspace or facebook) via www.Ning.com I'd like to know if other proponents of some kind of pmwiki-social would agree that read-access should be limited to members? Even if we were to make membership automatic to anyone who wanted it, we'd still be keeping posts out of general public-space search results (unlike posts to pmwiki-users), which would be my preference. Why? So that you more freely can share personal information? Or what? (I'm afraid I haven't grasped the purpose of this thing at all, I just remembered about the google groups thing.) /Christian PS. Regarding security issues (as with Zap for instance), would it make sense to have a list for those kinds of announcements? -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Tue, 1 May 2007, Patrick R. Michaud wrote: Also for the benefit of those using ZAP it might be best to not document whatever workaround you use to achieve this on the mail list. Fair enough. Anyone who wants the address to the description of the exploit, just let me know and I'll send it off-list when it's ready. I'm interested. In general I think this kind of information really would be useful to (advanced) recipe writers. So it's a shame to sit on it. /C (not a big fan of security-through-obscurity :-) -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
said... > On Mon, 30 Apr 2007, Neil Herber (nospam) wrote: > > > On 2007-04-30 The Editor is rumoured to have said: > >> Thanks for the input Ben... I've enjoyed learning about the ethics of > >> open source communities almost as much as the coding. A curious but > >> interesting environment. > > > > A couple of questions that have come up a few times still have not been > > answered to my knowledge. Could you please clarify? > > > > 1) Is there any difference between ZAP and Acme? > > 2) If no, then could you use just one of the names? > > 3) Is there any need for 2 identities (you and the Coyote)? > > 4) If no, then could you use just one of the names? > > > > From what I have seen in questions posed here about ZAP and Acme, they > > are confusing people more than clarifying the reasons they both exist. > > > > I think you would do yourself and PmWiki a favor by using one or the > > other. > > I'm also confused and would like a clear answer to the above. My confusion > _has_ actually kept me from giving Zap (and Jits) a try. Multiple names > and aliases doesn't help either for that matter. +1 But, also, I'm at the point of disregarding zap because of the ongoing confusion. -- Cheers, Marc ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
Neil Herber (nospam) wrote: > On 2007-05-01 kjettil is rumoured to have said: >> I'd propose that, similarly, the Cookbook recipes be organized in two >> sets: 1 - One set for recipes which have been tested and proved to be >> stable, reliable and secure, and therefore can be recommended for >> safe use by serious web site developers. 2 - One set for recipes >> under development and testing, and which may be released to the first >> set, when further testing has shown their stability, reliability and >> security. Discussions on this set should take place in pmwiki-devel. > > I don't think this division is a realistic proposal, given the nature > of Cookbook recipes. Writing recipes is not a simple task, and writing > secure and stable ones is even more difficult. At second thought, you may be right; it would require a review committee, or something of that sort, to judge whether a recipe qualifies. The problem remains, though, unsolved. > I also assume that for any recipe I use, the author has done the best > job they could to make it secure and stable (unless they explicity > label it as a beta of some sort). Whether I have confidence in that > assessment depends (for me) on how well the author's other > contributions have stood the test of time. My assessment of ZAP is now clear - thanks to the contributions over the last 36 hours! But normally, it's a time consuming process to find out which ones are in the rough. /kjettil ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 2007-05-01 kjettil is rumoured to have said: > I'd propose that, similarly, the Cookbook recipes be organized in two sets: 1 > - One set for recipes which have been tested and proved to be stable, > reliable and secure, and therefore can be recommended for safe use by serious > web site developers. 2 - One set for recipes under development and testing, > and which may be released to the first set, when further testing has shown > their stability, reliability and security. Discussions on this set should > take place in pmwiki-devel. I don't think this division is a realistic proposal, given the nature of Cookbook recipes. Writing recipes is not a simple task, and writing secure and stable ones is even more difficult. Who, other than the author, would decide if a recipe was secure or stable? For my own purposes, I assume that anything in the core is as secure and stable as it can be - but even that has not been true in the past. There was at least one instance I can dimly recall where a core security hole was identified (but quickly patched). I also assume that for any recipe I use, the author has done the best job they could to make it secure and stable (unless they explicity label it as a beta of some sort). Whether I have confidence in that assessment depends (for me) on how well the author's other contributions have stood the test of time. Even commercial software can be unstable and insecure (no name calling, please!) but you don't have the option of fixing the code yourself. As a gross level, to secure an insecure recipe, just disable it. Not too good a scenario if it makes up a large part of your site, but at least it is an option. -- Neil Herber Corporate info at http://www.eton.ca/ ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Tue, May 01, 2007 at 01:53:09PM -0400, The Editor wrote: > On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > >On Tue, May 01, 2007 at 12:08:23PM -0400, The Editor wrote: > >> On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > >> >I'm saying that if ZAP is enabled _anywhere_ on a site that allows > >> >_any_ editing by an untrusted user, then the untrusted user > >> >can use ZAP to modify any other page on the site, and likely > >> >obtain the contents of otherwise read-protected pages. > >> > >> How could they do that? If ZAP is not enabled any ZAP form a person > >> created would do absolutely nothing. > > > >I'll set up a demonstration site that illustrates it. It'll > >take just a bit of time as I want to clearly document it > >so there's no question as to what I'm saying. > > Better still show me how to fix it. : ) I don't have a solid "fix". You'll probably be able to close off the specific attack I'm using, but the underlying risk that another hole is available to exploited will still be there. In fact, the whole reason why it has taken me so long (months!) to come up with a forms processing system of my own is because I don't think it's safe to assume that _all_ editors on a site can be trusted. If I could make that assumption, then my version of forms-processing would've been ready last Fall, if not sooner. > Also for the benefit of > those using ZAP it might be best to not document whatever workaround > you use to achieve this on the mail list. Fair enough. Anyone who wants the address to the description of the exploit, just let me know and I'll send it off-list when it's ready. Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
The two questions on ZAP, Acme and ZAPwiki I asked less than 36 hours ago have not been clearly answered, but have resulted in some 50 elucidating contributions from more than a dozen contributors. All these contributions lead me to the conclusion that ZAP (or Acme or whatever it may be called) is a continual source of great confusion; ZAP might be a useful set of tools - sometime in a more distant future when basic functionality, stability and security requirements have been met - but should certainly not be considered for serious web site development now, or in the near future. As concerns the PmWiki discussion media, we already have two email lists, pmwiki-users and pmwiki-devel. They are intended for two different sets of discussions/contributions. I'd propose that, similarly, the Cookbook recipes be organized in two sets: 1 - One set for recipes which have been tested and proved to be stable, reliable and secure, and therefore can be recommended for safe use by serious web site developers. 2 - One set for recipes under development and testing, and which may be released to the first set, when further testing has shown their stability, reliability and security. Discussions on this set should take place in pmwiki-devel. This way those who need functionality that is not in the the PmWiki core have an open, clear choice and can be aware of the risks involved. I.e either safely use proven recipes for their PmWiki production installations, or take the risk of having problems by using non-proven (be it sometimes more innovative) recipes. This won't prevent or restrict any bright idea or solution being brought forward and tested, but the recipe will be in the development Cookbook until it's mature enough for wider release. With this solution, the PmWiki reputation (as a versatile, stable, reliable and secure wiki software) won't be tarnished by the fact that people will find that some Cookbook recipe doesn't work as envisaged, compromises security or is virtually impossible to bring into a working state without a lot of additional coding work. /kjettil ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, May 01, 2007 at 12:08:23PM -0400, The Editor wrote:
> > On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > >I'm saying that if ZAP is enabled _anywhere_ on a site that allows
> > >_any_ editing by an untrusted user, then the untrusted user
> > >can use ZAP to modify any other page on the site, and likely
> > >obtain the contents of otherwise read-protected pages.
> >
> > How could they do that? If ZAP is not enabled any ZAP form a person
> > created would do absolutely nothing.
>
> I'll set up a demonstration site that illustrates it. It'll
> take just a bit of time as I want to clearly document it
> so there's no question as to what I'm saying.
Better still show me how to fix it. : ) Also for the benefit of
those using ZAP it might be best to not document whatever workaround
you use to achieve this on the mail list.
> > It might be possible with the {(sectionlist)} markup cause that
> > doesn't require a form submission, [...]
>
> I'm talking about the zap.php file I downloaded yesterday
> from the ZAP sites. I'm not using anything but the core
> ZAP markups.
ZAP core without the ZAP toolbox, is fairly tame, but I'm looking
forward to your demonstration, as well as suggested fix.
> > >> Also about the source markup expression... If a page is blocked for
> > >> reading, is it automatically blocked for source?
> > >
> > >PmWiki doesn't have anything called 'source' permissions. I think
> > >you're confusing permissions here with ?action=source, and the
> > >default permissions for ?action=source are indeed 'read' permission.
> > >This is controlled by the setting of $HandleAuth['source']
> > >(which defaults to 'read', meaning that read permissions are
> > >required to view a page's source via ?action=source).
> >
> > Well, I may have expressed myself unclearly but you can check if a
> > person has access to view the source of a page with this code you gave
> > me (it works!)
> >
> > if (! CondAuth($p, $HandleAuth['source'])) return '';
> >
> > My question was if a page was read protected but the source action was
> > not blocked, could a person by pass the read permissions this way?
>
> You don't seem to have fully grokked my answer.
>
> The thing that controls ?action=source is $HandleAuth['source'],
> which defaults to 'read' permission. Thus, placing a read password
> on a page automatically blocks ?action=source for anyone who
> doesn't have read permissions (unless the admin changes the
> setting of $HandleAuth['source']).
>
> For the conditional you've given above, $HandleAuth['source']
> evaluates to 'read', thus it's equivalent to executing
>
> if (! CondAuth($p, 'read')) return '';
>
> This says to return an empty string if the visitor hasn't established
> read permissions to the page given by $p.
That's cool. I guess that one at least is ok. I definitely
appreciate your attention to ZAP to help ensure it's the very best
software piece it can be.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
On Tue, May 01, 2007 at 12:48:42PM -0500, Patrick R. Michaud wrote:
> On Tue, May 01, 2007 at 06:29:28PM +0100, Hans wrote:
> > Tuesday, May 1, 2007, 5:19:45 PM, Martin Fick wrote:
> > > Hmm, I guest this means that we already have
> > > templating built into pmwiki, just not with the
> > > include command!
> >
> > The (:include :) directive allows data display via a template, by
> > using this syntax:
> >
> > (:include basepage=:)
> >
>
> Correction: Any {$:var} on will be replaced by the
> corresponding PTV of .
Just to be *really* precise: What really happens is that
any {$:var} on gets replaced by {$:var},
which the markup engine subsequently evaluates to be the value of
$:var in .
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
On Tue, May 01, 2007 at 06:29:28PM +0100, Hans wrote:
> Tuesday, May 1, 2007, 5:19:45 PM, Martin Fick wrote:
> > Hmm, I guest this means that we already have
> > templating built into pmwiki, just not with the
> > include command!
>
> To be precise:
>
> The (:include :) directive allows data display via a template, by
> using this syntax:
>
> (:include basepage=:)
>
> Any {$$var} on will be replaced by the corresponding
> PTV on .
Correction: Any {$:var} on will be replaced by the
corresponding PTV of .
After I adjust (:include:), any {$$var} on template page will be
replaced by the corresponding option value to (:include:) --
i.e., in the above {$$basepage} in the template would end up
with the value of after the substitution.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Tue, May 01, 2007 at 12:08:23PM -0400, The Editor wrote:
> On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >I'm saying that if ZAP is enabled _anywhere_ on a site that allows
> >_any_ editing by an untrusted user, then the untrusted user
> >can use ZAP to modify any other page on the site, and likely
> >obtain the contents of otherwise read-protected pages.
>
> How could they do that? If ZAP is not enabled any ZAP form a person
> created would do absolutely nothing.
I'll set up a demonstration site that illustrates it. It'll
take just a bit of time as I want to clearly document it
so there's no question as to what I'm saying.
> It might be possible with the {(sectionlist)} markup cause that
> doesn't require a form submission, [...]
I'm talking about the zap.php file I downloaded yesterday
from the ZAP sites. I'm not using anything but the core
ZAP markups.
> >> Also about the source markup expression... If a page is blocked for
> >> reading, is it automatically blocked for source?
> >
> >PmWiki doesn't have anything called 'source' permissions. I think
> >you're confusing permissions here with ?action=source, and the
> >default permissions for ?action=source are indeed 'read' permission.
> >This is controlled by the setting of $HandleAuth['source']
> >(which defaults to 'read', meaning that read permissions are
> >required to view a page's source via ?action=source).
>
> Well, I may have expressed myself unclearly but you can check if a
> person has access to view the source of a page with this code you gave
> me (it works!)
>
> if (! CondAuth($p, $HandleAuth['source'])) return '';
>
> My question was if a page was read protected but the source action was
> not blocked, could a person by pass the read permissions this way?
You don't seem to have fully grokked my answer.
The thing that controls ?action=source is $HandleAuth['source'],
which defaults to 'read' permission. Thus, placing a read password
on a page automatically blocks ?action=source for anyone who
doesn't have read permissions (unless the admin changes the
setting of $HandleAuth['source']).
For the conditional you've given above, $HandleAuth['source']
evaluates to 'read', thus it's equivalent to executing
if (! CondAuth($p, 'read')) return '';
This says to return an empty string if the visitor hasn't established
read permissions to the page given by $p.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] pmWiki and PDF
Greetings, I'm wondering if someone can help me out. I've tried both the GeneratePDF and pmWiki2PDF recipes and while both do, in fact, generate a PDF file, they both seem to leave something out. If I use GeneratePDF, the PDF seems to come out ok, but centering doesn't work. If I use pmWiki2PDF, the PDF comes out ok, centering works, but page breaks don't seem to work at all. Additionally, if I enclose something in a div (to provide the page break), it runs together.. Honestly, all I'm looking for here is a way to generate a PDF file as with GeneratePDF, but allow text to be centered like pmWiki2PDF. It would be wonderful if I could add color in there as well, but that's definitely not a requirement at this point. Can anyone help me out with this? Thanks, -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
Tuesday, May 1, 2007, 5:19:45 PM, Martin Fick wrote:
> Hmm, I guest this means that we already have
> templating built into pmwiki, just not with the
> include command!
To be precise:
The (:include :) directive allows data display via a template, by
using this syntax:
(:include basepage=:)
Any {$$var} on will be replaced by the corresponding
PTV on .
We also can use already
(:include basepage=:)
to use one particular template section from a template page which
holds multiple templates, similar to the pagelist templates.
Not yet possible is the use of
(:include var="some data value":)
or
(:include basepage=:)
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] (:sectionlist:) proposal (was: New template expression markup....)
Tuesday, May 1, 2007, 2:51:47 PM, Patrick R. Michaud wrote:
> Note that I make no representations as to how fast or slow this
> is likely to be, nor am I committing to any implementation or timeline
> for such. At this stage I'm just suggesting a direction for discussion,
> and indicating the direction I'm likely to head for this.
First and foremost I would like to see an implementation of making
PTVs more general so we can use PTVs in page sections, as in
{PageName#section$:Date}
and (:include TemplatePage basepage=DataPage#section:)
Second to be able to use {$$var} inside the included text.
Only last, but I need to think about this more, a (:sectionlist :)
directive.
Maybe the first two go hand in hand.
They would be incredible useful to build display templates for blogs
and forums and comment pages, of course for any display of data.
For this reason I wish an implementation would come rather sooner than
later. At least come together with the new form processing you are
working on.
We have not added much in the cookbook in the direction of display
templates, and a core implemetation of data display via templates
would give PmWiki development a great boost and stop fragmented efforts
to do it via special markups etc.
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On 5/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On Mon, 30 Apr 2007, Dr Fred C wrote: > Seems there might be a place for starting up a pmwiki social group on > FaceBook to handle this sort of 'thing'. There's also 'google groups' which would work well. Or create a custom "social networking" site (similar to myspace or facebook) via www.Ning.com I'd like to know if other proponents of some kind of pmwiki-social would agree that read-access should be limited to members? Even if we were to make membership automatic to anyone who wanted it, we'd still be keeping posts out of general public-space search results (unlike posts to pmwiki-users), which would be my preference. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
On Mon, 30 Apr 2007, Dr Fred C wrote: Seems there might be a place for starting up a pmwiki social group on FaceBook to handle this sort of 'thing'. There's also 'google groups' which would work well. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 5/1/07, Ben Stallings <[EMAIL PROTECTED]> wrote: > Patrick R. Michaud wrote: > > This understates/misstates my point. If ZAP is enabled on > > _any_ publicly accessible pages, then an author with edit permission > > to any other page on the site -- even pages where ZAP isn't > > "enabled" -- can use ZAP directives to modify any other page on > > the site. > > My first reaction to this was, "That's not true!" and indeed, when I > tried it on a site using UserAuth, it was not. It may also not be true > under AuthUser, where Dan has done most of his testing (and I have not). > But using regular PmWiki authentication it is, in fact, possible for a > user to save data to pages where s/he has no edit privileges. > Fortunately for me, none of my sites use regular PmWiki authentication. > But I hope you'll look into this soon, Dan! --Ben Again this is a feature not a bug in ZAP. It's so users can post comments etc., to pages they cannot edit. As far as I know however, they cannot do this unless ZAP is enabled on those page--which is what Pm is suggesting. You do need to block edit access to pages where ZAP is enabled or take one of ZAP's other security measures on those pages, as stated clearly in the tutorials on security at ZAPsite. Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] OT: Telemarketers without a Clue
I got a call a few secs ago: May I please speak to the person who does your company websites" (barely comprehend the English) -- Speaking May I have your name, please, -- I tell him first name I represent (very halting, lots of space between phrases) (can't understand company name) -- Okay (or similar non-committal, I'm listening phrase) (Lots and lots of pauses here. Either he's being polite and giving me pauses in which to hang up, or he's having trouble reading the script. Might be the latter, there was a lot of typing noise in the background) We are a website consulting company, based in Chicago, gives large number (like 150ish) sites they've done, international and all! -- During pause I ask him if he knows what my business is. He pauses a few seconds and hangs up. Damn. I wish he'd stayed on longer. I wanted to learn more about the competition. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
--- noskule <[EMAIL PROTECTED]> wrote:
>
> could someone briefly explane or point me to the
> explanation of {$$vars}
Briefly mentioned on this page:
http://pmwiki.org/wiki/PmWiki/PageListTemplates
{$$option} The argument option values from
(:pagelist:)
In other words, if you create a pagelist with the
following:
(:pagelist ... text="my special text":)
In your template you can use:
Text: {$$text}
and you will get the equivalent of:
Text: my special text
Hmm, I guest this means that we already have
templating built into pmwiki, just not with the
include command! One could certainly just write a
pagelist that returns a single page (any page, it is
not used) and then do variable substitution on a
template. Take a look at this:
http://pmwiki.org/wiki/Test/Templating
-Martin
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, May 01, 2007 at 11:40:33AM -0400, The Editor wrote:
> > On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > >On Tue, May 01, 2007 at 10:57:51AM -0400, The Editor wrote:
> > >> True. As the ZAPsite recommends, ZAP should only be enabled on pages
> > >> where trusted users have access to edit permissions. That is, either
> > >> lock down your site for editing and do all user interaction through
> > >> ZAP, or only enable ZAP on specific non-editable pages.
> > >
> > >This understates/misstates my point. If ZAP is enabled on
> > >_any_ publicly accessible pages, then an author with edit permission
> > >to any other page on the site -- even pages where ZAP isn't
> > >"enabled" -- can use ZAP directives to modify any other page on
> > >the site.
> >
> > Not sure I see the difference, but we're aggreed ZAP should not be
> > enabled on any pages where untrusted users have edit privileges (ie
> > non admins) unless special precautions are taken involving one of the
> > various security layers available in ZAP.
>
> The key difference is 'pages' versus 'site'.
>
> Your statement seems to imply that it's okay for a site to
> allow editing of some pages by untrusted users (e.g., something
> like a WikiSandbox) as long as ZAP is not enabled on those pages.
Yes, that is correct, as I understand it...
> I'm saying that if ZAP is enabled _anywhere_ on a site that allows
> _any_ editing by an untrusted user, then the untrusted user
> can use ZAP to modify any other page on the site, and likely
> obtain the contents of otherwise read-protected pages.
How could they do that? If ZAP is not enabled any ZAP form a person
created would do absolutely nothing. No info retrieved. No commands
executed. No post processing. Nothing. So how could ZAP be used to
obtain the contents of read protected pages or anything else for that
matter--via editable pages ZAP is not enabled on?
It might be possible with the {(sectionlist)} markup cause that
doesn't require a form submission, but it hasn't even been released
yet, and it will certainly be fixed before it comes out. The {(source
)} might also need some tweaking to beef it up, but even then it's
already blocked where the source is blocked.
> > Also about the source markup expression... If a page is blocked for
> > reading, is it automatically blocked for source? If so a page might
> > be read protected but not source protected, making the source markup
> > expression a vulnerability. (It only checks source permissions, not
> > read permissions). Is this correct?
>
> PmWiki doesn't have anything called 'source' permissions. I think
> you're confusing permissions here with ?action=source, and the
> default permissions for ?action=source are indeed 'read' permission.
> This is controlled by the setting of $HandleAuth['source']
> (which defaults to 'read', meaning that read permissions are
> required to view a page's source via ?action=source).
Well, I may have expressed myself unclearly but you can check if a
person has access to view the source of a page with this code you gave
me (it works!)
if (! CondAuth($p, $HandleAuth['source'])) return '';
My question was if a page was read protected but the source action was
not blocked, could a person by pass the read permissions this way? At
least that's what I was meaning. If so, I need to add a second check
for read permissions, just in case an admin read protects a page
without blocking the source.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] wikilib.d pmwiki/skin priority
hi list
On my skin I have a folder
/pub/skins/skin/wkilib.d folder
to access the files I have the following entry in config.php
global $WikiLibDirs, $SkinDir;
$where = count($WikiLibDirs);
if ($where>1) $where--;
array_splice($WikiLibDirs, $where, 0,
array(new PageStore("$SkinDir/wikilib.d/\$FullName")));
now it seams that pmwiki takes the file in /pmwiki/wikilib.d if a file
with the same name exists.
is there a way that pmwiki takes the file in /pub/skins/skin/wkilib.d folder
thanks for any hints
nos
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Tue, May 01, 2007 at 11:40:33AM -0400, The Editor wrote: > On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > >On Tue, May 01, 2007 at 10:57:51AM -0400, The Editor wrote: > >> True. As the ZAPsite recommends, ZAP should only be enabled on pages > >> where trusted users have access to edit permissions. That is, either > >> lock down your site for editing and do all user interaction through > >> ZAP, or only enable ZAP on specific non-editable pages. > > > >This understates/misstates my point. If ZAP is enabled on > >_any_ publicly accessible pages, then an author with edit permission > >to any other page on the site -- even pages where ZAP isn't > >"enabled" -- can use ZAP directives to modify any other page on > >the site. > > Not sure I see the difference, but we're aggreed ZAP should not be > enabled on any pages where untrusted users have edit privileges (ie > non admins) unless special precautions are taken involving one of the > various security layers available in ZAP. The key difference is 'pages' versus 'site'. Your statement seems to imply that it's okay for a site to allow editing of some pages by untrusted users (e.g., something like a WikiSandbox) as long as ZAP is not enabled on those pages. I'm saying that if ZAP is enabled _anywhere_ on a site that allows _any_ editing by an untrusted user, then the untrusted user can use ZAP to modify any other page on the site, and likely obtain the contents of otherwise read-protected pages. > Also about the source markup expression... If a page is blocked for > reading, is it automatically blocked for source? If so a page might > be read protected but not source protected, making the source markup > expression a vulnerability. (It only checks source permissions, not > read permissions). Is this correct? PmWiki doesn't have anything called 'source' permissions. I think you're confusing permissions here with ?action=source, and the default permissions for ?action=source are indeed 'read' permission. This is controlled by the setting of $HandleAuth['source'] (which defaults to 'read', meaning that read permissions are required to view a page's source via ?action=source). Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Mon, 30 Apr 2007, Neil Herber (nospam) wrote: On 2007-04-30 The Editor is rumoured to have said: Thanks for the input Ben... I've enjoyed learning about the ethics of open source communities almost as much as the coding. A curious but interesting environment. A couple of questions that have come up a few times still have not been answered to my knowledge. Could you please clarify? 1) Is there any difference between ZAP and Acme? 2) If no, then could you use just one of the names? 3) Is there any need for 2 identities (you and the Coyote)? 4) If no, then could you use just one of the names? From what I have seen in questions posed here about ZAP and Acme, they are confusing people more than clarifying the reasons they both exist. I think you would do yourself and PmWiki a favor by using one or the other. I'm also confused and would like a clear answer to the above. My confusion _has_ actually kept me from giving Zap (and Jits) a try. Multiple names and aliases doesn't help either for that matter. Best regards /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist q.
Patrick R. Michaud schrieb: > On Tue, May 01, 2007 at 04:21:15PM +0200, noskule wrote: > >> hi list >> Is there a way to get a pagelist that shows pages that links to PageA >> AND PageB >> >> (:pagelist name=CategoryA&CategoryB:) >> > > To just list pages that contain the strings "CategoryA" and > "CategoryB", one can do: > > (:pagelist CategoryA CategoryB:) > > If you're looking specifically for links to CategoryA and CategoryB, > that hasn't been implemented yet (but it's on my to-do list). > When implemented the syntax will be: > > (:pagelist links=+Category.CategoryA,+Category.CategoryB :) > > Pm > > yes, specifically links, cause otherwise all words would count, do you have a date when this will be? would be nice if in the next release ;-) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, May 01, 2007 at 10:57:51AM -0400, The Editor wrote:
> > On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > >Following up on this post, I think it needs to be made much clearer
> > >that using ZAP on a site means that _any_ author can create ZAP
> > >forms that can modify _any_ page on the site (including pages like
> > >Site.AuthUser and Site.ZAPConfig). I've already checked with Dan
> > >about this (off-list), and he confirmed it to be the case.
> >
> > True. As the ZAPsite recommends, ZAP should only be enabled on pages
> > where trusted users have access to edit permissions. That is, either
> > lock down your site for editing and do all user interaction through
> > ZAP, or only enable ZAP on specific non-editable pages.
>
> This understates/misstates my point. If ZAP is enabled on
> _any_ publicly accessible pages, then an author with edit permission
> to any other page on the site -- even pages where ZAP isn't
> "enabled" -- can use ZAP directives to modify any other page on
> the site.
Not sure I see the difference, but we're aggreed ZAP should not be
enabled on any pages where untrusted users have edit privileges (ie
non admins) unless special precautions are taken involving one of the
various security layers available in ZAP. ZAP is not designed for
publically editable pages. It's designed for admins who want a good
tool for rapid development.
> > >I also suspect that it's possible to create ZAP forms that can
> > >expose the contents of read-protected pages, but I haven't verified
> > >this yet.
> >
> > As far as I know this is not possible. In editing pages or sections
> > there is a {(source page#anchor)} markup expression--but it checks the
> > users permission to see the source before displaying anything. [...]
> > Anyway, there's no other way I know of in ZAP to get at a
> > page's source...
>
> I was looking specifically at the commands
>
>(:zap emailtemplate=.:)
>(:zap pagetemplate=.:)
>(:input type *template .:)
>
> They don't appear to me to be doing any checking of read
> permissions, which means that someone can use them to obtain
> the contents of protected pages.
You are likely correct. Though only trusted users should be creating
these forms (see above) all templating should do a check for read
permissions. I'll be sure to add it for the next release. Thanks
again Pm...
Cheers
Dan
Also about the source markup expression... If a page is blocked for
reading, is it automatically blocked for source? If so a page might
be read protected but not source protected, making the source markup
expression a vulnerability. (It only checks source permissions, not
read permissions). Is this correct?
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote: > Tuesday, May 1, 2007, 4:11:18 PM, The Editor wrote: > > > One simple solution would be to require double colons or some other > > variation in the data page... Or some kind of leading symbol, or an = > > sign. Open to suggestions... > > > time:: I don't know yet > > place:: my place > > people:: just some friends > > I hope you mean: use double colons or some other variation in order to > make possible the posting of simple colons in text. > A user would not use double colons, those will be used in setting up > the template for the form processor. Correct, as we can construct the data templates easily enough however we want. I guess :: strikes me as well as anything Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
Hi Jm!
Just a quick note to let you know I appreciate your emphasis on the
human side of our interactions. We need more of that in today's
disconnected and messed up world.
I also want to let you know I appreciate the interest you have shown
in ZAP and your willingness to examine the code. I have not yet been
able to study carefully all your recommendations but do plan to. I'm
trying to minimize major changes at this point but will implement as
much as I can.
Anyway I haven't said thank you (or least not enough) and wanted to do
that now. Not sure how a social list would work with all of us as busy
as we are, but I'd join. : )
Please continue to stay a part of PmWiki... I appreciate what you
have to offer, and it's needed.
Cheers
Dan
On 4/30/07, J. Meijer <[EMAIL PROTECTED]> wrote:
>
> In many ways this has become an open letter to Pm. Read it when you have the
> time.
>
>
>
> > Date: Mon, 30 Apr 2007 12:41:40 -0500
> > From: [EMAIL PROTECTED]
> > Subject: Re: [pmwiki-devel] Announce: pmwiki-social
> >
> >
> > [The original post was sent to pmwiki-devel, which is not the
> > purpose of the pmwiki-devel list. Please send any followups
> > to pmwiki-users.]
>
> That's ok, I just thought the issue concerns anyone wishing to associate
> themselves with pmwiki more.
>
> > On Mon, Apr 30, 2007 at 04:47:49PM +, J. Meijer wrote:
> > > We need a pmwiki-social list. That's a start to value our members and our
> > > community more.
> >
> > Decline. The pmwiki-users list can certainly double as pmwiki-social,
> > and has done so in the past. In particular, I have trouble imagining
> > posts that would be appropriate for pmwiki-social and inappropriate
> > for pmwiki-users.
> You want pmwiki-users to function better then? Or not lose value? Afraid
> people will start to ask questions "off-list"?
>
> Tegans response is to the point as far as I'm concerned.
>
> To me it is a product just as pmwiki is. Perhaps more valuable so.
>
>
> > > Like what's happening now with Dan isn't his fault, it is
> > > a consequence of a community lacking, forcing everything through the
> > > semantics of pmwiki-users!
> >
> > I disagree with this on several fronts.
> >
> > First, in some ways what is happening with Dan *is* his
> > fault, in that some of his posts go against open-source
> > community norms and expectations (likely unintentionally).
> >
> > - Open source communities consider forks to be a Bad Thing [1],
> > and for all intents and purposes ZAPWiki looks like a fork,
> > regardless of whether Dan chooses to call it one.
> >
> > - Open source communities don't like unsubstantiated claims.
> >
> > - Open source communities don't like misdirection (e.g., the
> > ongoing confusion between ZAP, Acme, ZAPEngine, ZAPWiki, ...),
> > false representations of identity, or other forms of "spin".
>
> Good list. But the list also holds when substituting "Open source
> communities" by "open source _users_". I.e. it is the users that dictate the
> norm. It is the developers group ('professional contributors') that orients
> my focus. They are a different bunch, my peers, having (and in some ways
> requiring) something more to offer.
>
> On the topic of forks: I am a fork owner myself. It is frustrating in many
> ways. Yet I have no *intent* of formally forking, that would require a
> _substantial_ additional effort. But yes it may happen and I see it as a
> *good* thing. Code demonstrated is better then code talked about. It is
> sometimes the only way to substantiate claims.
>
> So when freely shared and finding a place for oneself within the pmwiki
> developers/community, what could be the problem? Mild forks (not the ones
> created from flame wars) are good for open source, regardless if _users_ are
> somewhat confused. Confusion can of course be avoided. Developers on this
> list seem more than willing to do so.
>
> On the subject of misdirection, to me it seems Dan is pointing to common
> misdirections that have a personal effect on him. But when he turns the spin
> that is on him, he is suddenly guilty of 'spin'. Sure, you haven't commented
> on this thread, and as a father have let it go. I can see your point. Yet I
> don't like seeing it and I feel this is counter-productive and in some way a
> desire to see blood in order for to be passed on. I don't think that lesson
> is worth passing on. Doesn't this bring people down just for the sake of it?
>
> You know, communities aren't driven entirely by noble impulses. It is hard
> -if not impossible- to defend oneself of a sudden someone else interpreting
> you in a way you never envisioned, taking you by the balls so to say. It just
> isn't the right thing to do but it happens and it often happens with a
> majority vote. Doesn't make it right though.
>
> Of course, we mostly all operate on a best effort basis. But especially in
> this environment it helps _knowing_ who is who. Gush, I didn't know Hans i
Re: [pmwiki-users] Why all this zapping?
On Tue, May 01, 2007 at 10:57:51AM -0400, The Editor wrote:
> On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >Following up on this post, I think it needs to be made much clearer
> >that using ZAP on a site means that _any_ author can create ZAP
> >forms that can modify _any_ page on the site (including pages like
> >Site.AuthUser and Site.ZAPConfig). I've already checked with Dan
> >about this (off-list), and he confirmed it to be the case.
>
> True. As the ZAPsite recommends, ZAP should only be enabled on pages
> where trusted users have access to edit permissions. That is, either
> lock down your site for editing and do all user interaction through
> ZAP, or only enable ZAP on specific non-editable pages.
This understates/misstates my point. If ZAP is enabled on
_any_ publicly accessible pages, then an author with edit permission
to any other page on the site -- even pages where ZAP isn't
"enabled" -- can use ZAP directives to modify any other page on
the site.
> >I also suspect that it's possible to create ZAP forms that can
> >expose the contents of read-protected pages, but I haven't verified
> >this yet.
>
> As far as I know this is not possible. In editing pages or sections
> there is a {(source page#anchor)} markup expression--but it checks the
> users permission to see the source before displaying anything. [...]
> Anyway, there's no other way I know of in ZAP to get at a
> page's source...
I was looking specifically at the commands
(:zap emailtemplate=.:)
(:zap pagetemplate=.:)
(:input type *template .:)
They don't appear to me to be doing any checking of read
permissions, which means that someone can use them to obtain
the contents of protected pages.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
Tuesday, May 1, 2007, 4:11:18 PM, The Editor wrote: > One simple solution would be to require double colons or some other > variation in the data page... Or some kind of leading symbol, or an = > sign. Open to suggestions... > time:: I don't know yet > place:: my place > people:: just some friends I hope you mean: use double colons or some other variation in order to make possible the posting of simple colons in text. A user would not use double colons, those will be used in setting up the template for the form processor. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> Tuesday, May 1, 2007, 3:30:22 PM, The Editor wrote:
>
> > I just put together a solution for my needs, mentioned in the other
> > post--by using a markup expression. Basically:
>
> > 1) Use ZAP/Fox to create a page long these lines:
>
> > [[#ID1]]
> > name: Caveman
> > time: Today
> > comment: Welcome to the new section template system...
>
> > [[#ID2]]
> > name: Coyote
> > time: Tomorrow
> > comment: Guess he's gonna get deprecated...
>
> > [[#ID3]]
> > name: Editor
> > time: Soon
> > comment: One of these days I'll do my own website done!
>
> > 2) Second, create a template as normal (with {$$field} syntax).
>
> > 3) On the page you want to show the display put this markup:
>
> > {(section datapage templatepage)}
>
> > The rest is automatic. I'll be adding it to the ZAPtoolbox and
> > MarkupExpressionsExtension list shortly as I believe it will prove
> > very useful.
>
> How does it handle when people post text (posting a message in a forum for
> instance) in form of
>
> time: I don't know yet
> place: my place
> people: just some friends
>
> I mean this is a common way of writing.
> Would it not collide with the STV pattern recognition?
Very good question. Indeed it would... Here's the code if anyone
cares to suggest a solution:
$MarkupExpr['section'] = 'MkExpExtSection($args[0], $args[1])';
function MkExpExtSection($data, $template) {
$template = ReadPage($template);
$template = $template['text'];
$data = ReadPage($data);
$sections = explode("[[#ID", $data['text']);
unset($sections[0]);
foreach ($sections as $i => $section) {
$sectionarray = '';
$lines = explode("\n", $section);
$id = substr($line[0], 0, strpos($line[0], "]]"));
$sectionarray['id'] = $id;
foreach ($lines as $line) {
if (strpos($line, ": ") !== false) {
$f = substr($line, 0, strpos($line, ": "));
$v = substr($line, strpos($line, ": ") + 2);
$sectionarray[$f] = $v;
}
}
$out[$i] = preg_replace('/\\{\\$\\$(\\w+)\\}/e',
'ZAPfieldreplace("$1", $sectionarray)', $template);
}
return implode("", $out);
}
One simple solution would be to require double colons or some other
variation in the data page... Or some kind of leading symbol, or an =
sign. Open to suggestions...
time:: I don't know yet
place:: my place
people:: just some friends
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] ZAP threads and anchors
There is currently a conflict in ZAP between the thread syntax and the anchor symbol (#). I'm planning to change the way threads work so it only kicks in if it is the final character in a page name--ie forum.# but not forum.1000#123454322. That will solve the anchor problem--but wanted to give people a chance to offer input on the off chance it will break forms or do something I haven't considered... Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
Tuesday, May 1, 2007, 3:30:22 PM, The Editor wrote:
> I just put together a solution for my needs, mentioned in the other
> post--by using a markup expression. Basically:
> 1) Use ZAP/Fox to create a page long these lines:
> [[#ID1]]
> name: Caveman
> time: Today
> comment: Welcome to the new section template system...
> [[#ID2]]
> name: Coyote
> time: Tomorrow
> comment: Guess he's gonna get deprecated...
> [[#ID3]]
> name: Editor
> time: Soon
> comment: One of these days I'll do my own website done!
> 2) Second, create a template as normal (with {$$field} syntax).
> 3) On the page you want to show the display put this markup:
> {(section datapage templatepage)}
> The rest is automatic. I'll be adding it to the ZAPtoolbox and
> MarkupExpressionsExtension list shortly as I believe it will prove
> very useful.
How does it handle when people post text (posting a message in a forum for
instance) in form of
time: I don't know yet
place: my place
people: just some friends
I mean this is a common way of writing.
Would it not collide with the STV pattern recognition?
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 30, 2007 at 09:07:18PM -0700, H. Fox wrote:
> > On 4/30/07, Ben Stallings <[EMAIL PROTECTED]> wrote:
> > > I also fear [Dan's] doing his reputation more harm
> > > than good by repeatedly saying the recipe is unreliable and
> > > untrustworthy and something to be cautious of, when it is not
> > ...
> > I'm confident that Dan has made some effort to make ZAP safe, but
> > security concerns seem to have taken a back seat to adding Power!,
> > Features! and Extensibility!... From my perspective this conclusion
> > has been easy to reach, but it may not be obvious to a new
> > WikiAdministrator that adding lots of power, features, and
> > extensibility also adds significant risk of vulnerability to their
> > Pmwiki site.
>
> Following up on this post, I think it needs to be made much clearer
> that using ZAP on a site means that _any_ author can create ZAP
> forms that can modify _any_ page on the site (including pages like
> Site.AuthUser and Site.ZAPConfig). I've already checked with Dan
> about this (off-list), and he confirmed it to be the case.
True. As the ZAPsite recommends, ZAP should only be enabled on pages
where trusted users have access to edit permissions. That is, either
lock down your site for editing and do all user interaction through
ZAP, or only enable ZAP on specific non-editable pages.
There are three other backup security options also.
1) Set a ZAP password which will lock all ZAP form submissions unless
specifically enabled where needed. Do this as usual on your page/group
attributes pages.
2) Create a Site.ZAPConfig page (blank) which will automatically lock
all advanced commands from working except where specifically enabled.
Then be sure to edit protect that page!
3) If you want to get your hands a bit dirty, don't enable ZAPtoolbox
anywhere (that's where all the powerful functions are). Just cut and
paste the various functions on specific local config page as needed.
That way you only have just the power you need where you need it. It
might even improve performance a fraction of a second!
So you have several good ways for securing ZAP's capabilities, and
they can be mixed and matched or all added on top of each other for
the especially paranoid.
I should also add this is not a bug but a feature. I don't want my
users to be able to edit their forum posts or comments directly. So I
lock down those pages and allow users to post via the ZAP forms. I'm
not sure how Fox works but I definitely prefer to not leave these
kinds of pages closed to public editing. So ZAP is designed to make
that possible, on purpose.
> I also suspect that it's possible to create ZAP forms that can
> expose the contents of read-protected pages, but I haven't verified
> this yet.
As far as I know this is not possible. In editing pages or sections
there is a {(source page#anchor)} markup expression--but it checks the
users permission to see the source before displaying anything. It
does not check for read permissions however, and so that might need to
be added. Maybe Pm can clarify how that is supposed to work. Anyway,
there's no other way I know of in ZAP to get at a page's source...
It does occur to me something like the {(sectionlist page page)}
markup could be used maliciously, by a page editor simply setting the
template page to the read-protected page. And perhaps some of the
other templating functions in ZAP likewise need to be read-protected
checked. Of course if you are trusting those who can edit pages, or
using some of the built in security measures to block form
submissions--these are non-issues. I generally designed ZAP for those
who want to lock their site down and direct interaction through ZAP
forms. That's it's purpose. It's not very wiki-ish in nature.
> So, if your site is using ZAP, make sure you trust all of the
> people who have the ability to use ?action=edit . :-)
With anything as powerful and flexible as ZAP, it would be good idea
for users to read the security tutorials on ZAP carefully and make
sure they ask questions if something is not clear.
Thanks Pm for checking out the code and helping to clarify for others
what ZAP does and does not do.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] (:sectionlist:) proposal (was: New template expression markup....)
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Continuing on the brainstorming track, we could develop a
> (:sectionlist:) markup that does for sections the same thing
> that (:pagelist:) does for pages. In particular, (:sectionlist:)
> would read a page's markup, split it into sections by anchor, and
> then apply a template to each section. For example:
>
>(:sectionlist fmt=Site.BlogTemplate:)
>
>[[#id0001]]
>(:author:Pm:)
>(:date:2007-05-01:)
>(:subject:demonstration of sectionlist:)
>(:text:...:)
>
>[[#id0002]]
>(:author:Alice:)
>(:date:2007-05-01:)
>(:subject:what a cool idea:)
>(:text:...:)
>
> Or, to view the sections from another page:
>
>(:sectionlist OtherPage fmt=Site.BlogTemplate:)
>
> Of course, one could use (:sectionlist:) inside of a pagelist
> template to apply templates to sections across multiple pages:
>
>[[#sectionlist]]
>(:sectionlist {=$FullName} fmt=Site.BlogTemplate:)
>[[#sectionlistend]]
>
> Note that I make no representations as to how fast or slow this
> is likely to be, nor am I committing to any implementation or timeline
> for such. At this stage I'm just suggesting a direction for discussion,
> and indicating the direction I'm likely to head for this.
I just put together a solution for my needs, mentioned in the other
post--by using a markup expression. Basically:
1) Use ZAP/Fox to create a page long these lines:
[[#ID1]]
name: Caveman
time: Today
comment: Welcome to the new section template system...
[[#ID2]]
name: Coyote
time: Tomorrow
comment: Guess he's gonna get deprecated...
[[#ID3]]
name: Editor
time: Soon
comment: One of these days I'll do my own website done!
2) Second, create a template as normal (with {$$field} syntax).
3) On the page you want to show the display put this markup:
{(section datapage templatepage)}
The rest is automatic. I'll be adding it to the ZAPtoolbox and
MarkupExpressionsExtension list shortly as I believe it will prove
very useful.
I've just been testing it out and it's very cool. Very easy to put
links to editing the template or data for an admin. And with ZAP's
edit command you can retrieve one specific section and edit it
directly (the data fields), or insert a delete link to each comment.
Exactly what I was looking for.
It could of course be renamed sectionlist (which is better), and/or
changed to a directive--but this is my current implementation.
Cheers,
Dan
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist q.
On Tue, May 01, 2007 at 04:21:15PM +0200, noskule wrote: > hi list > Is there a way to get a pagelist that shows pages that links to PageA > AND PageB > > (:pagelist name=CategoryA&CategoryB:) To just list pages that contain the strings "CategoryA" and "CategoryB", one can do: (:pagelist CategoryA CategoryB:) If you're looking specifically for links to CategoryA and CategoryB, that hasn't been implemented yet (but it's on my to-do list). When implemented the syntax will be: (:pagelist links=+Category.CategoryA,+Category.CategoryB :) Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] pagelist q.
hi list Is there a way to get a pagelist that shows pages that links to PageA AND PageB (:pagelist name=CategoryA&CategoryB:) I would need this to show pages that have CategoryA AND CategoryB anyone any suggestions grz nos ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Tue, May 01, 2007 at 09:04:24AM -0400, The Editor wrote:
> > On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> > >Tuesday, May 1, 2007, 1:23:16 PM, Patrick R. Michaud wrote:
> > >
> > >> It might also be worthwhile to generalize PTVs to work with
> > >> sections. For example:
> > >
> > >> {PageName#section$:Date}
> > >
> > >Yes please. I hoped you would say something like this! :)
> > >This will then allow grabbing of PTVs of same name in different
> > >sections.
> >
> > Yes! Yes! I want to second this.
>
> It's just an idea at this point, I can't commit to an implementation
> at the moment.
>
> One of the big issues is that the next step will be a request to
> make it work with pagelists somehow and that's not likely
> to happen anytime soon. So, all I'm doing above is suggesting
> a markup approach, without any particular promise to implement it
> until/unless there's a huge demand for it.
>
> Pm
That's cool. There IS a good demand for it here! : ) I'm wanting to
do the same thing for ZAP so that it can set a datapage to
Group.Name#Anchor and either save data in that section, or edit that
section, or insert a comment there, or whatever. It would be quite
cool. I really need to change datapage to target so it would make
more sense to use it with all those functions, but it would greatly
simplify the syntax. Maybe I could allow either for awhile...
But regardless, I was able to get my immediate objective taken care
of. I'll post on the other thread you just started.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Why all this zapping?
On Mon, Apr 30, 2007 at 09:07:18PM -0700, H. Fox wrote: > On 4/30/07, Ben Stallings <[EMAIL PROTECTED]> wrote: > > I also fear [Dan's] doing his reputation more harm > > than good by repeatedly saying the recipe is unreliable and > > untrustworthy and something to be cautious of, when it is not > > ... > I'm confident that Dan has made some effort to make ZAP safe, but > security concerns seem to have taken a back seat to adding Power!, > Features! and Extensibility!... From my perspective this conclusion > has been easy to reach, but it may not be obvious to a new > WikiAdministrator that adding lots of power, features, and > extensibility also adds significant risk of vulnerability to their > Pmwiki site. Following up on this post, I think it needs to be made much clearer that using ZAP on a site means that _any_ author can create ZAP forms that can modify _any_ page on the site (including pages like Site.AuthUser and Site.ZAPConfig). I've already checked with Dan about this (off-list), and he confirmed it to be the case. I also suspect that it's possible to create ZAP forms that can expose the contents of read-protected pages, but I haven't verified this yet. So, if your site is using ZAP, make sure you trust all of the people who have the ability to use ?action=edit . :-) Pm ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] (:sectionlist:) proposal (was: New template expression markup....)
On Tue, May 01, 2007 at 08:25:57AM -0500, Patrick R. Michaud wrote:
> On Tue, May 01, 2007 at 09:04:24AM -0400, The Editor wrote:
> > On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> > >Tuesday, May 1, 2007, 1:23:16 PM, Patrick R. Michaud wrote:
> > >> It might also be worthwhile to generalize PTVs to work with
> > >> sections. For example:
> >
> > Yes! Yes! I want to second this.
>
> It's just an idea at this point, I can't commit to an implementation
> at the moment.
>
> One of the big issues is that the next step will be a request to
> make it work with pagelists somehow and that's not likely
> to happen anytime soon. So, all I'm doing above is suggesting
> a markup approach, without any particular promise to implement it
> until/unless there's a huge demand for it.
Continuing on the brainstorming track, we could develop a
(:sectionlist:) markup that does for sections the same thing
that (:pagelist:) does for pages. In particular, (:sectionlist:)
would read a page's markup, split it into sections by anchor, and
then apply a template to each section. For example:
(:sectionlist fmt=Site.BlogTemplate:)
[[#id0001]]
(:author:Pm:)
(:date:2007-05-01:)
(:subject:demonstration of sectionlist:)
(:text:...:)
[[#id0002]]
(:author:Alice:)
(:date:2007-05-01:)
(:subject:what a cool idea:)
(:text:...:)
Or, to view the sections from another page:
(:sectionlist OtherPage fmt=Site.BlogTemplate:)
Of course, one could use (:sectionlist:) inside of a pagelist
template to apply templates to sections across multiple pages:
[[#sectionlist]]
(:sectionlist {=$FullName} fmt=Site.BlogTemplate:)
[[#sectionlistend]]
Note that I make no representations as to how fast or slow this
is likely to be, nor am I committing to any implementation or timeline
for such. At this stage I'm just suggesting a direction for discussion,
and indicating the direction I'm likely to head for this.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On Tue, May 01, 2007 at 09:04:24AM -0400, The Editor wrote:
> On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> >Tuesday, May 1, 2007, 1:23:16 PM, Patrick R. Michaud wrote:
> >
> >> It might also be worthwhile to generalize PTVs to work with
> >> sections. For example:
> >
> >> {PageName#section$:Date}
> >
> >Yes please. I hoped you would say something like this! :)
> >This will then allow grabbing of PTVs of same name in different
> >sections.
>
> Yes! Yes! I want to second this.
It's just an idea at this point, I can't commit to an implementation
at the moment.
One of the big issues is that the next step will be a request to
make it work with pagelists somehow and that's not likely
to happen anytime soon. So, all I'm doing above is suggesting
a markup approach, without any particular promise to implement it
until/unless there's a huge demand for it.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Drop down code
On 5/1/07, Nicholas Buttle <[EMAIL PROTECTED]> wrote: > Hi > > there was a request for the drop down code. > > Here it is. Moslty provided by The Editor. It > requires ZAP, zapconditionals and zap markup. Actually, you only need ZAP and the list markup expression function in ZAP toolbox/markup expression extensions. (Which can be cut and pasted into a config file. In the latest release, ZAPconditionals and ZAPmarkup have all been rolled into one combined toolbox. Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] Announce: pmwiki-social
Facebook? Or Tribe.net, or (G-d forbid) MySpace? Or right here in the mailing list? Howdy, y'all. My name is Michael, and I have been a PmWiki user for three years. I was raised in South Datoka, live in Northeastern Pennsylvania, and think that linearity is over-rated. My day-job is programming in VB6/VBA (hrm...), and am enrolling in a Master's program in Software Engineering (so in about 5 years, look out, PM!). I would be more than happy to bring hotdish to the wiki-picnic. -the Other michael http://www.xradiograph.com/interference http://www.xradiograph.com/wrottings On 5/1/07, Dr Fred C <[EMAIL PROTECTED]> wrote: > Seems there might be a place for starting up a pmwiki social group on > FaceBook to handle this sort of 'thing'. > > -- > > Always, Dr Fred C > [EMAIL PROTECTED] ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> Tuesday, May 1, 2007, 11:10:39 AM, The Editor wrote:
>
> > ZAP uses them the same way in its templates.
>
> oh good. I did not know you switched these over from the {name} syntax.
I'm still using {field} for field replacements, but for template
insertions I use {$$field}
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> Tuesday, May 1, 2007, 1:23:16 PM, Patrick R. Michaud wrote:
>
> > It might also be worthwhile to generalize PTVs to work with
> > sections. For example:
>
> > {PageName#section$:Date}
>
> Yes please. I hoped you would say something like this! :)
> This will then allow grabbing of PTVs of same name in different
> sections.
Yes! Yes! I want to second this.
Also, thank you again for your input Hans. I think I have a good
interim solution now that will work for what I want. Hope to release
some updated code soon.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
Tuesday, May 1, 2007, 1:23:16 PM, Patrick R. Michaud wrote:
> It might also be worthwhile to generalize PTVs to work with
> sections. For example:
> {PageName#section$:Date}
Yes please. I hoped you would say something like this! :)
This will then allow grabbing of PTVs of same name in different
sections.
> [...]
> Inside of Site.BlogTemplate, {$$text} would be replaced
> with the value of the "text=" argument above, which would
> result in either {*$:comment1} or {*:comment2} and grab
> the appropriate PTV.
This looks good. It will preserve unique PTV names.
and using (:include ..:) no ending markup is needed.
Great, another recipe will be obsolete before any serious cooking has
started.
> Just some rambling thoughts. FWIW, it is _very_ likely that
> (:include:) will end up processing {$$...} variables from the
> arguments to the include directive.
Very exciting. Please do it!
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pagelist count
Thanks to Kathryn for the wildcard suggestion on the pagecount. Works great. Paul Lewis USCA Library ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On Tue, May 01, 2007 at 09:45:44AM +0100, Hans wrote:
> Tuesday, May 1, 2007, 1:42:07 AM, The Editor wrote:
> > [...]
> > (:template :)
>
> > It opens the datapage, explodes the content by the anchors, inserts
> > the data values into the template, and then re-implodes the output and
> > sends it back to the page.
It might also be worthwhile to generalize PTVs to work with
sections. For example:
{PageName#section$:Date}
would grab the $:Date PTV out of PageName#section. Then applying
a template to a single section simply becomes a variation of
(:include basepage=:)
except that here would be allowed to contain a section
identifier.
> http://www.pmwiki.org/wiki/Cookbook/FeralFormattedEntry
> which provides a kind of data container markup, and uses a template
> for formatted display of its data content. Data is stored as parameter
> values inside the markup, for instance
>
> (:ffe heading="A new entry" author="Jim" template=Site.BlogTemplate:)
> Some text
> from a textarea input box.
> (:ffeend:)
FWIW, I've been thinking that parameters to include should be
usable as {$$var} inside the included text, so that the above
could be something like
(:include Site.BlogTemplate heading="A new entry" author="Jim":)
and we'd just need a convenient way to get multi-line text
values into something that could be used by a template.
> (:ffe template=Site.BlogTemplate:)
> (:heading:A new entry:)
> (:author:Jim:)
> (:text:
> Some text
> from a textarea input box.
> (:ffeend:)
>
> (:ffe template=Site.BlogTemplate:)
> (:heading:reply to you:)
> (:author:John:)
> (:text:
> What is all this about?
> more text lines...
> (:ffeend:)
Perhaps instead:
(:include Site.BlogTemplate
heading="new entry" author="Jim" text=$:comment1 :)
(:comment1:
Some text
from a textarea input box.
:)
(:include Site.BlogTemplate
heading="reply to you" author="John" text=$:comment2 :)
(:comment2:
What is all this about?
more text lines...
:)
Inside of Site.BlogTemplate, {$$text} would be replaced
with the value of the "text=" argument above, which would
result in either {*$:comment1} or {*:comment2} and grab
the appropriate PTV.
Just some rambling thoughts. FWIW, it is _very_ likely that
(:include:) will end up processing {$$...} variables from the
arguments to the include directive.
Pm
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
Tuesday, May 1, 2007, 11:10:39 AM, The Editor wrote:
> ZAP uses them the same way in its templates.
oh good. I did not know you switched these over from the {name} syntax.
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
Tuesday, May 1, 2007, 11:28:31 AM, The Editor wrote: > ZAP has the ability to edit sections (delimited by anchors) so it > would be fairly trivial to pull the stv's back into a text box and > edit them just as they appear above (I'd just need to handle the > trailing section line better). If you wan t to use anchors, why not use an ending anchor as well: [[#id1]] [[#id1end]] PmWiki uses those quite commonly. > This gives a nice clean source that should be searchable, yet display > fully formatted without needing pagelists. Also the code for handling > the STV's will be quite a bit simpler not using hidden ptv format. I don't see how this would be searchable other than normal text search. I don't see you addressed the problem that we are not using proper PTVs. What you give as example would normally still be a PTV, even though not a hidden one. Or do you mean just to create these and call them STVs, sufficiently different in pattern as not to be seen as PTVs? Then we get something we can call a STV which is not a PTV. The script will process these, but they will not be processed by any PTV manipulating function or script. So this is just a variation on Feral's idea, but not using parameter=value inside a directive markup. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Drop down code
Hi
there was a request for the drop down code.
Here it is. Moslty provided by The Editor. It
requires ZAP, zapconditionals and zap markup.
cheers
Nicholas
**
{(list {$:mylist}|[[~{item}]] ^ [[<<]] )}
(:zapform:)
(:messages:)
(:if false:)
[[#dropdownlist]]
(:input select name=SocialsName "{=$Namespaced}":)
[[#dropdownlistend]]
(:if:)
(:pagelist fmt=#dropdownlist group=Profiles:)
(:input submit button "Add Me":)
(:input submit button "Drop Me":)
(:zap if1="equal '{button}' 'Add Me' ?
mylist=+{SocialsName}":)
(:zap if2="equal '{button}' 'Drop Me' ?
mylist=-{SocialsName}":)
(:zap mylist="":)
(:zap savedata="mylist":)
(:zapend:)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote: > Tuesday, May 1, 2007, 1:42:07 AM, The Editor wrote: > > [...] > > (:template :) > > > It opens the datapage, explodes the content by the anchors, inserts > > the data values into the template, and then re-implodes the output and > > sends it back to the page. All the data is cleanly stored on one > > page. And the template can be instantly updated sitewide. The best > > of both worlds! > > > I wrote out the code this morning but haven't had a chance to test or > > debut it yet. Should be able to finish tomorrow. Any thoughts? > > Kathryn is right; don't use (:template ...:). > > Otherwise very interesting. A short while ago I had a discussion about > this with Feral. We were polishing her new recipe FeralFormattedEntry > http://www.pmwiki.org/wiki/Cookbook/FeralFormattedEntry > which provides a kind of data container markup, and uses a template > for formatted display of its data content. Data is stored as parameter > values inside the markup, for instance > > (:ffe heading="A new entry" author="Jim" template=Site.BlogTemplate:) > Some text > from a textarea input box. > (:ffeend:) > > (:ffe heading="reply to you" author="John" template=Site.BlogTemplate:) > What is all this about? > more text lines... > (:ffeend:) > > One advantage to what you are proposing is that every entry can have > its own template specified. Nice for instance for a blog where the > first topic entry can look quite different than all the reply comments. > The other difference is that it does not use anchors to split the page > into different data entry sections, but the markup acts like a > container. So, this is working and you can play with it. I like to use > it for displaying forum posts with display templates. > > So then I thought: we could expand this and allow PTVs inside the > (:ffe :) ... (:ffeend:) container. I actually generalised Feral's > script to this extend for testing out this idea. So one could create a > page with > > (:ffe template=Site.BlogTemplate:) > (:heading:A new entry:) > (:author:Jim:) > (:text: > Some text > from a textarea input box. > (:ffeend:) > > (:ffe template=Site.BlogTemplate:) > (:heading:reply to you:) > (:author:John:) > (:text: > What is all this about? > more text lines... > (:ffeend:) > > But Feral's main objection was that we are creating "pseudo PTVs" and > that the source code looks less tidy and not so easy to edit later > than her own ffe markup. > > The point about pseudo PTVs is certainly true and applies to your > approach as well. PTVs are at the moment restricted, as all PTVs on one > page should bear unique names. So reusing PTV names in multiple data > sections of a page is against how PmWiki defines PTVs, and is not > suitable also for how PmWiki handles PTVs, for instance in pagelist > searches. > > A concept of multiple data sections on a page using some sort of PTV > needs to address this and really creates a new type of PTV, perhaps > better called SectionTextVariable, or STV. And this may indeed be very > useful. I've though of another way to do this that might be even more useful, though I'm still toying a bit with the exact implementation. The code should be easier and the syntax cleaner. Namely something like: == [[#ID1]] date: ... author: ... comment: ... == [[#ID1]] date: ... author: ... comment: ... == Then define a markup rule or two that takes the == wrappers and uses them to process the ptv's inside according to some template. The template could be defined by a (:sectiontemplate page:) markup, or perhaps be a ptv in the section, or I even thought of simply having the first section define the template. ZAP has the ability to edit sections (delimited by anchors) so it would be fairly trivial to pull the stv's back into a text box and edit them just as they appear above (I'd just need to handle the trailing section line better). This gives a nice clean source that should be searchable, yet display fully formatted without needing pagelists. Also the code for handling the STV's will be quite a bit simpler not using hidden ptv format. Just thinking out loud... Thanks for the input Hans! Cheers, Dan ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
On 5/1/07, Hans <[EMAIL PROTECTED]> wrote:
> Tuesday, May 1, 2007, 10:39:10 AM, noskule wrote:
>
> > could someone briefly explane or point me to the explanation of {$$vars}
>
> I don't think these are documented yet.
> Pm said he will adapt this syntax for replacement variables.
> Fox and FeralFormattedEntry uses them in templates as placeholders for
> field values.
>
> For instance the name of an input control will be matched by a var in
> a template page of this form {$$name}, then the value entered will be
> used in place of the {$$name} placeholder in the template.
ZAP uses them the same way in its templates.
Cheers,
Dan
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Dropdown list of Profiles
Nicholas Buttle schrieb:
> Hi
>
> I've got this code
>
> (:pagelist fmt=#dropdownlist group=Profiles:)
>
> and it generates a list of Profiles for me. However,
> it is concatenating the names and getting rid of the
> space between first name and surname. Is there any
> way of pulling the profiles information in and
> maintaining (or inserting) a space? So that
> 'NickButtle' would become 'Nick Buttle'
>
> TIA
>
> Nicholas
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>
hi nic
theres a pagevar for that |{$Namespaced}
hope that helps . ...
you post your pagelisttemplate, just wondering how you do the
dropdownlist . .
grz nos
|
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] {$$vars}
Tuesday, May 1, 2007, 10:39:10 AM, noskule wrote:
> could someone briefly explane or point me to the explanation of {$$vars}
I don't think these are documented yet.
Pm said he will adapt this syntax for replacement variables.
Fox and FeralFormattedEntry uses them in templates as placeholders for
field values.
For instance the name of an input control will be matched by a var in
a template page of this form {$$name}, then the value entered will be
used in place of the {$$name} placeholder in the template.
~Hans
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Dropdown list of Profiles
Hi I've got this code (:pagelist fmt=#dropdownlist group=Profiles:) and it generates a list of Profiles for me. However, it is concatenating the names and getting rid of the space between first name and surname. Is there any way of pulling the profiles information in and maintaining (or inserting) a space? So that 'NickButtle' would become 'Nick Buttle' TIA Nicholas __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] {$$vars}
hi list
could someone briefly explane or point me to the explanation of {$$vars}
thanks nos
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New template expression markup....
Tuesday, May 1, 2007, 1:42:07 AM, The Editor wrote: > [...] > (:template :) > It opens the datapage, explodes the content by the anchors, inserts > the data values into the template, and then re-implodes the output and > sends it back to the page. All the data is cleanly stored on one > page. And the template can be instantly updated sitewide. The best > of both worlds! > I wrote out the code this morning but haven't had a chance to test or > debut it yet. Should be able to finish tomorrow. Any thoughts? Kathryn is right; don't use (:template ...:). Otherwise very interesting. A short while ago I had a discussion about this with Feral. We were polishing her new recipe FeralFormattedEntry http://www.pmwiki.org/wiki/Cookbook/FeralFormattedEntry which provides a kind of data container markup, and uses a template for formatted display of its data content. Data is stored as parameter values inside the markup, for instance (:ffe heading="A new entry" author="Jim" template=Site.BlogTemplate:) Some text from a textarea input box. (:ffeend:) (:ffe heading="reply to you" author="John" template=Site.BlogTemplate:) What is all this about? more text lines... (:ffeend:) One advantage to what you are proposing is that every entry can have its own template specified. Nice for instance for a blog where the first topic entry can look quite different than all the reply comments. The other difference is that it does not use anchors to split the page into different data entry sections, but the markup acts like a container. So, this is working and you can play with it. I like to use it for displaying forum posts with display templates. So then I thought: we could expand this and allow PTVs inside the (:ffe :) ... (:ffeend:) container. I actually generalised Feral's script to this extend for testing out this idea. So one could create a page with (:ffe template=Site.BlogTemplate:) (:heading:A new entry:) (:author:Jim:) (:text: Some text from a textarea input box. (:ffeend:) (:ffe template=Site.BlogTemplate:) (:heading:reply to you:) (:author:John:) (:text: What is all this about? more text lines... (:ffeend:) But Feral's main objection was that we are creating "pseudo PTVs" and that the source code looks less tidy and not so easy to edit later than her own ffe markup. The point about pseudo PTVs is certainly true and applies to your approach as well. PTVs are at the moment restricted, as all PTVs on one page should bear unique names. So reusing PTV names in multiple data sections of a page is against how PmWiki defines PTVs, and is not suitable also for how PmWiki handles PTVs, for instance in pagelist searches. A concept of multiple data sections on a page using some sort of PTV needs to address this and really creates a new type of PTV, perhaps better called SectionTextVariable, or STV. And this may indeed be very useful. ~Hans ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
