martin,
what was the conclusion regarding your stale nonce param patch?
i would do it so that if www or proxy_authorize function returns -4 (stale nonce) then i would call www or proxy_challenge with stale flag on. it would then cause stale=true to be added to the header.
i don't understand why your patch calls pre_auth, since the request was already authenticated and it failed due to stale nonce.
-- juha
Juha Heinanen wrote:
what was the conclusion regarding your stale nonce param patch?
My plan was to eventually start a branch of my own in git. Haven't gotten round to it yet.
i would do it so that if www or proxy_authorize function returns -4 (stale nonce) then i would call www or proxy_challenge with stale flag on. it would then cause stale=true to be added to the header.
That would be an option, too, but IMHO it makes the whole authorization bit in the config unnecessarily messy. My idea was that if the nonce is stale, *_challenge just adds the stale flag. I only added the flag bit to maintain backwards compatibility (if you don't set it, the module behaves as it always did) and as a quick way out if my patch blows up.
i don't understand why your patch calls pre_auth, since the request was already authenticated and it failed due to stale nonce.
I use pre_auth to find the relevant auth_body_t which will include information whether the nonce was stale. This part should probably be factored out if we intend to use this patch or a derivate of it as the default behaviour.
Best regards, Martin
Martin Hoffmann writes:
My plan was to eventually start a branch of my own in git. Haven't gotten round to it yet.
i would do it so that if www or proxy_authorize function returns -4 (stale nonce) then i would call www or proxy_challenge with stale flag on. it would then cause stale=true to be added to the header.
That would be an option, too, but IMHO it makes the whole authorization bit in the config unnecessarily messy.
why is that? i now have,
if (!radius_proxy_authorize("$var(uri_domain)", "$var(uri_user)")) { switch ($rc) { ... case -4: xlog("L_INFO", "$rm <$ru> by <$var(uri)> has stale nonce\n"); www_challenge("$td", "1"); exit;
the only thing i would need to change is www_challenge flag parameter value from "1" to "9".
currently README says:
1.4.2. www_challenge(realm, flags) ... * flags - Value of this parameter can be a bitmask of following: + 1 - build challenge header with qop=auth + 2 - build challenge header with qop=auth-int + 4 - do not send '500 Internal Server Error' reply automatically in failure cases (error code is returned to config)
so i propose adding this:
+ 8 - build challenge header with stale=true
it would be a simple, fully backwards compatible new feature.
-- juha
Juha Heinanen wrote:
Martin Hoffmann writes:
My plan was to eventually start a branch of my own in git. Haven't gotten round to it yet.
i would do it so that if www or proxy_authorize function returns -4 (stale nonce) then i would call www or proxy_challenge with stale flag on. it would then cause stale=true to be added to the header.
That would be an option, too, but IMHO it makes the whole authorization bit in the config unnecessarily messy.
why is that? i now have,
if (!radius_proxy_authorize("$var(uri_domain)", "$var(uri_user)")) { switch ($rc) { ... case -4: xlog("L_INFO", "$rm <$ru> by <$var(uri)> has stale nonce\n"); www_challenge("$td", "1"); exit;the only thing i would need to change is www_challenge flag parameter value from "1" to "9".
Right. I can live with that. But just to illustrate my point, here is how my authentication part looks:
if (!proxy_authorize("$fd", "subcriber") { proxy_challenge("$fd", "9"); drop; }
I don't really see any reason why I would want the switch and cases when proxy_challenge() magically does what I want.
so i propose adding this:
+ 8 - build challenge header with stale=trueit would be a simple, fully backwards compatible new feature.
Okay. That would be a completely different albeit much simpler patch than mine.
Regards, Martin
Martin Hoffmann writes:
Right. I can live with that. But just to illustrate my point, here is how my authentication part looks:
if (!proxy_authorize("$fd", "subcriber") { proxy_challenge("$fd", "9"); drop; }
I don't really see any reason why I would want the switch and cases when proxy_challenge() magically does what I want.
operators using my proxy want to know why authentication fails. it is very useful information when some user complains that his/her ua is not able to authenticate and in bigger installations that happens quite often.
Okay. That would be a completely different albeit much simpler patch than mine.
can i go ahead and try to do it? if you want, you can then use flag "16" for whatever more complicated stuff.
-- juha
-
Juha Heinanen -
Martin Hoffmann