<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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.</pre>
</blockquote>
You got the idea.<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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.</pre>
</blockquote>
Our current implementation doesn't handle authorization but
authentication.<br>
That's in the TODO list..<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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...</pre>
</blockquote>
Unfortunately not...at least not in an easy way. I could query LDAP
for groups, but that is - IMHO - going too far.<br>
Methods: HTTP, locations: yes, I have them on paper :P<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">"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".</pre>
</blockquote>
That's a pitty.<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap=""> 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;
}</pre>
</blockquote>
That's similar to what I'm doing know...<br>
<blockquote>map $request_method:$http_groups:$request_uri $denied {<br>
default 1;<br>
~^GET:gfoo:/foo 0;<br>
~^GET:gbar:/bar 0;<br>
...<br>
200 lines<br>
...<br>
~^POST:gfoo:/foo/create 0;<br>
~^POST:gbar:/bar/create 0;<br>
...<br>
200 lines<br>
...<br>
}</blockquote>
...and that's why I was trying to reduce it to:<br>
<blockquote>map $request_method:$http_groups:$request_uri $denied {<br>
default 1;<br>
~^GET:group$group:/$group 0;<br>
~^POST:group$group:/$group/create 0;<br>
... <br>
(a few more lines)<br>
...<br>
}<br>
</blockquote>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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?</pre>
</blockquote>
Number of human errors is directly proportional to the number of
files you have to handle :P<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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.</pre>
</blockquote>
It works...in the long/ugly form<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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.</pre>
</blockquote>
Already doing that, which makes rules appear like:<br>
<blockquote>map $request_method:$http_groups:$host:$request_uri
$denied {<br>
default 1;<br>
~^GET:gfoo:foo.domain.com:/foo 0;<br>
~^GET:gbar:bar.domain.com:/bar 0;<br>
...<br>
200 lines<br>
...<br>
~^POST:gfoo:foo.domain.com:/foo/create 0;<br>
~^POST:gbar:bar.domain.com:/bar/create 0;<br>
...<br>
200 lines<br>
...<br>
}</blockquote>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">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.)</pre>
</blockquote>
Did I say it is a pitty?<br>
<br>
<blockquote cite="mid:20160725184217.GX12280@daoine.org" type="cite">
<pre wrap="">From the words I've seen, this looks like it should work. If not, I'm
happy to try guessing again.</pre>
</blockquote>
I'm satisfied with my care:<br>
You told me on the first message it can't work the way I was trying,
so no more headaches<br>
You pointed to some cosmetic changes/improvements on my config<br>
You spent more time than deserved answering these questions.<br>
<br>
So, thank you very much. I'll go for the "one long file" option
duplicating a few lines for each <br>
Have a great week,<br>
Regards<br>
<br>
</body>
</html>