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.
