Layer7 API Management

 View Only
  • 1.  Restrict Access to IP Address with Variables

    Posted Jan 29, 2020 03:00 AM

    ​Hi,
    as it is not possible to define a list of allowed IP-addresses within the "Restrict Access to IP Address"-assertion, I was trying to built a workaround with "Run Assertion for Each Item". But it seems that the IP Range fields are NOT supporting variables.
    Can you please confirm, if this is true? Or otherwise can you help me identifying my issue as it's currently not working?
    Or is there any other method to manage all allowed IPs in a single place instead of inserting an additional "Restrict Access to IP Address"-assertion each time.
    Thank you!

    Ciao Stefan :)



  • 2.  RE: Restrict Access to IP Address with Variables

    Posted Jan 29, 2020 05:26 AM
    Edited by Deactivated User Jan 29, 2020 05:32 AM
      |   view attached
    Try this encapsulation


    Return Template Response
    ${matchat}
    process:${allowed}



    -- Give True (if boolean is true) else false (for all restrict)

    You can modify you encapsulation  as per your need and error handling requirement 


    I think you are right with regards to it not accepting context variable



    ------------------------------
    Pre-Sales Consultant
    CA Southern Africa
    ------------------------------

    Attachment(s)



  • 3.  RE: Restrict Access to IP Address with Variables

    Posted Jan 29, 2020 06:09 AM
    Hi Ronald,
    that's indeed a nice assertion, but only works with fixed classA, classB and classC networks. Ok, it could at least be easily extended to work with /32 as well.
    But the nice part of the "Restrict Access to IP Address"-assertion is, that it works with each CIDR, so also for small subnets/ranges like /28 or /30.
    Also the input-variable of the allowed IPs/networks from your assertion is a "one-line" string, which is very hard to handle/maintain if you have a huge list of entries. In a multivalued-variable in comparison ​you can add each IP/network as a single row and it's scrollable.
    Also I assume, that the built-in assertions have a better performance than a own-built assertion.
    Nevertheless I will think about it and maybe I can use it.
    Thank you!

    Ciao Stefan :)


  • 4.  RE: Restrict Access to IP Address with Variables
    Best Answer

    Posted Jan 29, 2020 06:49 AM
    Edited by Stefan Klotz Jan 30, 2020 03:09 AM

    Sorted.. Somehow the Restrict assertion was not taking multi valued variables like an array which is why I had restricted only to class a, class b and class c.
    Now the attached version can cater to any class
    Regarding the text field you could create a context variable called ip range and add the context variable as input

    and then use that as input 


    Also I assume, that the built-in assertions have a better performance than a own-built assertion.
    You are correct about this.. but In the encapsulation added as attached I am only using Run assertion -> Restict IP with the ip provided. That way I am using the native method to validate ip and break when there is a match







    -- Output : true (allow ip) | false (restrict ip)


    --
    Attached :
    Just import the corresponding policy (allow-restrict-ip-range)
    OR 
    Overwrite the encapsulation

    Hope this helps

    Note: Please disable (audit message policy and audit message in the encapsulation) enabled it for testing purpose..

    ------------------------------
    Pre-Sales Consultant
    CA Southern Africa
    ------------------------------



  • 5.  RE: Restrict Access to IP Address with Variables

    Posted Jan 30, 2020 03:13 AM
    Hi Ronald,
    thanks for your second update. I noticed, that you now also uses the ""Restrict Access to IP Address"-assertion, means this assertion CAN handle variables.
    The only thing you have to keep in mind is NOT to use array-variables. If in use (as in my code as well), you have to put its content in a "normal" variable.
    With this small change, my code is working now as well.
    Thank you so much!

    Ciao Stefan :)