1. 17 Apr, 2023 1 commit
    • Binbin's avatar
      Fix the bug that CLIENT REPLY OFF|SKIP cannot receive push notifications (#11875) · 7afd1724
      Binbin authored
      This bug seems to be there forever, CLIENT REPLY OFF|SKIP will
      mark the client with CLIENT_REPLY_OFF or CLIENT_REPLY_SKIP flags.
      With these flags, prepareClientToWrite called by addReply* will
      return C_ERR directly. So the client can't receive the Pub/Sub
      messages and any other push notifications, e.g client side tracking.
      
      In this PR, we adding a CLIENT_PUSHING flag, disables the reply
      silencing flags. When adding push replies, set the flag, after the reply,
      clear the flag. Then add the flag check in prepareClientToWrite.
      
      Fixes #11874
      
      Note, the SUBSCRIBE command response is a bit awkward,
      see https://github.com/redis/redis-doc/pull/2327
      
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      (cherry picked from commit 416842e6)
      (cherry picked from commit f8ae7a41)
      7afd1724
  2. 26 Mar, 2021 1 commit
    • Huang Zhw's avatar
      make processCommand check publish channel permissions. (#8534) · e138698e
      Huang Zhw authored
      Add publish channel permissions check in processCommand.
      
      processCommand didn't check publish channel permissions, so we can
      queue a publish command in a transaction. But when exec the transaction,
      it will fail with -NOPERM.
      
      We also union keys/commands/channels permissions check togegher in
      ACLCheckAllPerm. Remove pubsubCheckACLPermissionsOrReply in 
      publishCommand/subscribeCommand/psubscribeCommand. Always 
      check permissions in processCommand/execCommand/
      luaRedisGenericCommand.
      e138698e
  3. 28 Feb, 2021 1 commit
    • Viktor Söderqvist's avatar
      Shared reusable client for RM_Call() (#8516) · 6122f1c4
      Viktor Söderqvist authored
      A single client pointer is added in the server struct. This is
      initialized by the first RM_Call() and reused for every subsequent
      RM_Call() except if it's already in use, which means that it's not
      used for (recursive) module calls to modules. For these, a new
      "fake" client is created each time.
      
      Other changes:
      * Avoid allocating a dict iterator in pubsubUnsubscribeAllChannels
        when not needed
      6122f1c4
  4. 17 Feb, 2021 1 commit
  5. 04 Jan, 2021 1 commit
    • Itamar Haber's avatar
      HELP subcommand, continued (#5531) · 9dcdc7e7
      Itamar Haber authored
      
      
      * man-like consistent long formatting
      * Uppercases commands, subcommands and options
      * Adds 'HELP' to HELP for all
      * Lexicographical order
      * Uses value notation and other .md likeness
      * Moves const char *help to top
      * Keeps it under 80 chars
      * Misc help typos, consistent conjuctioning (i.e return and not returns)
      * Uses addReplySubcommandSyntaxError(c) all over
      Signed-off-by: default avatarItamar Haber <itamar@redislabs.com>
      9dcdc7e7
  6. 01 Dec, 2020 1 commit
    • Itamar Haber's avatar
      Adds pub/sub channel patterns to ACL (#7993) · c1b1e8c3
      Itamar Haber authored
      Fixes #7923.
      
      This PR appropriates the special `&` symbol (because `@` and `*` are taken),
      followed by a literal value or pattern for describing the Pub/Sub patterns that
      an ACL user can interact with. It is similar to the existing key patterns
      mechanism in function (additive) and implementation (copy-pasta). It also adds
      the allchannels and resetchannels ACL keywords, naturally.
      
      The default user is given allchannels permissions, whereas new users get
      whatever is defined by the acl-pubsub-default configuration directive. For
      backward compatibility in 6.2, the default of this directive is allchannels but
      this is likely to be changed to resetchannels in the next major version for
      stronger default security settings.
      
      Unless allchannels is set for the user, channel access permissions are checked
      as follows :
      * Calls to both PUBLISH and SUBSCRIBE will fail unless a pattern matching the
        argumentative channel name(s) exists for the user.
      * Calls to PSUBSCRIBE will fail unless the pattern(s) provided as an argument
        literally exist(s) in the user's list.
      
      Such failures are logged to the ACL log.
      
      Runtime changes to channel permissions for a user with existing subscribing
      clients cause said clients to disconnect unless the new permissions permit the
      connections to continue. Note, however, that PSUBSCRIBErs' patterns are matched
      literally, so given the change bar:* -> b*, pattern subscribers to bar:* will be
      disconnected.
      
      Notes/questions:
      * UNSUBSCRIBE, PUNSUBSCRIBE and PUBSUB remain unprotected due to lack of reasons
        for touching them.
      c1b1e8c3
  7. 17 Nov, 2020 1 commit
    • Meir Shpilraien (Spielrein)'s avatar
      Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025) · d87a0d02
      Meir Shpilraien (Spielrein) authored
      
      
      Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
      the caller, who executes the command in this context, expects a reply.
      
      Today, LUA and MULTI have a special (and different) treatment to blocking commands:
      
      LUA   - Most commands are marked with no-script flag which are checked when executing
      and command from LUA, commands that are not marked (like XREAD) verify that their
      blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
      MULTI - Command that is going to block, first verify that the client is not inside
      multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
      return a result which is a match to the empty key with no timeout (for example blpop
      inside MULTI will act as lpop)
      For modules that perform RM_Call with blocking command, the returned results type is
      REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
      
      Disadvantages of the current state are:
      
      No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
      Module can not safely execute blocking command (and get reply or error).
      Though It is true that modules are not like LUA or MULTI and should be smarter not
      to execute blocking commands on RM_Call, sometimes you want to execute a command base
      on client input (for example if you create a module that provides a new scripting
      language like javascript or python).
      While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
      REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
      check if the command came from another module using RM_Call. So there is no way
      for a module to know not to block another module RM_Call execution.
      
      This commit adds a way to unify the treatment for blocking clients by introducing
      a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
      turned on to signify that the client should not be blocked. A blocking command
      verifies that the flag is turned off before blocking. If a blocking command sees
      that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
      which are matches to empty key with no timeout (as MULTI does today).
      
      The new flag is checked on the following commands:
      
      List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
      Zset blocking commands: BZPOPMIN, BZPOPMAX
      Stream blocking commands: XREAD, XREADGROUP
      SUBSCRIBE, PSUBSCRIBE, MONITOR
      In addition, the new flag is turned on inside the AOF client, we do not want to
      block the AOF client to prevent deadlocks and commands ordering issues (and there
      is also an existing assert in the code that verifies it).
      
      To keep backward compatibility on LUA, all the no-script flags on existing commands
      were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
      
      To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
      We added a special treatment on those commands to allow executing them on MULTI.
      
      The only backward compatibility issue that this PR introduces is that now MONITOR
      is not allowed inside MULTI.
      
      Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
      or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      Co-authored-by: default avatarItamar Haber <itamar@redislabs.com>
      d87a0d02
  8. 10 Feb, 2020 1 commit
  9. 09 Jan, 2019 5 commits
  10. 02 Jul, 2018 1 commit
  11. 09 Jun, 2018 1 commit
  12. 07 Jun, 2018 1 commit
  13. 01 Mar, 2018 1 commit
    • 伯成's avatar
      Boost up performance for redis PUB-SUB patterns matching · dfb12f06
      伯成 authored
      If lots of clients PSUBSCRIBE to same patterns, multiple pattens matching will take place. This commit change it into just one single pattern matching by using a `dict *` to store the unique pattern and which clients subscribe to it.
      dfb12f06
  14. 06 Dec, 2017 1 commit
    • antirez's avatar
      Change indentation and other minor details of PR #4489. · 522760fa
      antirez authored
      The main change introduced by this commit is pretending that help
      arrays are more text than code, thus indenting them at level 0. This
      improves readability, and is an old practice when defining arrays of
      C strings describing text.
      
      Additionally a few useless return statements are removed, and the HELP
      subcommand capitalized when printed to the user.
      522760fa
  15. 28 Nov, 2017 1 commit
    • Itamar Haber's avatar
      Standardizes the 'help' subcommand · 59d52f7f
      Itamar Haber authored
      This adds a new `addReplyHelp` helper that's used by commands
      when returning a help text. The following commands have been
      touched: DEBUG, OBJECT, COMMAND, PUBSUB, SCRIPT and SLOWLOG.
      
      WIP
      
      Fix entry command table entry for OBJECT for HELP option.
      
      After #4472 the command may have just 2 arguments.
      
      Improve OBJECT HELP descriptions.
      
      See #4472.
      
      WIP 2
      
      WIP 3
      59d52f7f
  16. 27 Jul, 2015 1 commit
  17. 26 Jul, 2015 3 commits
  18. 08 Aug, 2014 1 commit
  19. 16 Jul, 2014 1 commit
    • antirez's avatar
      PubSub clients refactoring and new PUBSUB flag. · 59cf0824
      antirez authored
      The code tested many times if a client had active Pub/Sub subscriptions
      by checking the length of a list and dictionary where the patterns and
      channels are stored. This was substituted with a client flag called
      REDIS_PUBSUB that is simpler to test for. Moreover in order to manage
      this flag some code was refactored.
      
      This commit is believed to have no effects in the behavior of the
      server.
      59cf0824
  20. 20 Mar, 2014 1 commit
  21. 10 Feb, 2014 1 commit
  22. 21 Jun, 2013 1 commit
    • antirez's avatar
      New API to force propagation. · 515a26bb
      antirez authored
      The old REDIS_CMD_FORCE_REPLICATION flag was removed from the
      implementation of Redis, now there is a new API to force specific
      executions of a command to be propagated to AOF / Replication link:
      
          void forceCommandPropagation(int flags);
      
      The new API is also compatible with Lua scripting, so a script that will
      execute commands that are forced to be propagated, will also be
      propagated itself accordingly even if no change to data is operated.
      
      As a side effect, this new design fixes the issue with scripts not able
      to propagate PUBLISH to slaves (issue #873).
      515a26bb
  23. 20 Jun, 2013 2 commits
    • antirez's avatar
      Allow PUBSUB NUMSUB without channels. · 519c9e11
      antirez authored
      The result is an empty list but it is handy to call it programmatically.
      519c9e11
    • antirez's avatar
      PUBSUB command implemented. · 455563fa
      antirez authored
      Currently it implements three subcommands:
      
      PUBSUB CHANNELS [<pattern>]    List channels with non-zero subscribers.
      PUBSUB NUMSUB [channel_1 ...]  List number of subscribers for channels.
      PUBSUB NUMPAT                  Return number of subscribed patterns.
      455563fa
  24. 06 Mar, 2013 1 commit
  25. 21 Jan, 2013 1 commit
    • antirez's avatar
      UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply. · 2039f1a3
      antirez authored
      UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe
      the client respectively all the channels and patters if called without
      arguments.
      
      However when these functions are called without arguments, but there are
      no channels or patters we are subscribed to, the old behavior was to
      don't reply at all.
      
      This behavior is broken, as every command should always reply.
      Also it is possible that we are no longer subscribed to a channels but we
      are subscribed to patters or the other way around, and the client should
      be notified with the correct number of subscriptions.
      
      Also it is not pretty that sometimes we did not receive a reply at all
      in a redis-cli session from these commands, blocking redis-cli trying
      to read the reply.
      
      This fixes issue #714.
      2039f1a3
  26. 19 Jan, 2013 1 commit
  27. 08 Nov, 2012 1 commit
  28. 04 Feb, 2012 1 commit
  29. 08 Nov, 2011 1 commit
  30. 07 Oct, 2011 1 commit
  31. 04 Oct, 2011 1 commit
  32. 25 May, 2011 1 commit
  33. 17 Oct, 2010 1 commit