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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
