Getting error in Access Control

[#1]

I am trying to do Access Control in my proxy.But getting below error.

Invalid value : /ALLOW for attribute action in MatchRule. Allowed values are [ALLOW, DENY].

I am just trying to do the same sample given in the docs page.

<AccessControl name="ACL">
  <IPRules noRuleMatchAction="/DENY">
    <MatchRule action="/ALLOW">
      <SourceAddress mask="16">10.10.10.10</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Its not working.Please suggest what I am missing.

[Former Community Member]

Hi @RK4 can you elaborate what exactly is not working? Looks like from your policy configuration you are trying to block traffic from any IP address except if it happens to be in this range 10.10.*.*

Is the system you are trying to invoke this proxy from has a source address in the range 10.10.*? One option is to examine the value of the "proxy.client.ip" variable in the trace tool & then set your SourceAddress element value/mask appropriately.

[#3]

Hi @Prithpal Bhogill

This is failing even when I am saving the proxy.This is not runtime error.

Do you really think if I change the IP address ,this error will go off?

[Former Community Member]

Ah gotcha the "/" character shouldn't be there in the action attribute, the docs need to be fixed. Try the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <Properties/>
    <IPRules noRuleMatchAction="DENY">
        <MatchRule action="ALLOW">
            <SourceAddress mask="16">10.10.10.10</SourceAddress>
        </MatchRule>
    </IPRules>
</AccessControl>

@Floyd Jones FYI

[#5]

😞 No luck.

Trying below one.Still same error

Invalid value : /ALLOW for attribute action in MatchRule. Allowed values are [ALLOW, DENY].

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <Properties/>
    <IPRules noRuleMatchAction="DENY">
        <MatchRule action="ALLOW">
            <SourceAddress mask="32">127.0.0.1</SourceAddress>
        </MatchRule>
      
    </IPRules>
</AccessControl>

[Former Community Member]

Hmm thats interesting. Can you make sure that you do not have "/ALLOW" or "/DENY" in your policy but simply "ALLOW" & "DENY" without the "/" character. Can you try with that please? I have also attached my proxy that works below.

no-target-rev1-2016-04-12.zip

[#7]

I checked again and i dont have /ALLOW.

I am checking your proxy.

[#8]

Also,I got this example from http://docs.apigee.com/api-services/reference/access-control-policy

[#9]

@Prithpal Bhogill

Is this APIGEE Edge or UI version issue?

I am not sure..

I checked your proxy in free org.And able to see its saving without issues.

In our Onpremise APIGEE,its not saving.I am copying the same policy details from your proxy...

[Former Community Member]

Interesting. Works for me in the Cloud & On-Premise (16.01). What version of on-premise are you using?

[Former Community Member]

Hi @RK4 can you elaborate what exactly is not working? Looks like from your policy configuration you are trying to block traffic from any IP address except if it happens to be in this range 10.10.*.*

Is the system you are trying to invoke this proxy from has a source address in the range 10.10.*? One option is to examine the value of the "proxy.client.ip" variable in the trace tool & then set your SourceAddress element value/mask appropriately.

[#12]

Start the Chrome browser from command prompt with a flag to ignore cross-site content

Add the Chrome addon from the following link -

Allow-Control-Allow-Origin: * - Chrome Web Store

Your server must return an appropriate Access-Control-Allow-Origin header in the response. For example, if the request is being sent from, then your server must return this header: Access-Control-Allow-Origin. You can determine, server-side, what the origin is by looking at the Origin header on the request. If your server does not return this header in the response, you will not have any access to the properties of the response browser-side (such as the status code, headers, or message body). The Same Origin Policy is at the center of this restriction.

[#13]

Thankyou @marlonbrando

I will check this...

[#14]

@marlonbrando , @Prithpal Bhogill I could not replicate this issue to figureout what is going wrong.When I tried next day,I was able to save!. In the middle,I believe restart happened in the Edge.Not sure if that fixed some glitches.Anyhow,I want to close this thread as no more issues on this.

[#15]

I have a MEAN Stack Application and I want to implement CORS with it.I have a digital ocean droplet with Ubuntu 14.04 on it and nginx installed on it. Till now everything was fine but suddenly I have been getting these errors that

Seo Training | Angularjs Training | Hadoop Training | Tableau Training