Re: [Rails-core] Improvements to Strong Params

2014-05-01 Thread Alexander Trauzzi
That's a really good question, but I don't know if presenting a new problem necessarily invalidates the original issue which is that by returning the "required" value, the API is basically saying strong params has no way of enforcing more than one required value. What if one of the values cont

Re: [Rails-core] Re: CSRF protection in rails 2.3.11

2014-05-01 Thread A Wilson
I know this is some serious thread necromancy, and I apologize for that. Google shows this result prominently for this subject. How is this a security flaw? Login only succeeds if the credentials are > correct. If someone has credientials, they can login to the site, and I > don't see what rol

Re: [Rails-core] Named has_*

2014-05-01 Thread Łukasz Niemier
Yes. I have given bad example. It should be only: has_may :boos, class_name: 'Foo' I was writing fast as I encounter the problem, so don't be mad. W dni czw 1 maj, 2014 o 23∶31 użytkownik Matt Jones napisał: On May 1, 2014, at 11:57 AM, Łukasz Niemier wrote: It will be nice, if has_* m

Re: [Rails-core] Improvements to Strong Params

2014-05-01 Thread Matt Jones
On Apr 30, 2014, at 10:00 PM, Alexander Trauzzi wrote: > I've just been getting re-acquainted with Rails 4 after spending the past > year working in some other frameworks. > > One thing I noticed are strong parameters which I see as a really great > addition! One flaw I've noticed however is

Re: [Rails-core] Named has_*

2014-05-01 Thread Matt Jones
On May 1, 2014, at 11:57 AM, Łukasz Niemier wrote: > It will be nice, if has_* methods will have named option. Example: > > has_many :foos, named: :boos > > # equivalent of > > has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' > > IMHO it is quite often used feature. Also it will be n

Re: [Rails-core] Improvements to Strong Params

2014-05-01 Thread Alexander Trauzzi
Sure, but keep in mind, you've made an assumption about the schema of the posted variables and imposed it on all consumers of the API. Probably goes beyond astonishment at that point... On Thursday, 1 May 2014 11:20:40 UTC-5, Jeremy Kemper wrote: > > I expect params.require(:key) to return its

Re: [Rails-core] Improvements to Strong Params

2014-05-01 Thread Jeremy Kemper
I expect params.require(:key) to return its value, not self. I can see that perspective on astonishment, though. In practice, it leads to fluently chained code to set up your params "schema": ```ruby def post_params params.require(:post).permit(:subject, :body, ...) end ``` On Wed, Apr 30, 2014

Re: [Rails-core] Named has_*

2014-05-01 Thread Денис Редозубов
I also think it is used pretty frequent and may be a good convention. +1 on this, i personally will be glad to see this on trunk. 2014-05-01 19:57 GMT+04:00 Łukasz Niemier : > It will be nice, if has_* methods will have named option. Example: > > has_many :foos, named: :boos > > # equivalent of

[Rails-core] Named has_*

2014-05-01 Thread Łukasz Niemier
It will be nice, if has_* methods will have named option. Example: has_many :foos, named: :boos # equivalent of has_many :boos, class_name: 'Foo', foreign_key: 'foo_id' IMHO it is quite often used feature. Also it will be nice to have scoped option that will allow easy flow with scoped models

[Rails-core] Improvements to Strong Params

2014-05-01 Thread Alexander Trauzzi
I've just been getting re-acquainted with Rails 4 after spending the past year working in some other frameworks. One thing I noticed are strong parameters which I see as a really great addition! One flaw I've noticed however is in the behaviour of `params.require` which I don't think is 100% u