Re: [pmwiki-users] Easy Web Feeds?
On Sun, Aug 22, 2010 at 7:17 PM, Randy Brown wrote: > Depending on how you want to select pages for your dynamic trail, you may be > able simply to define via the configuration file which pages you wish to > write to RecentChanges. Thanks, that's an idea. Still quite a bit of fiddling and RecentChanges may then be too limited in information for other things(?). After about 3 years of messing around I discovered that the Bloge-Feeds recipe works almost out-of-the-box and is really easily to customise via the URL. Thanks, Eemeli, for the recipe. I'd suggest the Web Feeds page which dates back to 2005, be updated. With Bloge-Feeds you can have feeds working in 10 minutes. I'm not the author of the Web Feeds docs so not sure I could add a "Feeds made easy" section to the top of the page? Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Easy Web Feeds?
Is there a simple way to get a web feed, including the content? I've looked through the recipes and they seem fairly old and complicated, are betas, or contain unresolved bug reports. Is there anything simple and stable? I thought with pagelists and wikitrails it should be possible, but I've not figured it out yet. It seems wikitrails require static pages? The web feeds docs say: "Subscribe to the WikiTrail you desire by supplying the feed url to the aggregator." But how to dynamically create the trail? Many Thanks, Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Keeping history when updating pages via php
How do you keep the full page history when using UpdatePage($pn, $old, $page) from PHP? I tried the following, reading the current page values into $old. But there are no diffs added to the page source in wiki.d (and rev=1). It's just overwriting, as though the page had not existed. Do I have to call another function to get history added? $page['text'] = 'the new text'; $pn = 'MyGroup.MyPage'; $old = ReadPage($pn); UpdatePage($pn, $old, $page); Many Thanks, Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Creating pages from other PHP script
I would like another PHP application to export content to pmwiki by creating pages, and/or editing pages. So via scripts on the same server. Is there an existing script or recipe which creates pmwiki pages? I would also need to set page permissions/attributes. Sure, I can create a file and write each line manually, but I guess pmwiki must already have scripts which would accept parameters to do this, but I don't know the inner workings. I guess it would be an API call, but does pmwiki have an API? I've only used cookbook recipes so far. Does anybody know? Thanks, Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On Fri, May 28, 2010 at 2:30 PM, Eemeli Aro wrote: > > I'm working on the next version of that just now, a rather heavy-duty > refactoring of the code to make it more generic, separating the back-end > storage solution from the rest of the code. Sounds like a good plan. I think this particular recipe needs a sort of open API functionality, so that other recipes can call upon it rather than authors having to create new versions of the sign-up recipe to suit each type of usage. @Dave, I also think captcha should suffice. If captcha is not an option for someone, then once backend storage is separate, it is easy for another recipe to specify a temp storage page, and copy data over after verification. Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On Fri, May 28, 2010 at 12:35 PM, Eemeli Aro wrote: > > There are at least three benefits from storing the data, as opposed to > passing it through the authentication link... There certainly are benefits, and I did use a temp sign-up storage file myself. I was just suggesting a solution with less work since initially everybody said they had little to no time to work on this recipe. There are other benefits to storing sign-up data, which I also used. Store the IP and you can limit attempts to crack the secret. Store the date to have the link expire, etc. > For using PmWiki data as a back-end to a newsletter or mailing list, I'd > recommend Enemies of Carlotta: I was thinking of Notify/FoxNotify, and other pmwiki based mailing recipes. Eemeli, you already have the mechanisms in your new AuthUserProfiles recipe proposal. Why not have an email-only option, stored in a separate place for these purposes? e.g. SiteAdmin.VerifiedAddresses, or whatever, which other recipes can access. Unsubscribing can use the same mechanism as the subscription/sign-up process. Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
In reply to various issues above. - The user clicks on a link, a "GET" query string. They do not have to re-enter information. - The data does not have to be stored *before* verification because the data will be sent back when the user clicks the email link, and the key tells us if it's correct. - Upon successful verification the email and any other data has been stored, so you have the data to unsub an email address. Just look it up by supplying the storage page. - This also works for email subscription only sign-ups to newsletters or Notify, for users without accounts. It should not require a username and password. - Unsubscribing uses the same mechanism. The email is again hashed with a secret. The user clicks the link, the key is checked, voila!, verified or not. - You can verify any info like this. It is not only against spammers, but also hijacking. Only the real user has access to their email account.That is the second reason for sending emails. - The sign-up system could allow the admin, or other cookbooks, full control. They specify which fields, only email is mandatory. They specify where to write the verified data, and the separator. fields: email, user, password storagePage: SiteAdmin.Whatever separator: ',' Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On Mon, May 24, 2010 at 11:17 PM, V.Krishn wrote: > > I am guessing $secret is set by admin in some php file. config.php would be a good place. > Then secret would become permanent till those users exists, > and admin would not be able to change the secret when compromised. You can change a line in config.php whenever you like. > But then this would not be an issue as $password /s cannot easily be known. If config.php is compromised then it's probably game over anyway. That's not really an issue in this context, just standard security for pmwiki and your web server. Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On Mon, May 24, 2010 at 2:24 PM, V.Krishn wrote: > > I am guessing you mean sha1($email.$username.$password) The secret string is the important thing to include. Build a hash containing whatever strings you want to verify, plus the secret, e.g.: sha1($email.$username.$password.$secret); Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
I just realised this a lot simpler than I thought. There is no need for temporarily storing the sign-up info. I think this should work: - user supplies email, username, password via a form - create a key containing supplied info plus a secret: sha1($email.). - Mail to user. No record is kept because the key can be generated from info the returning user enters plus the secret. - user goes to verification page and enters the info plus the key. The key is checked. - if it matches, append, replace, or remove entry in wiki page The only general functions needed are to find a line in a wiki page, and write to a page. (I guess both these already exist as pmwiki functions?) Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On Thu, May 20, 2010 at 5:08 PM, Hans wrote: > > Is it a safe enough method to sent out a registration code to a new > user, with a link and url parameters for automatic confirmation? (Hans this is the thread I was referring to in my post on FoxNotify yesterday). I had no problems using this method. If you want to be really secure then just wrap a secret word into a hashed number instead of just a random key, e.g. sha1($email.$secret). I don't think hashing or encryption is necessary because all you need is a unique number e.g. like short urls (youtube, bitly), and the email address. A spammer or thief would need to guess both the number and email. If you are still unsure just limit the allowed verification attempts. It's simple and secure. I have a sign-up script I wrote in PHP and used it for a site over several months successfully. It had a few hundred subs, noticed no problems. It was very simple. 95% of the code was form validation and retrieving data. What I did, and this might work for pmwiki, is to use a separate flat file for the sign-ups. This keeps the real user list clean. On successful verification, and that is simply comparing the email and key, you copy the user data to where it's needed. To unsub go the same way. Write the request to a temp file entry, when successful, remove both the temp and real DB entries. I included the current unix time so the sign-ups could also expire. Failed subs/unsubs don't effect the real DB. All the junk stays in temp files. You can also control sign-ups by IP logging. I used a PHP script which writes to flat files, but one could just as well use pmwikis built-in methods. So my suggestion is to not mess with the actual wiki data until after verification. This would also allow a general method of verification. Cookbook authors can then select where and how they want to write the verified data. It's really a feature pmwiki needs. I hope that makes sense. I am willing to help, only my knowledge of pmwiki coding is minimal. Since I've written such a script before and used it in a working environment I can help in the design and whatever code I can provide. Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Fox / Notify Unsubscribe
What would you suggest to let users subscribe to notifications (notify.php/FoxNotify)? I need unauthenticated visitors without edit permissions to be able to subscribe to notifications of changes in Groups or (comments) on a page, *and* unsubscribe, or change their options. FoxNotify seems to offer what I need, but I read no way for users to unsubscribe, or change existing options. Could that be added by searching for an email address line and deleting it, and adding a replacement for changes? (Note, slight problem there that users could unsub other users, because there's no address verification. See other post on this.) Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] How to test group membership in config.php?
How do you check in config.php whether the authenticated user is the member of a specified group? if currently authenticated user is in @group1 do this (The groups have been set with AuthUser) Thanks, Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Page List Template Trouble
On Wed, May 12, 2010 at 2:49 PM, Eemeli Aro wrote:
> Ah, that's because the pagelist template itself is on the page, and
> its contents get displayed as well, and outside pagelist processing
> {=$Name} isn't a valid variable.
Many Thanks, that fixed it.
>
> So try:
>
> (:pagelist link=Group.Page fmt=#bytitle:)
>
> (:if false:)
> [[#bytitle]]
> [[{=$Group}/{=$Name}]]
> \\
> [[#bytitleend]]
> (:ifend:)
>
> eemeli
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Page List Template Trouble
Can anyone please explain the following two problems which occur with
the code below:
code
(:pagelist link=Group.Page fmt=#bytitle:)
[[#bytitle]]
[[{=*$Name}]]
\\
[[#bytitleend]]
--
(Note: the template is within the same page.)
1) After the expected (partially) correct page list it also prints
"{=Name}" at the end.
2) The links only have the page correct, the group is always the group
on which the calling page is.
I tried it on the current stable pmwiki and also an older version,
both yield the same results.
Thanks,
Marcus
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Listing category links
How do you display links to pages which have the same categories as found on the current page? I'm trying out various tagging recipes. Say the post has three categories, cat1, cat2, cat3. I need to list the pages within those categories. Preferably separately for each category and limited to x page links, e.g.: pages within cat1: (list of max x page links within cat1) Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Site planning - tags/categories?
I could do with some help planning a movie review site with pmwiki. What I need to do is create cross-references to movies by the same director and actors, and most importantly films which are related. I guess categories or tags are the best way to flexibility? If that is the way forward, then does anybody have recommendations to which cookbook recipes to use? There are a whole bunch of tag/categories methods. Anybody done something similar like a book or music review site? Thanks, Marcus ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
