Hi all, I am familiar with attr_accessible. But lately I have realised that it doesnt do exactly what I want it to do. Once a user is created on the system, I want to prevent the person from changing their username. I need username to be accessible on create... but after that I need it to be protected. Similarly - passwords need to be protected malicious form submits. I don''t want peope to be able to change their password in a sneaky way when, say, they submit a form to change their address. Instead, passwords should only be changed after they submit a very paticular form, and after they confirm the change through email. Are there any ideas on how to lock down certain values in a model after its initial creation? thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 13, 9:03 pm, Luzzy <luzer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi all, > > I am familiar with attr_accessible. But lately I have realised that > it doesnt do exactly what I want it to do. > > Once a user is created on the system, I want to prevent the person > from changing their username. > > I need username to be accessible on create... but after that I need it > to be protected. > > Similarly - passwords need to be protected malicious form submits. I > don''t want peope to be able to change their password in a sneaky way > when, say, they submit a form to change their address. > > Instead, passwords should only be changed after they submit a very > paticular form, and after they confirm the change through email. > > Are there any ideas on how to lock down certain values in a model > after its initial creation? > > thanks!you could do a before_update, or try this: http://locusfoc.us/2007/2/1/validates_unchangeable-plugin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
with before_update is the idea that i check the submitted fields and throw an exception if a protected field is given for an existing record? is there a clean way to do this already explored? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 13, 2007, at 9:03 PM, Luzzy wrote:> Once a user is created on the system, I want to prevent the person > from changing their username. > > I need username to be accessible on create... but after that I need it > to be protected. > > Similarly - passwords need to be protected malicious form submits. I > don''t want peope to be able to change their password in a sneaky way > when, say, they submit a form to change their address. > > Instead, passwords should only be changed after they submit a very > paticular form, and after they confirm the change through email. > > Are there any ideas on how to lock down certain values in a model > after its initial creation?This sounds to me like you''re expecting that an update via ActiveRecord will automatically write any data it recieves from a form. So, if you have a form that is intended to update a user''s name, and they copy the HTML, then add a password field that they collected from the original account create form, then submit that version, you''re suspicious that the password data actually makes it all the way through to the database. Is that what you''re worried about? Me too. :-) I''m new to Rails, and haven''t yet figured out what it has to protect against this situation, but in my own framework, my form processing had a required attribute which is an explicit list of allowed inputs by name. SQL was generated based on which inputs were submitted, but no matter what gets sent by POST or GET, and no matter even if you handed over the entire params array, the SQL generator would only allow those explicitly named inputs to become part of the query. IMO, it''s an essential part of input validation. Accept only what you want to accept applies to the actual field count in addition to date/ format per field. To me the protection you''re looking for doesn''t belong as a state of attribute in the model, it belongs at the poing of filtering the form to start with. That''s how you achieve fields being changed by "a very particular form." I would suspect Rails has some mechanism for this input filtering, but I haven''t gotten that far yet. -- gw --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 14, 12:45 am, Luzzy <luzer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> with before_update > > is the idea that i check the submitted fields and throw an exception > if a protected field is given for an existing record? > > is there a clean way to do this already explored?I haven''t tested this, but i think for the fields /columns you want write-once, you just return false/nil. Also, there''s this, and attr_readonly, but I haven''t figured out how to use it: http://constancy.rubyforge.org/ http://dev.rubyonrails.org/ticket/6896 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 14, 7:19 am, gene tani <gene.t...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Oct 14, 12:45 am, Luzzy <luzer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > with before_update > > > is the idea that i check the submitted fields and throw an exception > > if a protected field is given for an existing record? > > > is there a clean way to do this already explored? > > I haven''t tested this, but i think for the fields /columns you want > write-once, you just return false/nil. > > Also, there''s this, and attr_readonly, but I haven''t figured out how > to use it:http://constancy.rubyforge.org/http://dev.rubyonrails.org/ticket/6896BTW, this is a pretty common requirement, dozens of blogs. Search for "read-only", "write-once", "write-protected" "constant" fields/ columns/ objects/models etc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Any methods that are declared as protected will not be updated by update_attributes. You must set them explicitly using the attributes setter method. This doesn''t prevent them from being changed, but it does prevent form data sent to update_attributes from changing them. Hope this helps. -Bill Greg Willits wrote:> On Oct 13, 2007, at 9:03 PM, Luzzy wrote: > > >> Once a user is created on the system, I want to prevent the person >> from changing their username. >> >> I need username to be accessible on create... but after that I need it >> to be protected. >> >> Similarly - passwords need to be protected malicious form submits. I >> don''t want peope to be able to change their password in a sneaky way >> when, say, they submit a form to change their address. >> >> Instead, passwords should only be changed after they submit a very >> paticular form, and after they confirm the change through email. >> >> Are there any ideas on how to lock down certain values in a model >> after its initial creation? >> > > > This sounds to me like you''re expecting that an update via > ActiveRecord will automatically write any data it recieves from a > form. So, if you have a form that is intended to update a user''s > name, and they copy the HTML, then add a password field that they > collected from the original account create form, then submit that > version, you''re suspicious that the password data actually makes it > all the way through to the database. Is that what you''re worried about? > > Me too. :-) I''m new to Rails, and haven''t yet figured out what it has > to protect against this situation, but in my own framework, my form > processing had a required attribute which is an explicit list of > allowed inputs by name. SQL was generated based on which inputs were > submitted, but no matter what gets sent by POST or GET, and no matter > even if you handed over the entire params array, the SQL generator > would only allow those explicitly named inputs to become part of the > query. > > IMO, it''s an essential part of input validation. Accept only what you > want to accept applies to the actual field count in addition to date/ > format per field. To me the protection you''re looking for doesn''t > belong as a state of attribute in the model, it belongs at the poing > of filtering the form to start with. That''s how you achieve fields > being changed by "a very particular form." > > I would suspect Rails has some mechanism for this input filtering, > but I haven''t gotten that far yet. > > -- gw > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---