auth_mode = 0 - normal authentication
auth_mode = 1 - transparent authentication
Passes authentication from one to another side thorough b2b.
Controlling auth mode globally (via a module param) is a little bit restrictive.
I would prefer having a variable the will will be set before initiating the b2b call. This will allow both authentication modes to coexist on the same server.
What do you think about change b2b_init_request parameters?
First - scenario
Second - FLAGS (I think it will be useful in future)
Third-Sixth - scenario params
And make first flag to manage authentication mode?
I would prefer a variable to be set.
Even if auth mode would be controlled as a parameter for b2b_init_request, it must accept pvars and the work is pretty much there. Also, inserting a param in the middle of existing ones, will break forward compatibility (old scripts will no longer work with new opensips versions).
What do you think about new command, like b2b_set_flags("flags")?
I think that there are more than one option (flag) will be needed in future.
b2b_set_flags("T"); # transparent authentication
I think it would be better than just a variable.
I agree with Ovidiu on both things - it should not be a global option and it should be backward compatible.
The only options I see here is either use a kind of module variable to set the flags before the init:
$b2b_flags = xxxxxx ;
or as Nick suggested, with a function, to do more or less the same.
Another approach may be to quiz the flags in the first param, using a separator - this will be backward compat. Like:
Wow! I think flags in the first param is the best solution!
If we want this functionality implemented as a flag, then it shouldn't be passed as an extension to the first parameter because:
- it's an awkward syntax
- and it's really messy when you want to pass more flags.
Best thing would be to set up the flag(s) before calling b2b_init_request and leave the syntax for b2b_init_request as is.
Okay, let it be separate command and one-character flags.
A - Enable transparent authentication
b2b_set_mode("AxSZ"); // For example
I've added per b2b session flags. And the first flag - "a" for transparent authentication.
It affects only this b2b session.
The new patch attached in file opensips_b2b_transp_auth_v2.patch file.
Also I attached opensips_b2b_lumpsbug_v2.patch that fixes lumps bug when opensips_b2b_transp_auth_v2.patch and opensips_b2b_lumps.patch (#3519778) applied together.
I've added updated version with fixed bug in late variables initialization. opensips_b2b_transp_auth_v3.patch It's production patch now.
Nick, sorry for this going back and forward on how this feature should be implemented . On my side, the final decision is have the flags in the first parameter (like b2b2_init_request("my_scenario/flags","",""); ) and not to add any new functions.
Reasons: simplicity in usage and in coding.
Let me know if you are willing to rework (again :D) the patch.
Of course, I'll change it.
The new patch (v4).
And small patch for doc - opensips_b2b_transp_auth_v4_doc.patch
I have looked also at this patch and my question is - is this patch really needed?
What you are trying to achieve is to patch the authentication headers from one part to another, right?
Have you tried putting in the custom_headers module parameter the authentication headers? Something like:
modparam("b2b_logic", "custom_headers", "Proxy-Authorization|Proxy-Authenticate")
I think I have tried this at some point and it was working.
Hmm, it really works. I made patch because it doesn't work for me earlier.
Anca, where were you 5 months ago? :-)
Now it works for me with
modparam("b2b_logic", "custom_headers", "WWW-Authenticate;Authorization")
Possible it was bug, I think it fixed in commit number 9088.
In my first patch was the same fix as in commit 9088.
I did'nt try custom_headers param after my first (v1) patch.
Ticket may be closed, but please, apply this small fixes to the documentation:
- Then it can take at most 4 other parameters that represent the parameters for
+ Then it can take at most 5 other parameters that represent the parameters for
the xml scenario. The expected number of parameters is also specified as an attribute
- If you have a multi interface setup and want to chance the outbound interface,
+ If you have a multi interface setup and want to change the outbound interface,
So this patch should be reworked just to offer the generic support for flags (which is used by the other patches) ?
I'll include this support in #3520528, when I'll rewrite it. (It also depends on #3516387).
I don't know any other patches that require flags support, except #3520528.
I think that there is no need to include flags support into b2b_logic module when this support is not used (yet), isn't it?
I think there is a corner case where flags might be used.
If the b2b modules are loaded with authentication support, then the modules will try to authenticate if credentials are found and if not, the challenge will be passed upstream.
If we want to always force the upstream authentication, we might use a flag.
But again, this is a corner case when local authentication is used/mixed with remote authentication.
Thanks for reworking the patch, I uploaded it on svn.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.