Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#218 B2B_LOGIC - transparent authentication

trunk
closed-accepted
modules (179)
5
2013-01-23
2012-04-10
Nick Altmann
No

New option:
auth_mode = 0 - normal authentication
auth_mode = 1 - transparent authentication

Passes authentication from one to another side thorough b2b.

Discussion

1 2 3 > >> (Page 1 of 3)
  • Ovidiu Sas
    Ovidiu Sas
    2012-04-10

    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.

     
  • Nick Altmann
    Nick Altmann
    2012-04-10

    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?

     
  • Ovidiu Sas
    Ovidiu Sas
    2012-04-10

    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).

     
  • Nick Altmann
    Nick Altmann
    2012-04-16

    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.

    Something like:
    b2b_set_flags("T"); # transparent authentication
    b2b_init_request("top hiding");

    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:
    b2b2_init_request("my_scenario","","");
    ->
    b2b2_init_request("my_scenario/flags","","");

    Regards,
    Bogdan

     
  • Nick Altmann
    Nick Altmann
    2012-04-20

    Wow! I think flags in the first param is the best solution!

     
  • Ovidiu Sas
    Ovidiu Sas
    2012-04-21

    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.

    Regards,
    Ovidiu Sas

     
  • Nick Altmann
    Nick Altmann
    2012-04-21

    Okay, let it be separate command and one-character flags.

    Like
    b2b_set_mode("A");
    A - Enable transparent authentication

    b2b_set_mode("AxSZ"); // For example

     
  • Nick Altmann
    Nick Altmann
    2012-04-23

    I've added per b2b session flags. And the first flag - "a" for transparent authentication.

    Usage:
    b2b_set_mode("a");
    b2b_init_request("scenario");

    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.

     
  • Nick Altmann
    Nick Altmann
    2012-05-29

    I've added updated version with fixed bug in late variables initialization. opensips_b2b_transp_auth_v3.patch It's production patch now.

     
1 2 3 > >> (Page 1 of 3)