From: Marc L. <ma...@la...> - 2012-11-21 23:07:36
|
Beyond a mailing list with archiving, it could also be an email address that redirects to several email accounts... xavi: If a mailing list is registered to Tiki, anyone on that list could do "reset password" and take over the account, right? Is this an acceptable / accepted risk? (Everyone on the list would see it happened) Another risk is the 1-click unsubscribe link being archived and clicked on by a search engine crawler... M :-) On Nov 21, 2012 11:13 AM, "Steve Cichosz" <St...@te...> wrote: > I see what your saying Marc. I was misinterpreting Xavi's example > slightly. The way I read it, the site admin was setting up the relay. What > is actually happening is that an end user of Xavi's site like's his > newsletter so much he is redistributing it to his own email list himself, > so the permission approach doesn't actually work into the situation as I > had first imagined. > > From that perspective yes, I would agree an option available to the site > user to force login at unsubscribe for the subscribing account would be a > good approach. I'll get a look at this on my holiday from work tomorrow > sometime between between watching my Dallas Cowboy's go to battle with the > Redskins and slipping into a turkey induced tryptophan coma. > > A quick caveat, I am working on this from a "PHP as a second language" > approach. I'll do my level best to implement this sensibly, though it may > not ultimately be as elegant as one would like in the end. I do agree > however that changes shouldn't break someone's usage model, so I'll > definitely be taking a shot at finishing what I started. > > Thanks guys, > Steve > > On Nov 21, 2012, at 7:41 AM, Marc Laporte wrote: > > We have a lot of permissions, and some are cryptic/long tail. Do we really > see a case where the site admin wants to permit some users to be able to > have 1-click unsub but others not? > > In xavi's example, it's a user choice. > > Brainstorming: > New pref: Let user de-activate 1-click unsub (default off, xavi turns on) > > If pref is activated, when user registers to newsletter, their is an > option > * "Need to login to unsubscribe" > * "1-click unsubscribe" (in newsletter footer) -> If you forward a copy > of your newsletter and don't remove the footer, this person can unsubscribe > you from the newsletter. > > To be even more fancy, this could be an option per newsletter. > > I think 1-click unsub is the nicer default. To avoid fraudulent unsubs, > the system could send one last message to confirm unsub. And in this > message, "If you have been unsubscribed by error, visit the site to > re-subscribe" > > M :-) > On Nov 21, 2012 9:07 AM, "Steve Cichosz" <St...@te...> wrote: > >> Hi Xavi, >> >> It took me a minute, but yes, I see what your getting at. You have a >> secondary distribution layer of an email list so that Tiki itself doesn't >> do the distribution management. Your preference would be that the final >> recipient unsubscribe from the email list, not from the Tiki newsletter >> itself, because that would unsubscribe all the recipients. Is that about >> right? >> >> I never saw this one coming. I completely subscribe to the Tiki >> philosophy of "make it optional" and have always done so with my own code >> (one way or another). In this particular case I was, in my mind, submitting >> a bug fix - not a feature add, so "optional" never came to mind. >> Personally, I'd say that given an unsubscribe feature is a fundamental part >> of a newsletter and that "make it easy for the customer" should be part of >> any development philosophy, it's disabling subscriptions or requiring login >> that should be the optional feature. :^) Either way though, site >> management choice is called for here and if making it happen is how I can >> give back, I'm happy to do it. >> >> There are a couple of ways to implement this and I'm not sure straight up >> "newsletter option" implementation is the best way. If this is made as a >> newsletter option , then it is an all-or-none situation. Everybody >> subscribed to the newsletter, or nobody subscribed to the newsletter will >> require login to unsubscribe. When there is a mixed newsletter, i.e. a >> newsletter that Tiki sends to mail list bots *and* directly to site >> patrons, that is going to cause a problem for one or the other. If this >> were implemented as a permission "tiki_p_loginless_unsubscribe" then the >> "fake" email list user could be put in a group that does not have the >> permission checked, while all other users would have the permission. >> >> To really go out on a limb, this could be impetus for a much deeper >> change in Tiki that could have benefit far beyond this one situation by >> implementing a "constraint system" to compliment the "permission system." >> Instead of making sure everyone had "tiki_p_loginless_unsubscribe" except >> the one-off email list management account, "loginless unsubscribe" could be >> assumed (as it is now, as of my change) and a constraint of >> "tiki_c_newsletter_login_unsubscribe" would be applied to the one user. I'm >> not necessarily suggesting that this is the immediate solution to the >> problem at hand, but certainly worth considering for future implementation. >> I see a lot of benefit, but it needs to be balanced with the potential >> complexity introduced. >> >> Back to the topic at hand, I am very much leaning towards the permission >> approach rather than the option approach. Being that an option was >> requested and not a permission, I'd like to get your opinion on this before >> I go marching forward. >> >> By the way, thanks for the detailed explanation of the problem and not >> just rejecting my submit Xavi, >> >> Steve >> >> On Nov 21, 2012, at 2:08 AM, Xavier de Pedro wrote: >> >> Skinut, could you please make this as an optional feature, please? >> Right now, after your commit, some sites will have a feature broken (I >> have a few): >> >> * we have subscribed email lists (mailman, in our case) for easy >> distribution of content generated from Tiki sites (through newsletters, >> etc), as well as many users subscribed to that newsletter. This way, any >> users in the mailman email list will be able to cancel the subscription of >> the email list to the tiki newsletter, and we do not want that to happen. >> Before your commit, that was not possible, because when anyone in the >> mailman email list clicked at the link, they were requested to log in, and >> since they don't know the password of the fake user which receives the >> email at the mailman email list (and receive also watches of certain tiki >> objects thorugh gourp watches), then everything was working fine. >> >> So, please, make your feature or enhancement optional, to avoid breaking >> current features. >> >> Thanks and welcome back to the active developers (I did read something in >> the irc log from these last days :-) >> >> Xavi >> >> On 20/11/12 22:47, sk...@us... wrote: >> >> Revision: 44053 >> >> >> http://tikiwiki.svn.sourceforge.net/tikiwiki/?rev=44053&view=rev >> >> Author: skinut >> >> Date: 2012-11-20 21:47:12 +0000 (Tue, 20 Nov 2012) >> >> Log Message: >> >> ----------- >> >> [FIX] Fixed problem with newsletters requiring subscriber to be logged in >> to unsubscribe. >> >> >> Modified Paths: >> >> -------------- >> >> branches/9.x/tiki-newsletters.php >> >> >> Modified: branches/9.x/tiki-newsletters.php >> >> =================================================================== >> >> --- branches/9.x/tiki-newsletters.php 2012-11-20 21:44:52 UTC (rev 44052) >> >> +++ branches/9.x/tiki-newsletters.php 2012-11-20 21:47:12 UTC (rev 44053) >> >> @@ -4,12 +4,13 @@ >> >> // All Rights Reserved. See copyright.txt for details and a complete >> list of authors. >> >> // Licensed under the GNU LESSER GENERAL PUBLIC LICENSE. See license.txt >> for details. >> >> // $Id$ >> >> - >> >> $section = 'newsletters'; >> >> require_once ('tiki-setup.php'); >> >> global $nllib; include_once ('lib/newsletters/nllib.php'); >> >> $access->check_feature('feature_newsletters'); >> >> -$access->check_permission('tiki_p_list_newsletters'); >> >> +if ( !isset( $_REQUEST["unsubscribe"] ) ){ >> >> + $access->check_permission('tiki_p_list_newsletters'); >> >> +} >> >> $auto_query_args = array('nlId', 'offset', 'sort_mode', 'find'); >> >> $smarty->assign('confirm', 'n'); >> >> @@ -35,7 +36,7 @@ >> >> >> >> } >> >> } >> >> -if (!$user && $tiki_p_subscribe_newsletters != 'y' && >> !isset($_REQUEST["confirm_subscription"])) { >> >> +if (!$user && $tiki_p_subscribe_newsletters != 'y' && >> !isset($_REQUEST["confirm_subscription"]) && >> !isset($_REQUEST["unsubscribe"])) { >> >> $smarty->assign('msg', tra("You must be logged in to subscribe to >> newsletters")); >> >> $smarty->display("error.tpl"); >> >> die; >> >> >> This was sent by the SourceForge.net collaborative development platform, >> the world's largest Open Source development site. >> >> >> >> ---------------- >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Tikiwiki-cvs mailing list >> Tik...@li... >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs >> >> > |