Ahh, that's what you meant. Still, unless the attacker had a way to either intercept (receive the email) or block (keep it from recipient) there's no loss in that regard. The person who is trying to be denied already gets the signup email with the key. In most cases, everything except the email or whatever field is the user name can be changed.
For the case of someone losing the key, you can make another transition to resend a key to a given email address. Then, even if the attacker somehow managed to block the first send (doubtful unless they're the mail admin for a particular domain and then they can read it), the user still gets their account. On Aug 31, 7:49 pm, Henry Baragar <[email protected]> wrote: > Kevin, > > Currently, I am doing something similar in my transition block: > > transition :activate, { :inactive => :active }, :available_to => :key_holder > do > self.acting_user = self > members << Member.find_all_by_email(email_address) > organizers << Organizer.find_all_by_email(email_address) > save > end > > As to the DoS, consider the following: > > Suppose I signup as using [email protected]. I can't activate the > account (unless I can intercept the email being set to you), but you can't > signup (because I already have for you). Even if you did not ignore the > activation message, you don't known what password I used. So, I have denied > service to you. This the DoS scenario to which I was referring. > > Regards, > Henry > > On August 31, 2009 05:46:20 pm kevinpfromnm wrote: > > > I your transitions, you can provide a block and in that block, self is > > available as the user. For example I have the following transition in > > my user lifecycle: > > > transition :verify_email_address, { :unverified > > => :verified }, :available_to => :key_holder do > > UserMailer.deliver_email(self,"Email address verified","Your email > > address has been verified.") > > end > > > The self passed to the method is the user. > > > As to this being vulnerable to a DoS, I don't see any advantage to > > having a separate guest table. You're still storing information and > > you're still taking the compute time to generate the key and a > > response. If you're worried, you should probably limit the number of > > posts to that action per IP or even maybe on a max per second or both > > at the http level, not when it's already to rails. Though if you're > > getting that many attacks to implement that, you probably need a > > comprehensive security plan to close up all the various > > vulnerabilities IMHO. > > > On Aug 31, 2:43 pm, Henry Baragar <[email protected]> > > > wrote: > > > Kevin, > > > > Thanks for the reply. Also, I notice that Tom mentioned > > > after_user_create in another message. > > > > What you mention would work, except that I don't want to do those things > > > until after the activate. That is, I don't want to be exposed to a > > > Denial of Service Attack by someone just registering a whole bunch of > > > email addresses, without ever activating any of them. > > > > For that matter, I don't think that the user object should be created > > > until the activate stage. The implications of this is that we need the > > > Guest model to be backed by a table and had a life cycle that captures > > > the activation key. When I get a bit more time, I will flesh out this > > > idea a bit more and present it here before attempting an implementation. > > > > Regards, > > > Henry > > > > On August 31, 2009 01:36:59 pm kevinpfromnm wrote: > > > > I the after create you don't want to use current user or acting user > > > > which isn't really correct. You want self - the new user model. > > > > Assuming you're doing this in the model. > > > > > On Aug 28, 11:05 am, Henry Baragar <[email protected]> > > > > > wrote: > > > > > Hello, > > > > > > I need to update some tables in my database when somebody signs up as > > > > > a user. > > > > > > Originally, I had the updates in the User::after_create. However, > > > > > the current user at that point is guest and is prohibited from > > > > > updating those records by the hobo permission system. > > > > > > So, I moved the updates to the to activate step of the User > > > > > lifecycle. The updates still failed because the the active_user is > > > > > still Guest. > > > > > > This got me to thinking. Is the person using the application > > > > > considered to be authenticated if he/she can successfully activate a > > > > > User? If so, how come the acting_user is not set (to self) in the > > > > > activate step? If not, how come the person is not redirected to the > > > > > login page? Thoughts? > > > > > A related question: if I lose my activation key, how can I get it > > > > > back or restart the process? Do I have to ask the administrator to > > > > > remove my User record? > > > > > A little bit more off topic: If I ask for a password reset and go in > > > > > and reset may password, can someone who has found my password_reset > > > > > key (e.g. from reading my email) be able to reuse the key to change > > > > > my password and get control of my User? > > > > > Regards, > > > > > Henry > > > > > > -- > > > > > > Henry Baragar > > > > > Instantiated Software > > > > -- > > > > Henry Baragar > > > Instantiated Software > > -- > > Henry Baragar > Instantiated Software --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hobousers?hl=en -~----------~----~----~----~------~----~------~--~---
