27 May
2011
27 May
'11
3:41 p.m.
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
28 May
28 May
2:21 a.m.
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
2:35 a.m.
Martin Hoffmann writes:
My plan was to eventually start a branch of my own in
git. Haven't
gotten round to it yet.
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
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.
2:54 a.m.
Juha Heinanen wrote:
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.
My plan was to eventually start a branch of my
own in git. Haven't
gotten round to it yet.
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". 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. so i propose adding this:
+ 8 - build challenge header with stale=true
it would be a simple, fully backwards compatible new feature.
Okay. That would be a completely different albeit much simpler patch
than mine.
Regards,
Martin
3:11 a.m.
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
4968
days inactive
4969
days old
6 comments
2 participants
participants (2)
-
Juha Heinanen -
Martin Hoffmann