Using variables on configuration (map?) for regex

[mostolog at gmail.com]

Hi
> Ok; I've read briefly about CAS, and I do not see how exactly the request
> gets from the client to nginx.
>
> But it sounds like the client does not have access to nginx directly;
> instead it talks "through" the CAS system which adds this http header
> to all requests.
You got the idea.

> That suggests that (a) nginx can entirely trust the content of the header;
> and also (b) potentially the access control could be handled by the CAS
> system instead of the nginx system.
>
> (b) is not something to worry about right now, but may be a path towards
> a solution if you cannot do what you want purely in nginx conf.
Our current implementation doesn't handle authorization but authentication.
That's in the TODO list..

> They are examples; but you do have (or have access to) the complete list
> of groups, methods, and locations that are allowed access, somewhere?
>
> See below...
Unfortunately not...at least not in an easy way. I could query LDAP for 
groups, but that is - IMHO - going too far.
Methods: HTTP, locations: yes, I have them on paper :P

> "That can't" refers to "that map directive will not work as you wish,
> because $myvar is not expanded in the first argument of each pair within
> the block".
That's a pitty.

>    map $request_method:$http_groups:$request_uri $denied {
>      default 1;
>      ~^GET:groupAll:/asdf 0;
>      ~^POST:groupFoo:/foo 0;
>      ~^POST:groupBar:/bar 0;
>      ~^DELETE:groupBonus:/foo 0;
>    }
That's similar to what I'm doing know...

    map $request_method:$http_groups:$request_uri $denied {
       default 1;
       ~^GET:gfoo:/foo 0;
       ~^GET:gbar:/bar 0;
       ...
       200 lines
       ...
       ~^POST:gfoo:/foo/create 0;
       ~^POST:gbar:/bar/create 0;
       ...
       200 lines
       ...
    }

...and that's why I was trying to reduce it to:

    map $request_method:$http_groups:$request_uri $denied {
       default 1;
       ~^GET:group$group:/$group 0;
       ~^POST:group$group:/$group/create 0;
       ...
       (a few more lines)
       ...
    }


> Perhaps your objection is related to you not wanting to write lots of
> config? (nginx doesn't care - it doesn't write the config.) Or you not
> wanting to read lots of config? (nginx is quite good at reading lots
> of config, even if it looks like mostly-duplicate boilerplate.) Or
> something else?
Number of human errors is directly proportional to the number of files 
you have to handle :P

> Ok, so assuming that that set of method:group:url-prefix is complete,
> I think I'm missing how it is not working with the previous suggestion.
It works...in the long/ugly form

> Perhaps include $server_name or $host in the "map" definition if you
> want to be explicit that (e.g) gfoo should not be able to GET /foo on
> bar.domain.com; only on foo.domain.com.
Already doing that, which makes rules appear like:

    map $request_method:$http_groups:$host:$request_uri $denied {
       default 1;
       ~^GET:gfoo:foo.domain.com:/foo 0;
       ~^GET:gbar:bar.domain.com:/bar 0;
       ...
       200 lines
       ...
       ~^POST:gfoo:foo.domain.com:/foo/create 0;
       ~^POST:gbar:bar.domain.com:/bar/create 0;
       ...
       200 lines
       ...
    }


> In nginx conf, a variable is a per-request expanded thing. A config-time
> expandable thing should use a macro processor to turn it into as many
> static things as are needed, and then let nginx read the static things.
>
> In some cases, someone has written the code to use a $variable in a
> directive. In the case of the "location" directive this has not happened,
> and I suspect will not happen, in stock nginx.
>
> What you are describing is, in nginx terms, the job of a macro
> processor. Use the one you already know to generate the bunch of similar
> rules. If the rules fragments are *identical*, you could use the nginx
> "include" directive, which is about the limit of the built-in "macro"
> processor. (That is to say: not a macro processor at all.)
Did I say it is a pitty?

>  From the words I've seen, this looks like it should work. If not, I'm
> happy to try guessing again.
I'm satisfied with my care:
You told me on the first message it can't work the way I was trying, so 
no more headaches
You pointed to some cosmetic changes/improvements on my config
You spent more time than deserved answering these questions.

So, thank you very much. I'll go for the "one long file" option 
duplicating a few lines for each
Have a great week,
Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160726/8c49156d/attachment.html>