Hi, On Tue, 2009-05-26 at 11:47 -0700, Rob Miller wrote: > Tim Knapp wrote: > > Hello again Rob, > > > > On Thu, 2009-05-21 at 11:35 -0700, Rob Miller wrote: > >> Ross Patterson wrote: > > > > <snip /> > > > >> 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. > > > > I've implemented this solution as per your recommendations and I ended > > up having to create a browser view that the expired member opens up > > (with the memberid supplied via query string) and enters their password > > and selects their subscription period and the authenticateCredentials > > method is run against the member object and if this is successful the > > user is 'enabled' and redirected off to the payment processor and > > subsequently their expiry date is updated. This all works fine and dandy > > but I had to take away the transition guards from the 'enable_private' > > transition and I'm unsure what kind of security holes this opens up? > > well, the security holes that this opens up are what you might expect based > on > what you changed: it's now possible for any user to reactivate a disabled > user, whereas before it was only possible for someone w/ the "Manage users" > permission (assuming the guards you removed were still the default as > provided > in the member_approval_workflow). > > i wouldn't remove the guards, myself; instead i'd probably escalate the user > privileges by changing to the "system" user before triggering the protected > code, something like this: > > > from AccessControl.SecurityManagement import getSecurityManager > from AccessControl.SecurityManagement import newSecurityManager > from AccessControl.SecurityManagement import setSecurityManager > from AccessControl.SpecialUsers import system > > sm = getSecurityManager() > try: > newSecurityManager(None, system) > ### INSERT CODE REQUIRING EXTRA PRIVS HERE > finally: > setSecurityManager(sm) > > > i haven't tested this, so it may need a bit of tweaking, but the idea is > sound; i've used this technique successfully a number of times.
Thanks a lot, as always 'on the money'. I did try to use a similar approach to this but got errors but didn't try the 'system' user. I'll give it another go and report back. Thanks again, Tim > > -r > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2009/05/1243363709686 > 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/1243367235277 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
