1. 14 3月, 2018 1 次提交
  2. 18 2月, 2018 1 次提交
  3. 31 1月, 2018 1 次提交
  4. 29 11月, 2017 1 次提交
  5. 28 11月, 2017 1 次提交
  6. 26 10月, 2017 1 次提交
  7. 24 10月, 2017 1 次提交
  8. 09 10月, 2017 1 次提交
    • J
      redis-rb 4.0 support · 53c516d8
      Jeremy Daer 提交于
      * Use `gem 'redis', '~> 4.0'` for new app Gemfiles
      * Loosen Action Cable redis-rb dep to `>= 3.3, < 5`
      * Bump redis-namespace for looser Redis version dep
      * Avoid using the underlying `redis.client` directly
      * Use `Redis.new` instead of `Redis.connect`
      53c516d8
  9. 07 8月, 2017 1 次提交
  10. 06 7月, 2017 1 次提交
  11. 27 6月, 2017 1 次提交
  12. 30 4月, 2017 1 次提交
  13. 17 4月, 2017 1 次提交
  14. 22 3月, 2017 1 次提交
  15. 24 2月, 2017 1 次提交
  16. 22 1月, 2017 1 次提交
  17. 27 12月, 2016 1 次提交
  18. 13 11月, 2016 1 次提交
  19. 11 10月, 2016 1 次提交
    • M
      Permit same-origin connections by default · dae40447
      Matthew Draper 提交于
      WebSocket always defers the decision to the server, because it didn't
      have to deal with legacy compatibility... but the same-origin policy is
      still a reasonable default.
      
      Origin checks do not protect against a directly connecting attacker --
      they can lie about their host, but can also lie about their origin.
      Origin checks protect against a connection from 3rd-party controlled
      script in a context where a victim browser's cookies will be passed
      along. And if an attacker has breached that protection, they've already
      compromised the HTTP session, so treating the WebSocket connection in
      the same way seems reasonable.
      
      In case this logic proves incorrect (or anyone just wants to be more
      paranoid), we retain a config option to disable it.
      dae40447
  20. 28 9月, 2016 1 次提交
  21. 10 8月, 2016 1 次提交
  22. 09 7月, 2016 2 次提交
  23. 13 5月, 2016 1 次提交
  24. 10 5月, 2016 1 次提交
  25. 07 5月, 2016 1 次提交
  26. 28 4月, 2016 1 次提交
  27. 31 3月, 2016 1 次提交
    • J
      Cable message encoding · b168eb58
      Jeremy Daer 提交于
      * Introduce a connection coder responsible for encoding Cable messages
        as WebSocket messages, defaulting to `ActiveSupport::JSON` and duck-
        typing to any object responding to `#encode` and `#decode`.
      * Consolidate encoding responsibility to the connection. No longer
        explicitly JSON-encode from channels or other sources. Pass Cable
        messages as Hashes to `#transmit` and rely on it to encode.
      * Introduce stream encoders responsible for decoding pubsub messages.
        Preserve the currently raw encoding, but make it easy to use JSON.
        Same duck type as the connection encoder.
      * Revert recent data normalization/quoting (#23649) which treated
        `identifier` and `data` values as nested JSON objects rather than as
        opaque JSON-encoded strings. That dealt us an awkward hand where we'd
        decode JSON strings… or not, but always encode as JSON. Embedding
        JSON object values directly is preferably, no extra JSON encoding,
        but that should be a purposeful protocol version change rather than
        ambiguously, inadvertently supporting multiple message formats.
      b168eb58
  28. 30 3月, 2016 1 次提交
  29. 05 3月, 2016 1 次提交
  30. 03 3月, 2016 1 次提交
  31. 02 3月, 2016 1 次提交
  32. 01 3月, 2016 1 次提交
  33. 25 2月, 2016 3 次提交
  34. 04 2月, 2016 1 次提交
  35. 02 2月, 2016 2 次提交
  36. 21 1月, 2016 1 次提交