Reuse Redis connection in allow_domain method about lua-resty-auto-ssl HOT 8 CLOSED

Well, better late than never, but this should finally be easier in the v0.12.0 release. You can now access the redis connection via auto_ssl.storage.adapter:get_connection(), and the auto_ssl instance is passed as the second argument to the allow_domain callback. Thanks for the idea!

from lua-resty-auto-ssl.

Not a dumb question at all!

You could establish a new redis connection inside the allow_domain callback, but it doesn't look like we have a super-easy way to reuse the same Redis connection that the storage mechanism would already have instantiated. But I think that's a good idea, so we could certainly look at ways to better expose that part of the storage API to the allow_domain callback for a future release (or pull requests are always welcome).

In the meantime, here's a workaround that I think might work to allow you to leverage the same connection in both places:

local function get_redis_instance(redis_options)
  local instance = ngx.ctx.auto_ssl_redis_instance
  if instance then
    return instance
  end

  instance = redis:new()
  local ok, err

  if redis_options["socket"] then
    ok, err = instance:connect(redis_options["socket"])
  else
    ok, err = instance:connect(redis_options["host"], redis_options["port"])
  end
  if not ok then
    return false, err
  end

  if redis_options["auth"] then
    ok, err = instance:auth(redis_options["auth"])
    if not ok then
      return false, err
    end
  end

  ngx.ctx.auto_ssl_redis_instance = instance
  return instance
end

auto_ssl = (require "resty.auto-ssl").new()
local redis_options = {
  host = "10.10.10.1"
}
auto_ssl:set("redis", redis_options)
auto_ssl:set("allow_domain", function(domain)
  local redis_instance, instance_err = get_redis_instance(redis_options)
  if instance_err then
    return nil, instance_err
  end

  local res, err = redis_instance:get("WHATEVER...")
  -- Do whatever else you need with redis_instance.
end)
auto_ssl:init()

It's a bit ugly, but basically I'm just copying the private get_redis_instance method out of the Redis storage adapter: https://github.com/GUI/lua-resty-auto-ssl/blob/v0.10.3/lib/resty/auto-ssl/storage_adapters/redis.lua#L5-L32 Since both functions will cache the redis connection on the ngx.ctx.auto_ssl_redis_instance context variable, then which ever version of get_redis_instance gets called first should be the only one that actually establishes a connection.

But again, I think providing a cleaner way to get at this connection object directly from the storage API would be better long term.

from lua-resty-auto-ssl.

Thanks for this! I'll check it out.

from lua-resty-auto-ssl.

Hey @GUI , has anything been done to enable this ?

from lua-resty-auto-ssl.

@aviatrix I don't know of any changes regarding this. Right now nobody knows what reusing that object would even look like, for a users point of view. Is there an interface idea you'd like to work out and propose? I'll be glad to give you some pointers on how to implement it.

from lua-resty-auto-ssl.

@luto Right now i've settled for the get_redis_instance example given by @GUI in the comments above, however that is sub optimal in my opinion. On first thought maybe exposing the get_redis_instance as public static method should suffice so we can call that function inside the auto_ssl like this : auto_ssl:get_redis_instance(). I'm not familiar with Lua or how it works or if this is even possible.

from lua-resty-auto-ssl.

One small caveat : if you don't put local redis = require "resty.redis" on the top of init_by_lua_block there is a chance it will blow up when trying to init redis :)

from lua-resty-auto-ssl.

@GUI Is it possible to get to ssl_options through the auto_ssl instance? Thanks!

from lua-resty-auto-ssl.