Update Reply returns noop

[Anastasios Gryponisiotis]

I will probably create my own dictionary with custom made attributes for
these, thank you. There are multiple ifs to give me more control, and each
of the contains a "else" to reject all that does not match.

The first "if" is the only one that doesn't have a catch-all "else" yet, as
I am still testing the cascade.

With all these responses however, we still have not adressed the fact that
the update reply in my first "if" returns noop and therefore does not stop
processing right then and there. Am I wrong to assume that since the reply
is acted upon it should not return noop? This is what all my other if/else
conditionals are already doing. Instead I get a reject from a "else"
further down the conditionals.

Thanks,
AG

On Mon, Jul 25, 2016 at 5:39 PM Matthew Newton <mcn4 at leicester.ac.uk> wrote:

> On Mon, Jul 25, 2016 at 03:04:21PM +0000, Anastasios Gryponisiotis wrote:
> > What I am trying to achieve, and have so far been sucesfull, is to have
> > groups of users and NAS groups (using regex). I then use unlang to create
> > conditionals in order to accept/reject/update reply items accordingly.
> >
> > I use this to specify different access levels using Cisco-AV-Pair values
> > and to allow users of some groups to access some NASes and not others.
> This
> > is all running in post_auth and works fine.
> >
> > Anything that is not matching withing the if conditionals is trickled
> down
> > to a "catch-all" else that rejects the request.
>
> That's a much more useful explanation.
>
> > Now I want some of these users to also be able to access VPNs to specific
> > sites. So I am trying to use a Reply item of "Realm" to match the
> > NAS-Identifier of the VPN endpoints. Unfortunately, even though the
>
> Realm and NAS-Identifier are normally in the request, so this is a
> bit of an odd use-case, but OK.
>
> You can create your own attributes for this sort of thing if you
> want.
>
> I'd put them in the control list rather than the reply so that
> they never get sent back to the client.
>
> > conditional matched this, it returns noop, therefore evaluation is
> > continuing to match another conditional, until it is rejected  by the
> > "catch-all"
> > else statement at the end.
>
> Well, if you want to reject there, then adding "reject" is a
> perfectly acceptable way to do it.
>
> Otherwise I would probably look at options involving another
> attribute or two that set whether the user should be rejected or
> not, then reject based on that.
>
> So you could create new attributes, Reject-Switch and Reject-VPN,
> then do something like
>
> update control {
>   Reject-Switch := 1
>   Reject-VPN := 1
> }
>
> if (...) {
>   # set of if to see if user is OK on switch
>
>   update control {
>     Reject-Switch := 0
>   }
> }
>
> if (...) {
>   # set of if to see if user is OK on vpn
>
>   update control {
>     Reject-VPN := 0
>   }
> }
>
>
> if (&control:Reject-VPN || &control:Reject-Switch) {
>   reject
> }
>
>
> That should pull the logic apart and make it easier to control
> what is happening along the way.
>
> When you end up with a
>
> if (a) {
>  ..
> }
> elsif (b) {
>  ..
> }
> elsif (c) {
>  ..
> }
> else {
>   reject
> }
>
> it makes it very hard sometimes to not hit the reject at the end
> as you get further down the list of ifs and something is OK if
> it's a and c but not b, for example.
>
> Matthew
>
>
> --
> Matthew Newton, Ph.D. <mcn4 at leicester.ac.uk>
>
> Systems Specialist, Infrastructure Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>
> For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html