set_encrypt_session after access phase?

[Vader Mader]

On Thu, Jun 18, 2015 at 11:29 AM, Vader Mader <vade...@gmail.com> wrote:
>
> I'm having trouble setting a cookie conditionally based upon
> an upstream variable The hope is to cache an auth token in an
> encrypted session and only go to the backend auth token generator once.


I managed to figure out how to use map to set the cookie:

map $new_auth_tok $cond_cookie_k {
'' '';
default "my_login=";
}

map $new_auth_tok $cond_cookie_v {
'' '';
default $b32_session;
}

add_header Set-Cookie $cond_cookie_k$cond_cookie_v;

However, my problem is that set_encrypt_session actually runs in the
rewrite phase before my authentication back end like this:

location / {
root /var/www;
index index.html index.htm;

set_encrypt_session $enc_auth_tok $new_auth_tok;
set_encode_base32 $b32 $enc_auth_tok;

auth_request /auth;
auth_request_set $new_auth_tok $upstream_http_auth_tok;

add_header Set-Cookie $cond_cookie_k$cond_cookie_v;
}

Is there any way to encrypt after the access phase?

[Yichun Zhang (agentzh)]

Hello!

On Fri, Jun 19, 2015 at 10:20 PM, Vader Mader wrote:
> However, my problem is that set_encrypt_session actually runs in the
> rewrite phase before my authentication back end like this:
>
> location / {
> root /var/www;
> index index.html index.htm;
>
> set_encrypt_session $enc_auth_tok $new_auth_tok;
> set_encode_base32 $b32 $enc_auth_tok;
>
> auth_request /auth;
> auth_request_set $new_auth_tok $upstream_http_auth_tok;
>
> add_header Set-Cookie $cond_cookie_k$cond_cookie_v;
> }
>
> Is there any way to encrypt after the access phase?
>

Yes, but your configuration needs a rework with a little bit of Lua.

Basically you can use the access_by_lua or access_by_lua_file
directive to replace your auth_request* and set_decrypt_session
directives in that location. The ndk.set_var.DIRECTIVE API [1]
provided by Lua can be used to invoke the set_decrypt_session and
set_decode_base32 directives directly from within Lua. And you can
mimic auth_request with ngx.location.capture() [2] for example, for
better, directly re-implement the logic in location /auth directly to
save the overhead of a subrequest (initiated by auth_request or
ngx.location.capture).

With the help of Lua, you don't have to fight nginx directives'
running orders and you have the full scripting capabilities at the
same time with little extra overhead.

Regards,
-agentzh

[1] https://github.com/openresty/lua-nginx-module#ndkset_vardirective
[2] https://github.com/openresty/lua-nginx-module#ngxlocationcapture

[Yichun Zhang (agentzh)]

Hello!

On Sat, Jun 20, 2015 at 9:54 PM, Yichun Zhang (agentzh) wrote:
> Yes, but your configuration needs a rework with a little bit of Lua.
>

Oh, BTW, please do not cross-post to both nginx and openersty-en
mailing lists. Choose one or the other (though for this question,
openresty-en is recommended, but still, it's your own decision to
make). Many people subscribe to both and seeing your duplicate mails
in different places is a bit annoying. Thanks for your cooperation!

Best regards,
-agentzh

[Vader Mader]

Thanks for your reply.

Is there any way to combine auth_request and xxx_by_lua?
My thought was to limit Lua overhead unless new token is
issued.

I experimented with something like the following but the
Lua code always seems to run but variables set in the script
aren't returned.

location = /auth {
set_decode_base32 $b32 $cookie_my_login;
set_decrypt_session $auth_tok $b32;

if ($auth_tok != '') {
return 200;
}

include fastcgi_params;
fastcgi_pass unix:/tmp/fcgi_auth_tok_gen.sock;

access_by_lua '
local enc = ngx.set_var.set_encrypt_session(new_auth_tok)
local b32 = ngx.set_var.set_encode_base32(enc)
...
';
}

[Yichun Zhang (agentzh)]

Hello!

On Sat, Jun 20, 2015 at 11:50 PM, Vader Mader wrote:
>
> Is there any way to combine auth_request and xxx_by_lua?

It seems to me that you didn't read my previous mail carefully enough? To quote:

"And you can mimic auth_request with ngx.location.capture() [2] for example, for
better, directly re-implement the logic in location /auth directly to
save the overhead of a subrequest (initiated by auth_request or
ngx.location.capture)."

> My thought was to limit Lua overhead unless new token is
> issued.
>

It's not really worth it, to be honest. You can benchmark the real
setup yourself.

> I experimented with something like the following but the
> Lua code always seems to run but variables set in the script
> aren't returned.
>

The set_xxx directives always run before access_by_lua.

Also try your best to avoid the "if" directive whenever possible
because it is evil:

http://wiki.nginx.org/IfIsEvil

It's much safer and cleaner to use Lua's own "if" statement.

If you really want to mess up with the nginx.conf scripting stuff,
ensure you're armed with enough knowledge to save both your and our
time:

https://openresty.org/#eBooks

http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html

Regards,
-agentzh

[Yichun Zhang (agentzh)]

Hello!

On Sun, Jun 21, 2015 at 12:03 AM, Yichun Zhang (agentzh) wrote:
>> My thought was to limit Lua overhead unless new token is
>> issued.
>
> It's not really worth it, to be honest. You can benchmark the real
> setup yourself.
>

You may see a real gain (maybe really significant) if you rewrite your
fastcgi backend's logic in Lua and make everything run inside nginx.
The fastcgi overhead is usually orders of magnitude bigger than the
boilerplate overhead of your Lua handlers.

Regards,
-agentzh

[Vader Mader]

On Sat, Jun 20, 2015 at 12:03 PM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> ensure you're armed with enough knowledge to save both your and our
> time:

Sorry to waste your time by asking a question.