Hi Rob, This is *very* helpful and was what I was planning on implementing too.
Gracias and thanks, Tim On Thu, 2009-05-21 at 11:35 -0700, Rob Miller wrote: > Ross Patterson wrote: > > Tim Knapp <[email protected]> writes: > > > >> I've been searching through the remember/membrane tests to try and work > >> out how the member subscription expiry functionality works? Is this > >> based on the last logon time? Also, how do I reset the expiration date > >> for a user? > > > > I know that members are not authenticated if their workflow state but > > I've never confirmed if remember honors the effective and expiration > > dates. I've done quick look through the code and I can't see anything > > that looks like it is intended to honor those dates. I'll look more > > thoroughly later. > > no, you're right. currently, the MembraneUserManager plugin (which provides > the IAuthenticationPlugin interface) checks to make sure a member object is > in > an "active" workflow state before delegating actual authentication to the > member object, but it does not check the effective or expiration dates at all. > > > If it's not currently supported, it seems like we should honor those > > dates. Anyone have any objections or other thoughts? > > it'd be tempting to put support for this in the MembraneUserManager plugin, > but i'd recommend against doing that, since we want Membrane to be making > fewer assumptions about the member objects, not more. it seems reasonable to > me for membrane to assume that a member object has a workflow. it seems less > reasonable for membrane to assume that a member object will always support > effective and expire dates in the same way, if at all. > > given that, then, if it's decided that the out-of-box products should support > this functionality, i'd recommend any code to support this land in Remember, > not in Membrane. > > frankly, though, if i needed this functionality, i'd probably just do it in > custom code, outside of Remember itself. it'd look something like this: > > - when someone confirms registration for a specific duration of time (via > payment or some other means), i'd set the expiration date on their member > object. > > - i'd set up a nightly clockserver job to query for members who are in an > active workflow state but whose expiration date is in the past. > > - this clockserver job would fire a transition for those member objects, > putting them into an inactive state designed specifically for this purpose > (i.e. i'd use 'inactive' or 'expired', i wouldn't try to overload 'pending'). > > - i'd have an event listener subscribed to that workflow transition event, > which would send an email to notify the user that their account has expired > and that they won't be able to log in again until they reactivate their > account. > > the change of the workflow state would already prevent the user from logging > in, so there wouldn't need to be any changes to the MembraneUserManager > plugin, nor would it be necessary to override the member object's > authenticateCredentials method. > > there are other details to be worked out here, of course. probably you'd > want > the clockserver job to also look for folks whose expiration dates are coming > soon, to send out warnings, to give them a chance to renew their account > before the actual deactivation occurs. > > another slightly tricky bit could be handling reactivation after their > account > has been expired. at this point, the user can't log in... which means you'll > be interacting w/ anonymous users, who of course have no privileges. this > still isn't that bad, though. it's not like some nefarious attacker is going > to go around paying subscription fees on expired accounts. it's similar to a > bank; you don't need to prove who you are to make a deposit to an account, > only to withdraw. if you really want to be careful, to prevent people from > accidentally paying for someone else's subscription, you could require users > to enter their password at some point in the renewal process. even though > the > account is inactive, the password is still there, you should be able to call > authenticateCredentials directly on the member object to make sure the > entered > password is correct. the main thing to be careful of here is to make sure > you > don't expose any of the member's personal information (email address, etc.) > to > anonymous users. > > of course, if account renewal is triggered by some external mechanism (i.e. a > paypal payment triggering a message of some sort to be sent to your system), > then you don't really have to worry about that, you just need to make sure > you > reset both the workflow state AND the expiration date if the renewal trigger > happens after the previous expiry. > > hth, > > -r > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2009/05/1242930958306 > To unsubscribe send an email with subject "unsubscribe" to > [email protected]. Please contact > [email protected] for questions. > -- Archive: http://www.openplans.org/projects/remember/lists/remember/archive/2009/05/1242935468353 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
