Re: [Rails-core] HttpOnly cookies by default
In that case, even that shared cookie should likely be HttpOnly anyway. I'm not quite following why anyone would really oppose such a change here — Rails needs to maintain a strong secure-by-default stance, and every case where developers have to opt-in to security is a case where many developers will not. As long as there's a flag that's set to the current behavior for existing projects, and defaults to secure behavior for new projects, there shouldn't be any backward-compatibility concerns. If you need to access a cookie in JS, set it in JS or disable HttpOnly for that specific cookie. If a developer doesn't upfront anticipate it being used in JS, then it shouldn't be *allowed* to be accessed from there. -- Stephen Touset step...@touset.org On Mon, May 19, 2014 at 5:34 AM, Gabriel Sobrinho gabriel.sobri...@gmail.com wrote: I can't be sure but using cookies for that sounds the wrong solution for me, you have better options like a shared database, a redis instance may work. You'll need to use a cookie to share a session identifier (I would use a uuid) between the applications but reducing it to just one cookie may mitigate the need to mark all shared cookies as http only, but I don't know your environment, so please don't take this a recommendation ;) About rails, I would be concerned to backwards compatibility too, but we need to have access to both options (httponly and not httponly). Something like cookies.secure[:key] = 'value' and cookies[:key] = 'value'may work but it won't be secure as default. If we are choosing for security first, we may have cookies.insecure[:key] = 'value' or something like that. On Sunday, May 18, 2014 4:25:35 PM UTC-3, Matt jones wrote: I’ve had to resort to some pretty weird cookie stuff when passing data between a Rails app and non-Rails applications. The session is handy, but parsing it anywhere but in Rails is difficult and *updating* it outside of Rails is more difficult. —Matt Jones On May 17, 2014, at 9:12 AM, Gabriel Sobrinho gabriel@gmail.comjavascript: wrote: I would argue that if you have some information that can't be hijacked and even parsed on javascript (httponly cookies can't be read on javascript at all), why would you use cookies instead of the rails session? On Friday, May 16, 2014 7:07:42 PM UTC-3, fedesoria wrote: I would like to see this happen, since when dealing with Enterprise Vulnerability Scans it always comes up. On Monday, January 7, 2013 2:09:42 PM UTC-8, Stephen Touset wrote: Earlier, someone proposed on the GH issues tracker that Rails default all cookies to HttpOnly[1]. Rails already makes the session cookie HttpOnly, but given a general to keep Rails secure-by-default, it would probably be best if *all* cookies defaulted to HttpOnly. This would be a compatibility-breaking change, but it wouldn't be difficult to add a configuration option that can be defaulted to false for existing Rails apps that are upgraded. I'm more than happy to write the code for this change, but wanted to discuss it here first to see if anyone objects strongly. Josh Peek had concerns with backwards compatibility, but I think my proposal above for a configuration option should satisfy them. Anyone care to weigh in? [1] https://github.com/rails/rails/issues/1449 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com javascript:. To post to this group, send email to rubyonra...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Ruby on Rails: Core group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubyonrails-core/yDzoifkfqvc/unsubscribe. To unsubscribe from this group and all its topics, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
[Rails-core] HttpOnly cookies by default
Earlier, someone proposed on the GH issues tracker that Rails default all cookies to HttpOnly[1]. Rails already makes the session cookie HttpOnly, but given a general to keep Rails secure-by-default, it would probably be best if *all* cookies defaulted to HttpOnly. This would be a compatibility-breaking change, but it wouldn't be difficult to add a configuration option that can be defaulted to false for existing Rails apps that are upgraded. I'm more than happy to write the code for this change, but wanted to discuss it here first to see if anyone objects strongly. Josh Peek had concerns with backwards compatibility, but I think my proposal above for a configuration option should satisfy them. Anyone care to weigh in? [1] https://github.com/rails/rails/issues/1449 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/5j4eYHz-d1AJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Proposal for def_method_missing in ActiveSupport
Yes. However, this is something currently implemented *in* Rails already
(e.g., `SomeModel#find_by_foo_and_bar_and_baz`). Rails itself could benefit
from the abstraction being put into ActiveSupport.
On Thursday, August 9, 2012 5:42:16 PM UTC-4, Ryan Bigg wrote:
-1
I don't think this feature would be useful to the majority of Rails
developers out there, sorry.
You could always release it as a separate gem and get people to use it
that way.
--
Ryan Bigg
On Friday, 10 August 2012 at 0:59, Stephen Touset wrote:
In several places in Rails (e.g., ActiveRecord
`find_by_#{attr2}_and_#{att2}` methods), you override `method_missing` to
provide functionality. In all of those places, you follow the sane approach
of handling `respond_to?` as well as actually defining the method body for
future callers.
I've abstracted this logic out into a project called
def_method_missing[1]. Examples:
class Foo
# regexp matchers yield the MatchData to the block, so you can modify the
method
# body based on the regexp
def_method_missing /bar/ do |match|
- { match.pre_match }
end
# without a regexp matcher, the name of the method is passed to the block,
allowing
# you to decide whether or not to implement the method
def_method_missing do |name|
- { name } if name.length == 4
- { bang! } if name[-1] == '!'
end
end
foo = Foo.new
# regexp-based method_missing
foo.respond_to?(:bazbar) # = true
foo.bazbar # = baz
foo.methods.include? /bazbaz/ # = true
# arbitrary Ruby method_missing
foo.respond_to?(:wat) # = false
foo.respond_to?(:what) # = true
foo.what # = :what
foo.methods.include?(:what) # = true
foo.bang # = :bang # matches four-character method name
foo.bang! # = bang! # matches last-character bang
foo.wat! # = :wat! # matches four-character method name first
Is this something you'd be willing to consider including in ActiveSupport?
Obviously, I'll have to put the logic into its own Module to avoid
polluting default `Object`s and `Module`s. Plus documentation/tests. The
current implementation was just a concept I threw together a few months
back and promptly forgot about.
[1]: https://github.com/stouset/def_method_missing
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/ICy42NxOSOAJ.
To post to this group, send email to rubyonra...@googlegroups.comjavascript:
.
To unsubscribe from this group, send email to
rubyonrails-co...@googlegroups.com javascript:.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/UQmIuqwXMlwJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Proposal for def_method_missing in ActiveSupport
In several places in Rails (e.g., ActiveRecord `find_by_#{attr2}_and_#{att2}`
methods), you override `method_missing` to provide functionality. In all of
those places, you follow the sane approach of handling `respond_to?` as well as
actually defining the method body for future callers.
I've abstracted this logic out into a project called def_method_missing[1].
Examples:
class Foo
# regexp matchers yield the MatchData to the block, so you can modify the
method
# body based on the regexp
def_method_missing /bar/ do |match|
- { match.pre_match }
end
# without a regexp matcher, the name of the method is passed to the block,
allowing
# you to decide whether or not to implement the method
def_method_missing do |name|
- { name } if name.length == 4
- { bang! } if name[-1] == '!'
end
end
foo = Foo.new
# regexp-based method_missing
foo.respond_to?(:bazbar) # = true
foo.bazbar# = baz
foo.methods.include? /bazbaz/ # = true
# arbitrary Ruby method_missing
foo.respond_to?(:wat) # = false
foo.respond_to?(:what) # = true
foo.what# = :what
foo.methods.include?(:what) # = true
foo.bang # = :bang # matches four-character method name
foo.bang! # = bang! # matches last-character bang
foo.wat! # = :wat! # matches four-character method name first
Is this something you'd be willing to consider including in ActiveSupport?
Obviously, I'll have to put the logic into its own Module to avoid polluting
default `Object`s and `Module`s. Plus documentation/tests. The current
implementation was just a concept I threw together a few months back and
promptly forgot about.
[1]: https://github.com/stouset/def_method_missing
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/ICy42NxOSOAJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] db/schema.rb
Reading the Rails commit logs, I see that db/schema.rb's purpose has been clarified. It's intended to be the authoritative location for your database schema, and rake tasks like db:reset use it to rebuild the schema rather than running migrations. This raises several questions for me. 1 ) What, then, is the preferred mechanism for seed data in the database? Currently, many people use migrations to insert bootstrap data. If schema.rb will be used for tasks like db:reset, none of this data will be loaded. 2 ) What about those of us who specify additional options like charset or table types? This information, last time I checked, doesn't seem to be saved in the schema.rb. 3 ) Should there be yet another database-related Rake task for development? Many of us create migrations, then modify them until we're ready to commit. A simple rake db:reset used to re-run the migrations from scratch, but the new semantics mean that migration changes are never reflected. Thanks in advance. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~--~~~~--~~--~--~---
