| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Corrects the time comparison to be `Time.now < time` which allows the user to
be set only when the current time is less than the 2 week window given in the
example.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?
To look at memory:
```ruby
require 'get_process_mem'
mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb
after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"
```
Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.
To look at raw speed:
```ruby
require 'benchmark/ips'
number_of_objects_reduced = 1_114
Benchmark.ips do |x|
x.report("freeze") { number_of_objects_reduced.times { " ".freeze } }
x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```
We get the results
```
Calculating -------------------------------------
freeze 1.428k i/100ms
no-freeze 609.000 i/100ms
-------------------------------------------------
freeze 14.363k (± 8.5%) i/s - 71.400k
no-freeze 6.084k (± 8.1%) i/s - 30.450k
```
Now we can do some maths:
```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration
ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration
diff = call_time_before - call_time_after
number_of_objects_reduced * diff * 100
# => 0.4530373333993266 miliseconds saved per request
```
So we're shaving off 1 second of execution time for every 220 requests.
Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep.
p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings.
Keep those strings Frozen
![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)
|
|
|
|
|
|
|
| |
```ruby
verifier = ActiveSupport::MessageVerifier.new('secret')
verifier.verify("\xff") # => ArgumentError: invalid byte sequence in UTF-8
```
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
[ci skip]
Complements #17727 and closes ee73d9ff8.
@lleger How do you feel about this?
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the project guideline and the reasons are:
* That follows standard Ruby semantics.
* Allows the implementation to avoid artificial code like !! or something ? true : false
* You do not need to rely on the exact type of 3rd party code. For
example, if your method returns str.end_with?('foo') you do not need to
make sure end_with? returns a singleton. Your predicate just propagates
predicate semantics up regardless of what end_with? returns.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a `#verified` method to
`ActiveSupport::MessageVerifier` which will return either `false` when
it encounters an error or the message. `#verify` continues to raise an
`InvalidSignature` exception on error.
This commit also adds a convenience boolean method on `MessageVerifier`
as a way to check if a message is valid without performing the
decoding.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Otherwise this will lead to another error later on
when generating a signature:
TypeError (no implicit conversion of nil into String).
|
|
|
|
|
|
|
|
| |
`Base64.strict_decode64`.
This broke natural order of things for `StaleSessionCheck#stale_session_check!` which tried auto_loading a class based on `ArgumentError` message , and later retrying the `Marshal#load` of class, successfully allowing auto_loading.
This PR tries to fix this behavior by forwarding `ArgumentError` 's not raised by `Base64.strict_decode64` , as is, ahead to `StaleSessionCheck#stale_session_check!`
|
|
|
|
| |
Also reduce extra object allocation by creating string directly instead of join on Array
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, on Mac OS X, programmers accidentally press Option+Space
rather than just Space and don’t see the difference. The problem is
that Option+Space writes a non-breaking space (0XA0) rather than a
normal space (0x20).
This commit removes all the non-breaking spaces inadvertently
introduced in the comments of the code.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
MessageVerifier and MessageEncryptor.
|
|
|
|
| |
and MessageEncryptor.
|
| |
|
|
|
|
|
| |
By default, these classes use Marshal for serializing and deserializing messages. Unfortunately, the Marshal format is closely associated with Ruby internals and even changes between different interpreters. This makes the resulting message very hard to impossible to unserialize messages generated by these classes in other environments like node.js.
This patch solves this by allowing you to set your own custom serializer and deserializer lambda functions. By default, it still uses Marshal to be backwards compatible.
|
| |
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
|
|
|
| |
This reverts commit 8b05c5207dd5757d55d0c384740db289e6bd5415.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
[#3195 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
| |
|
|
|
|
|
|
| |
Ruby's suite
This reverts commit 5de75398c495f109772b622291362a98bc6c21d1.
|
|
|
|
| |
Signed-off-by: Michael Koziarski <michael@koziarski.com>
|
| |
|
|
|
|
|
|
| |
Use a constant-time comparison algorithm to compare the candidate HMAC with the calculated HMAC to prevent leaking information about the calculated HMAC.
Signed-off-by: Michael Koziarski <michael@koziarski.com>
|
| |
|
| |
|
|
tamper-proof messages in cookies etc.
This is particularly useful for things like remember-me tokens in web applications and auto-unsubscribe links in emails.
|