Using variables on configuration (map?) for regex

[mostolog at gmail.com]

Hi

> The quick question/answer from the Subject line:
>
> if you are asking: how do I use a $variable in the "does this match" part
> of a "map"; the answer is "you don't". $ is either a literal character
> (in a string), or the end-of-string metacharacter (in a regex).
Thank you for your clear and concise answer. I wouldn't summarize it 
better, both question and answer.

> (Your example suggests that your client will send a http header "Groups:
> gfoo" if this request should be handled as if this user is in the group
> gfoo. Perhaps you are using a special client configuration where that
> is true?)
We're using Apereo CAS. The "grouplist" header comes from a trusted 
server after user successfully authenticated.

> Is the "foo" in each of "group gfoo", "group adminfoo", "url foo" always
> identical? As in: can simple pattern-matching work, or do you need an
> extra mapping somewhere to tie the names together?
Basically, users belongs to groups. Some groups have access to certain 
operations (GET, PUT, POST, DELETE) on certain URLs.

> Is the /page/bar here the same as the /page/bar in the "foo" section? Or
> is the "bar" in /page/bar here the same as the "bar" in /content/bar here?
>
> Possibly it does not matter; but if it does not matter it should probably
> not be in the question.
These were just examples (that seems to confuse more than help) trying 
to detail the scenario:
     "There are rules to allow some groups to do specific actions on 
certain URLs". eg:

  * groupAll can GET on /asdf
  * groupFoo can POST on /foo
  * groupBar can POST on /bar
    (again, names and locatiosn are just examples)
  * groupBonus can DELETE on /foo


> These map directives look wrong to me.
>
> It looks like you should have the $request_uri bit at the end of the
> "match against this" expansion, since you presumably want /content/bar
> and /content/bar/something both to match the same way.
I was using .*, but your approach seems better.

> And it's not clear to me why you have multiple "map" directives. One
> that sets the single variable "$denied_group" looks like it should
> be enough. One "default" line; two lines per "foo" or "bar". What am
> I missing?
Again, you're right.


>>     map $request_method:$request_uri:$http_groups $denied {
>>          default 1;
>>          ~^GET:/content/$myvar:g$myvar 0;
>>          ~^POST:/content/$myvar:admin$myvar 0;
>>     }
> That can't. You would need two lines per "myvar" value -- but since
> you must have the list of myvar values somewhere, you should be able to
> auto-generate these lines from that list.
I didn't understand that.


> If the problem is "lots of files", then you could concatenate them all
> in to one file.
A kitty just died somewhere.


>  From the question, it is not not clear to me whether a user in group gbar
> should have any access at all to the server foo.domain.com. And it is
> not clear to me whether there is anything else available below /content/
> other than /content/foo/, in the server foo.domain.com.
I'm sorry I wasn't able to be more clear.

foo.domain.com GET on certain URLs should be allowed for gfoo, gfoobar 
and gAdmin groups
while POST on specific URLs, can be only executed by gfoo and gAdmin
DELETE on some URLs only by gAdmin
otherwise default is denied

bar.domain.com share the "same" rules...the same way like 
asdf.domain.com, qwerty.domain.com and iloveyou.docmain.com

And here is it where I would like to use $variable, instead of copying a 
bunch of rules for each domain.

> Would a configuration along the lines of
>
> ==
>    server {
>      location /content/ {
>        if ($denied_group) {
>          return 403 "Forbidden";
>        }
>        ...
>      }
>      location ~ /page/bar/action...and ~10 locations more per server...
>    }
> ==
>
> do what you want?
No, as it doesn't include the method POST/GET part, neither the groups 
allowed for each URL.

Thanks a lot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160725/1c0b1be1/attachment.html>