Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP.

[Axel Luttgens]

(This is a first reaction. I'll reply a bit more seriously as soon as I have the opportunity. In the meantime, thanks for re-reading the whole thread and, possibly, the previous ones as well)

Le 10 sept. 2014 à 14:08, Alan DeKok a écrit :

> Axel Luttgens wrote:
>> In fact, I wasn't surprised by those roundtrips, but by the hardcoded behavior of the eap module: to return a noop in that precise case.
> 
> The fact that modules have specific return codes is surprising?

Yes, of course!
When writing a piece of code, I never care of return codes: they are just un-meaningful data returned for the sake of perturbing programmers. No more, no less.
I feel sooo good for having my prose so well understood.


> Would you expect them to have random return codes?  

Try to upgrade your OS, or to ask Google for a precise info; the randomness of the results is more than often somehow perturbing.
On the other hand, deliberately add randomness in your code: the user now knows that the random outcome is deliberate, and thus feels much better. And, thanks to the programmer's wisdom and for our relief, entropy is in fact decreasing.
So, yes, I clearly wish modules had random return codes.


> Or to return the same code no matter what happens?

From the point of view of entropy, that wouldn't be very useful.
On the other hand, returning systematically the same code might be reassuring; but then, returning no code at all, as I sure clearly stated in some of my earlier posts, would be faaaar easier: nothing to worry anymore.


>> After all, it has done "something", by recognizing the request as an EAP one but then taking the decision to not interfere with a subsequent proxy operation; in some sense, it has taken over the request.
>> I was thus wondering whether a noop was the most appropriate return code; on the other hand, I had a doubt, because I could also have induced it myself, by some misconfiguration.
> 
> If you read the eap module configuration, there is *nothing* which
> says "change the return code".  So you *cannot* make it return "noop" by
> some misconfiguration.

Who said I tried to explicitly and specifically change eap module's return code?
This isn't possible, since it's a module, hence magical (and random).


> It sounds like you think the modules are magic.  They're not.

Aren't they magic?
I'm feeling sooo disappointed now.
You are cheating, aren't you?
They *must* be magic.
Otherwise, they couldn't be modules.


>> Incidentally, may that "# complex DB stuff here" just be an invocation of the sql module? As in:
> 
> It can be whatever you want.  i.e. things to do when NOT using EAP.
> That's sort of what I said.

Sort of...
Do you mean randomness?
(sorry, can't be serious here, since the present post is voluntarily a biased one)


>> It seems to work, but aren't there some side-effects to be expected?
> 
> There are no magical side-effects.  Pretty much all of the server
> behavior is explicit.

No magic thus.
Feeling sooo disappointed.


>> Finally, there's the problem of logging.
>> I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt...
>> Which kind of criterion, if any, could be easily used for writing one line per connection only?
> 
> See the post-auth section.  That's what it's for.

You see?
Plain magic: auth_log in the authorize section is supposed, by default, to be meaningful, a linelog instance in that same section, is just plain nonsense.
Must be a matter of some module not returning a random code.


> And it's documented, too.

Yeah, and I think I even managed to have that part working without too much randomness.
That must be the least magical piece of the whole affair, and thus the least interesting one.


Axel