From marc.savy at redhat.com  Tue Aug  1 17:42:38 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 1 Aug 2017 22:42:38 +0100
Subject: [Apiman-user] Champax /
	https://issues.jboss.org/browse/APIMAN-1201
In-Reply-To: <28bed94cae5d4b93b14c9a74d14d124e@S1984.EX1984.lan>
References: <28bed94cae5d4b93b14c9a74d14d124e@S1984.EX1984.lan>
Message-ID: <CAA7j38+9dkmo_f8byUhfL=8W=Q28ovyn3uNWewpUCbPn5gXs9A@mail.gmail.com>

Hi,

Just to understand, do you have the same issue as the ticket or is
there some slightly different issue. I seem to recall you mentioning
Elasticsearch in IRC?

On 28 July 2017 at 15:46, Laurent Champagnac <lchampagnac at vulog.com> wrote:
> Hello,
>
>
> as requested, initial email.
>
>
> This is about https://issues.jboss.org/browse/APIMAN-1201
>
>
> Regards,
>
> Champax
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From lchampagnac at vulog.com  Wed Aug  2 03:45:37 2017
From: lchampagnac at vulog.com (Laurent Champagnac)
Date: Wed, 2 Aug 2017 07:45:37 +0000
Subject: [Apiman-user] Champax /
 https://issues.jboss.org/browse/APIMAN-1201
In-Reply-To: <CAA7j38+9dkmo_f8byUhfL=8W=Q28ovyn3uNWewpUCbPn5gXs9A@mail.gmail.com>
References: <28bed94cae5d4b93b14c9a74d14d124e@S1984.EX1984.lan>,
	<CAA7j38+9dkmo_f8byUhfL=8W=Q28ovyn3uNWewpUCbPn5gXs9A@mail.gmail.com>
Message-ID: <1501659936983.56786@vulog.com>

Hey,

so yes, i have exactly the same issue as the ticket, but with the vertx gw.

Though i am not sure 100%, I detected that, after import, there seems to have an issue concerning the $CRYPT value stored inside ES for the endpoint (ES apiman_gateway).

If i publish a version 2.0 of the endpoint, the error for the version 2.0 endpoint do not repro anymore.

Details below.

Please note that the vertx gw ouput no logs at all concerning this...
I try to check the source code for a possible cause without any clues (a bit lost in interfaces & call chains....)

Regards,
Laurent.

a) On first invoke(s) (after import or after any vertx gw restart following this import - this repro 100%) :

*** CURL (error output)

$CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDLQ+67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA; line: 1, column: 7]

*** Elastics apiman metrics (same error)

$CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDLQ+67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA; line: 1, column: 7]",

*** Elastic apiman_gateway (=> mismatch with 2 previous)

"$CRYPT::UyN7eOLxR5YtTWJvUnE7FENuXjZOJ2S69Fz+1RcYSzjgUpnHhAlOWQUKiMgC2pq3LL7fdkhqDey480lEL+R/FX+zKWkFpAK2NaqKGRPGl7N53T7zALEmBzxiIyo8gpYtsSoSoLL1/HkLWq9cyOvrIdaRmmAOcZgWcKmxLhf9tonm1ipBoJW89Q+XwSUjM1LOn+L89R1gVnJ7L4vfnMycKFQlOAEoplUk5ps6iSjSmcy9Uzwk11xuAbTGVFy03Mh9LqcbBTwDNVC2Lti5P66aCFF2bGsZINlhLjfl6ldfp4xhVWn1JcIKPaEi7MkdqUomrKtB9RI3GHPeskPXRzpjQVfg2XwXbnmRdiS7VQGibn05b6mB3VrEn0VP6MBc5ceuLuHlUf1iH5JFoSQeloWEdFbjDR2V3IM3FTeNxBBHc0SiRHxAElCvjdKvC3tTVhiTN/xDATn3xInId4PQt8WlvOqfn/MIkid3k11AIY6eowIxAdoG6Lbjt8mcqa7X+yCrs8RvNP9qz4FunHele3VgPGdLAeqpXpiAIHyo1GsDsGUFFGz5ZfuLGD+fB6GU/nsZY9pD8389qZC9Xv7kbdVlo9ZlipJ8CW48NH0gT7yGzIekTIAdqklD3hEHnTNFwHXpfTcqti6RcQgud6+ZwMY6i4g5Ls+weizCROEHJEP4cjXYwpjZZWFiGCUtwEWHJ/mlEZT5B4Ga2zXZ5a5VgbgG2+pbzWG4awTZ5TC7kLoW95NzSZPLEV/1KVohlRaKaNimGWThDES/4m/8g3TK3jWKqyLEmPakq290LCNmrSPWSJA8rFkJ7dIF3zBFGbYAjv3JQPdInkJH0MJIHnCWQghH/dE9HlAyMOQp4f0FuC7NZTJ9eZePwHbrgr0szjVedNZjpvMus1MgDi8QlIt5sSC4ZDZGoaHJOKz0+GxrdOnAPcFmu8xiwDe160V+nwLNZS++g+xP9i9D8QkySUXAsDyF2eDQgXqLxhBS7cTaf+YX258xr9k554fwK4ryCMJc9zOsM/SG7qiDCjpedq6H2SdtcKZdkwMjGm0Sr7JHMIA2EVa6VWVbP3n7/+uige/OALd7aJFN8v1Ks1KQIj3LDdrjVSPFQcO2iBi4pOIpKAcZEe/B+cmikhy0z8G/PhU3yL0oitBOztaloFjvCgqkG5ptlDaH1B3hDPUZqhwNsOF3xdB09oO7KVJvvGU5ua0orvhz6xT9v8z3q0vTyvHSGRxexyH6iWwxLAyxZkQmynej2Hj7kEX6V4hbWWxVSWgsjQDhUP6UH5tQET73z4lkZpP++1ieZwDFHk3LCwzy0XXlXIuMmNBx0KzGd0sZoaCVLYJAJftiGhDJ4ltIlSBn1XH8bCKm4qIUB/5lqNPb4J1CZryZ5+YnyoHQVm+Q7JTkNPG1PhOZjEXu6Y9FMMnoLjSpZFCbP3Q2n5TBwxLKHP14i5MsyGewObLJYRMtT6JsU3/NzYbn7tRQYn/ido+Sjj2WeBLZ1JDcMJ7i/0EdoVVSfk5oPNgZwjbFjWICF8nqYFpuFR8JHs1SGq9sc942zWCTqkMqXIs7pGVspQlVEIMgVjxQYZt7Kc/docBMgx28Y8He4SyYCDpUEYhevGB5xDZa6urq03xJ8mmtMWZxukDvmoPX/j4ULPcY3yvkKTD/A/0/O81qx0P10lysx1VQgM2qjQMTbEN9MBkG7vVFzq9TfLUR2NCdGvF8VjUzYmSu7qZAK4qNmEpYNYY58LgsSd6JnywPgUG0NRbjEcUyqYtjxQmOuujWs0frufcMvuUCGKM/8bC3nqAFwD9oUIpXwKGuptiO3J6tNcfunXQ6+4JdG2DKLA0vZYsE9y7nraUwN3/WYQ8eE6SSPSCJsdv2CtfbKn1DD9roLpVJXHlJ21Phnd3Kgge6q7PlMKhk0BhR2QfU4LwwANUnLWzPczxad9v1WuTOKjvYCz7ortWLuNXNQFQ6F1wzNIp22mXiccK0vJHyt6Kpgb3dqcEFfAzvJjI6mbdMj3TPXVeIBApmE82rFX9uToF0mz2bWLpyk7QWQKXVzrI3d1McwuQ1TbcqA83hmOI6WAo/posU0hJPff2OV0Zc/Xq7a5wgxhmZ9AYtmmxm/afjlBcVkVEH6Thm943qkljUbqcu2vZRpjbRo4z3+gwjcFBhevyhzO2y8S4g3IQZ35K+YAYs4cHn72gXax0JxApniPTdRM+yzR9ohAaE/4QzWndf7riAKdjZmXI6FN5y",

B) When i publish a new endpoint version (without any modification), the $CRYPT inside  Elastic apiman_gateway seems to be ok this time, and the error for the endpoint 2.0 is now gone and do not reproduce.

"$CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDLQ+67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA",

________________________________________
From: Marc Savy <marc.savy at redhat.com>
Sent: 01 August 2017 23:42
To: Laurent Champagnac
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Champax / https://issues.jboss.org/browse/APIMAN-1201

Hi,

Just to understand, do you have the same issue as the ticket or is
there some slightly different issue. I seem to recall you mentioning
Elasticsearch in IRC?

On 28 July 2017 at 15:46, Laurent Champagnac <lchampagnac at vulog.com> wrote:
> Hello,
>
>
> as requested, initial email.
>
>
> This is about https://issues.jboss.org/browse/APIMAN-1201
>
>
> Regards,
>
> Champax
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From stephen at saasindustries.com  Fri Aug  4 20:21:55 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Fri, 4 Aug 2017 17:21:55 -0700
Subject: [Apiman-user] Authorization question
Message-ID: <CA+iPe9t9A+1qHu9OjJWWmMK8HMrJLMcABDM2dzbzzcOaOyzNZA@mail.gmail.com>

My goal is minimize the amount of Apiman configuration that I need to do by
sharing a single, common authentication Plan using the Keycloak plugin
across all APIs while using an API specific authorization policy for each
individual API.

As such,  I am trying to configure a single, global plan within Apiman that
can be used for ensuring authentication policy using the Keycloak plugin
which forwards all of my realm roles. This single plan would be assigned to
all of my APIs in the Org, which would allow me to only have to configure
the Keycloak realm information in one place. Then for each individual API,
I was hoping to add a single Authorization policy plugin configured with
endpoints and paths specific for each API.

Something like

Api1 ---> Keycloak Plan Abc
  +---->Authorization Policy (123)

Api2 ---> Keycloak Plan Abc
  +---->Authorization Policy (456)


When I do this and call one of the API endpoints, I am getting the
following error:

curl -k  -H "Authorization: Bearer $T"
https://localhost:9443/apiman-gateway/chassi/chassi-tenant-bff/1.0/mytenants

{"type":"Other","failureCode":10010,"responseCode":0,"message":"No roles
have been extracted during authentication.  Make sure the authorization
policy comes *after* a compatible authentication policy in your
configuration.","headers":[]}

It would seem that the Keycloak plugin that is configured in the Plan
assigned to the API is not forwarding the realm roles to the Authentication
policy which is also assigned to the same API.

Is this by design? Do the authentication and authorization policies have to
be within the same entity (ie. Plan, Api, etc) and not passed out of a plan
to be used by downstream policies?  If so, is there another way to
configure plans and policies that will allow me to accomplish my goal?

Thanks in advance!
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170804/fee4c242/attachment.html 

From marc.savy at redhat.com  Sat Aug  5 04:44:25 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Sat, 5 Aug 2017 09:44:25 +0100
Subject: [Apiman-user] Champax /
	https://issues.jboss.org/browse/APIMAN-1201
In-Reply-To: <1501659936983.56786@vulog.com>
References: <28bed94cae5d4b93b14c9a74d14d124e@S1984.EX1984.lan>
	<CAA7j38+9dkmo_f8byUhfL=8W=Q28ovyn3uNWewpUCbPn5gXs9A@mail.gmail.com>
	<1501659936983.56786@vulog.com>
Message-ID: <CAA7j38LO8bFAn3=zAAWAiC97S+i3wdhdd4z7MOBwBzU=0923Hw@mail.gmail.com>

I'll chat with Eric next week to see if we can figure this one out.
Thanks for the extra detail!

On 2 August 2017 at 08:45, Laurent Champagnac <lchampagnac at vulog.com> wrote:
> Hey,
>
> so yes, i have exactly the same issue as the ticket, but with the vertx gw.
>
> Though i am not sure 100%, I detected that, after import, there seems to have an issue concerning the $CRYPT value stored inside ES for the endpoint (ES apiman_gateway).
>
> If i publish a version 2.0 of the endpoint, the error for the version 2.0 endpoint do not repro anymore.
>
> Details below.
>
> Please note that the vertx gw ouput no logs at all concerning this...
> I try to check the source code for a possible cause without any clues (a bit lost in interfaces & call chains....)
>
> Regards,
> Laurent.
>
> a) On first invoke(s) (after import or after any vertx gw restart following this import - this repro 100%) :
>
> *** CURL (error output)
>
> $CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDLQ!
>  +67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA; line: 1, column: 7]
>
> *** Elastics apiman metrics (same error)
>
> $CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDLQ!
>  +67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA; line: 1, column: 7]",
>
> *** Elastic apiman_gateway (=> mismatch with 2 previous)
>
> "$CRYPT::UyN7eOLxR5YtTWJvUnE7FENuXjZOJ2S69Fz+1RcYSzjgUpnHhAlOWQUKiMgC2pq3LL7fdkhqDey480lEL+R/FX+zKWkFpAK2NaqKGRPGl7N53T7zALEmBzxiIyo8gpYtsSoSoLL1/HkLWq9cyOvrIdaRmmAOcZgWcKmxLhf9tonm1ipBoJW89Q+XwSUjM1LOn+L89R1gVnJ7L4vfnMycKFQlOAEoplUk5ps6iSjSmcy9Uzwk11xuAbTGVFy03Mh9LqcbBTwDNVC2Lti5P66aCFF2bGsZINlhLjfl6ldfp4xhVWn1JcIKPaEi7MkdqUomrKtB9RI3GHPeskPXRzpjQVfg2XwXbnmRdiS7VQGibn05b6mB3VrEn0VP6MBc5ceuLuHlUf1iH5JFoSQeloWEdFbjDR2V3IM3FTeNxBBHc0SiRHxAElCvjdKvC3tTVhiTN/xDATn3xInId4PQt8WlvOqfn/MIkid3k11AIY6eowIxAdoG6Lbjt8mcqa7X+yCrs8RvNP9qz4FunHele3VgPGdLAeqpXpiAIHyo1GsDsGUFFGz5ZfuLGD+fB6GU/nsZY9pD8389qZC9Xv7kbdVlo9ZlipJ8CW48NH0gT7yGzIekTIAdqklD3hEHnTNFwHXpfTcqti6RcQgud6+ZwMY6i4g5Ls+weizCROEHJEP4cjXYwpjZZWFiGCUtwEWHJ/mlEZT5B4Ga2zXZ5a5VgbgG2+pbzWG4awTZ5TC7kLoW95NzSZPLEV/1KVohlRaKaNimGWThDES/4m/8g3TK3jWKqyLEmPakq290LCNmrSPWSJA8rFkJ7dIF3zBFGbYAjv3JQPdInkJH0MJIHnCWQghH/dE9HlAyMOQp4f0FuC7NZTJ9eZePwHbrgr0szjVedNZjpvMus1MgDi8QlIt5sSC4ZDZGoaHJOKz0+GxrdOnAPcFmu8xiwDe160V+nwLNZS++g+xP9i9D8QkySUXAsDyF!
>  2eDQgXqLxhBS7cTaf+YX258xr9k554fwK4ryCMJc9zOsM/SG7qiDCjpedq6H2SdtcKZdkwMjGm0Sr7JHMIA2EVa6VWVbP3n7/+uige/OALd7aJFN8v1Ks1KQIj3LDdrjVSPFQcO2iBi4pOIpKAcZEe/B+cmikhy0z8G/PhU3yL0oitBOztaloFjvCgqkG5ptlDaH1B3hDPUZqhwNsOF3xdB09oO7KVJvvGU5ua0orvhz6xT9v8z3q0vTyvHSGRxexyH6iWwxLAyxZkQmynej2Hj7kEX6V4hbWWxVSWgsjQDhUP6UH5tQET73z4lkZpP++1ieZwDFHk3LCwzy0XXlXIuMmNBx0KzGd0sZoaCVLYJAJftiGhDJ4ltIlSBn1XH8bCKm4qIUB/5lqNPb4J1CZryZ5+YnyoHQVm+Q7JTkNPG1PhOZjEXu6Y9FMMnoLjSpZFCbP3Q2n5TBwxLKHP14i5MsyGewObLJYRMtT6JsU3/NzYbn7tRQYn/ido+Sjj2WeBLZ1JDcMJ7i/0EdoVVSfk5oPNgZwjbFjWICF8nqYFpuFR8JHs1SGq9sc942zWCTqkMqXIs7pGVspQlVEIMgVjxQYZt7Kc/docBMgx28Y8He4SyYCDpUEYhevGB5xDZa6urq03xJ8mmtMWZxukDvmoPX/j4ULPcY3yvkKTD/A/0/O81qx0P10lysx1VQgM2qjQMTbEN9MBkG7vVFzq9TfLUR2NCdGvF8VjUzYmSu7qZAK4qNmEpYNYY58LgsSd6JnywPgUG0NRbjEcUyqYtjxQmOuujWs0frufcMvuUCGKM/8bC3nqAFwD9oUIpXwKGuptiO3J6tNcfunXQ6+4JdG2DKLA0vZYsE9y7nraUwN3/WYQ8eE6SSPSCJsdv2CtfbKn1DD9roLpVJXHlJ21Phnd3Kgge6q7PlMKhk0BhR2QfU4LwwANUnLWzPczxad9v1WuTOKjvYCz7ortWLuNXNQFQ6F1wz!
>  NIp22mXiccK0vJHyt6Kpgb3dqcEFfAzvJjI6mbdMj3TPXVeIBApmE82rFX9uTo!
>  F0mz2bWL
> pyk7QWQKXVzrI3d1McwuQ1TbcqA83hmOI6WAo/posU0hJPff2OV0Zc/Xq7a5wgxhmZ9AYtmmxm/afjlBcVkVEH6Thm943qkljUbqcu2vZRpjbRo4z3+gwjcFBhevyhzO2y8S4g3IQZ35K+YAYs4cHn72gXax0JxApniPTdRM+yzR9ohAaE/4QzWndf7riAKdjZmXI6FN5y",
>
> B) When i publish a new endpoint version (without any modification), the $CRYPT inside  Elastic apiman_gateway seems to be ok this time, and the error for the endpoint 2.0 is now gone and do not reproduce.
>
> "$CRYPT::YyFN7bHtDKmDqlQo/HXi9JaWTvRsoexmXTGaKQQ+bKpl6JBQZfOmO0P5G4VP5AODo0cH1ZBsHKHsMpWrSrGUTJzIdtZSIpM+Tk6a1H7eXe7imLXbxo5+bPulCZGRMUN2Vjmye6DSzWYTuxRF8soh/l+q1/yRhbyMARDbIjMRaPjq0hO91RR66c96s3Dlz+NTcJXmbWr9PNLq0Fgk63WG9I5l8yBKk3roCDKcC2ebci/hEVsn8o/tV2QuSOsqwwqIn8X6MeScU2HaPu5wyzC6LE9ATDcuvqdl7q+ELct/CrwQ+nyjCbWqekbIyy9sphiD+4tKT3uaFVvhEBK+EQtHMrskLGsvlErOXHUE9Bnn/CfmHu7qjK2gUOJOwGWNLmfrgx1CG0D9fHpc6osn94Z2x0rhRCUoTLdpuirh5mNsdXoFvsu4MrJHay4SmvZo8fIeuyQsay+USs5cdQT0Gef8J+Ye7uqMraBQ4k7AZY0uZ+uQG5aGgnXm6hB33MRxiN+zpcPUI+TnJCbIyZ+21pDZgaYSY5jSzDxnzew2q+85MoYFhl+IdIY71kzJddGYNCo+kZ59guzEHc+FSNmXbjakDl/PVXJGVsIxuSywq3CBQLfrL4BUbRJGb3TWYbPKdGLMjnIygvT+p4BS41pYVyWZCknRyWRIjU2MlMTzI491V5IlFC8ig2PGnZOx0iouu2rk+7H8UHgJZwrcAVGfo9UeovzAZyulXseoDE9Z2X7gkfJpi7i6PBdU9gQ0HjtdJV2yOzngbJzNDP5G9nfDnCH1kjt/wZMYm2fHE1EYc64H4SetzsniUdICxoYdaH7oqU8hkOoy8KRCdm+qVM2sKsac+Cd/xhIhp2qyFfUCRl/mLD5S5vFakRe/QPEmlNVsdfDFe5BmRaWaVLo1lTNPyxKEIKI/vg73TDJZENYCQd95SzLUl1LODSgAyI4jVJc45cQRyvpA2gXY1FxrLOxeAiDL!
>  Q+67nMV7INskk/bdOVQ1uyP/k7vBC78GlhLdD+5/no6tRrsnhUQBkRpd8dIM7+q9jTctwTmHFFsNkDhYfUrEGQnQzgzKJNdrV0iTaUJ85Xr4byIICuYW5esNeC1MpjAIxAqhKAEZ0PUn1fJV6cUzGDHRq4D3iMapfgN0CpLEijzXPIBXtieyZc50ihrne5peyHmRPtgp3s8SQWt9mfP+ScM6dUnD8gzP0GvJEuU/S/CSW6LchmCGuvOX33jJ/uJbEQ7Vw6zP2wrlrIFFgZCb34EPldzpmYblbV6PByp9ouiE5k9TFbYrp+8pH342YS1zlcvwNQl4W50GCaZT2UHmdYRFmKSC6IaupslNbn+FSkUYDUa0eHi+wTluYKjLLUIpqu5h5RcSO08z/IKZOW67lv2LxTAuxWg7QZVDvx91SADDfIl2fykUmbwKTjQOS/gxpZanzxRzoe4niKCVF86eU6C8xVDSODaDO2ACg417aejhVpy+PGi0oY+ecZarYHtBDjAv5dud9XMjXe6MuuX0RljWjy/mdZjXLfHm+BsyAGIXgLRUpOxk5+8p3F5hVh6bOH77HeJuMH/GMmXdLmHerftTODxndo/YiUlCzU67lpe623ygEo7gpnMH4cuTH+MUSa2Fi59wJ/tWoiFO5ETXGiWfTwr/rtBK3kBgvVkF2ITA",
>
> ________________________________________
> From: Marc Savy <marc.savy at redhat.com>
> Sent: 01 August 2017 23:42
> To: Laurent Champagnac
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Champax / https://issues.jboss.org/browse/APIMAN-1201
>
> Hi,
>
> Just to understand, do you have the same issue as the ticket or is
> there some slightly different issue. I seem to recall you mentioning
> Elasticsearch in IRC?
>
> On 28 July 2017 at 15:46, Laurent Champagnac <lchampagnac at vulog.com> wrote:
>> Hello,
>>
>>
>> as requested, initial email.
>>
>>
>> This is about https://issues.jboss.org/browse/APIMAN-1201
>>
>>
>> Regards,
>>
>> Champax
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From marc.savy at redhat.com  Sat Aug  5 12:45:20 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Sat, 5 Aug 2017 17:45:20 +0100
Subject: [Apiman-user] JIRA problems (unable to log in)
In-Reply-To: <CAA7j38J7q9xZDcjuW66+-Aj1Bc5Ee-=_=DMOYar-Y=FKEhpP=Q@mail.gmail.com>
References: <CAA7j38J7q9xZDcjuW66+-Aj1Bc5Ee-=_=DMOYar-Y=FKEhpP=Q@mail.gmail.com>
Message-ID: <CAA7j38Jt+WjH6u-XV56nxAhMKRo-Zx0tfAT-EQnue=fQ3Om+sA@mail.gmail.com>

This should be fixed now.

If you were unable to file your tickets, please try again now.

On 27 July 2017 at 11:14, Marc Savy <marc.savy at redhat.com> wrote:
> Hi All,
>
> Community members have reported that they are unable to log into the
> Apiman JIRA.
> Unfortunately we had no idea up until now as our own accounts were
> unaffected. We've contacted the relevant support folk and hopefully
> the glitch will be resolved shortly.
>
> Apologies for the inconvenience and just to reassure folk that work is
> still very much progressing!
>
> Regards,
> Marc

From marc.savy at redhat.com  Tue Aug  8 06:08:47 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 8 Aug 2017 11:08:47 +0100
Subject: [Apiman-user] Authorization question
In-Reply-To: <CA+iPe9t9A+1qHu9OjJWWmMK8HMrJLMcABDM2dzbzzcOaOyzNZA@mail.gmail.com>
References: <CA+iPe9t9A+1qHu9OjJWWmMK8HMrJLMcABDM2dzbzzcOaOyzNZA@mail.gmail.com>
Message-ID: <CAA7j38KciO2cuBH7z69WAHEj=YVufHuGYkw16RzH12_60KWjtg@mail.gmail.com>

Hi,

If I understand your description correctly, this should work. And in
my quick tests, it seems to work.  I might not be replicating
your setup perfectly though.

For example let's imagine we have a setup such that:

Client Policies [] // None
Plan Policies [Foo, Bar]
API Policies [Baz]

This ultimately flattens to a policy chain of:

Caller <-> [ Foo <-> Bar <-> Baz ] <-> API

So if your setup is (N of):

Plan [ Keycloak Auth ]
API [ Authz ]

This should always result in: Keycloak *then* Authz, passing roles as
defined in config.

If that isn't happening then there's a bug. I may may need to collect
some more information from you to see whether I can replicate the
issue.

Regards,
Marc

On 5 August 2017 at 01:21, Stephen Henrie <stephen at saasindustries.com> wrote:
>
> My goal is minimize the amount of Apiman configuration that I need to do by
> sharing a single, common authentication Plan using the Keycloak plugin
> across all APIs while using an API specific authorization policy for each
> individual API.
>
> As such,  I am trying to configure a single, global plan within Apiman that
> can be used for ensuring authentication policy using the Keycloak plugin
> which forwards all of my realm roles. This single plan would be assigned to
> all of my APIs in the Org, which would allow me to only have to configure
> the Keycloak realm information in one place. Then for each individual API, I
> was hoping to add a single Authorization policy plugin configured with
> endpoints and paths specific for each API.
>
> Something like
>
> Api1 ---> Keycloak Plan Abc
>   +---->Authorization Policy (123)
>
> Api2 ---> Keycloak Plan Abc
>   +---->Authorization Policy (456)
>
>
> When I do this and call one of the API endpoints, I am getting the following
> error:
>
> curl -k  -H "Authorization: Bearer $T"
> https://localhost:9443/apiman-gateway/chassi/chassi-tenant-bff/1.0/mytenants
>
> {"type":"Other","failureCode":10010,"responseCode":0,"message":"No roles
> have been extracted during authentication.  Make sure the authorization
> policy comes *after* a compatible authentication policy in your
> configuration.","headers":[]}
>
> It would seem that the Keycloak plugin that is configured in the Plan
> assigned to the API is not forwarding the realm roles to the Authentication
> policy which is also assigned to the same API.
>
> Is this by design? Do the authentication and authorization policies have to
> be within the same entity (ie. Plan, Api, etc) and not passed out of a plan
> to be used by downstream policies?  If so, is there another way to configure
> plans and policies that will allow me to accomplish my goal?
>
> Thanks in advance!
> Stephen
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From ashish.patel at futuregroup.in  Thu Aug 10 05:18:05 2017
From: ashish.patel at futuregroup.in (Ashish Patel)
Date: Thu, 10 Aug 2017 09:18:05 +0000
Subject: [Apiman-user] Any expiry settings for Clients ?
Message-ID: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>

Hi,

We recently faced a strange issue on our APIman setup (QA/UAT environment so far). Suddenly one by one (not all APIs yet) API Clients are complaining that they are getting below exception. Here, none of the Client details (register / unregister) changed under APIManUI and even though below exception. The fix we applied selectively is, break any one API from client and add the same again through "New Contract" -> it will enable the "Re-Register" button -> click it and issue is resolved. This leads me to think, is there any Client API expiry settings - after which we have to re-register the client ? OR am I missing something here ?

Any help is greatly appreciated.

App Server: Wildfly 10.0.0-Final
APIMan: 1.2.7.Final
OS: Ubuntu

Exception:

[apiResponse] => Array
        (
            [responseCode] => 500
            [message] => No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
            [trace] => io.apiman.gateway.engine.beans.exceptions.InvalidContractException: No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
    at io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)
    at io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)
    at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)
    at io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)
    at io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
    at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
    at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)


Thanks & Regards,
Ashish Patel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170810/e79ad9ed/attachment.html 

From marc.savy at redhat.com  Thu Aug 10 05:33:00 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 10 Aug 2017 10:33:00 +0100
Subject: [Apiman-user] Authorization question
In-Reply-To: <CAA7j38KciO2cuBH7z69WAHEj=YVufHuGYkw16RzH12_60KWjtg@mail.gmail.com>
References: <CA+iPe9t9A+1qHu9OjJWWmMK8HMrJLMcABDM2dzbzzcOaOyzNZA@mail.gmail.com>
	<CAA7j38KciO2cuBH7z69WAHEj=YVufHuGYkw16RzH12_60KWjtg@mail.gmail.com>
Message-ID: <CAA7j38KujBHUsJwxPNpaoqF9EcMW4p==Xn4pGxJ8YUWFtHS4LA@mail.gmail.com>

Is your setup roughly:

ClientApp -> Plan [Keycloak] -> API [Authz]

Which version of Keycloak are you using?
What type of roles are you using? For example, realm.

The way Keycloak roles are modelled has changed fairly significantly
over the last few versions of KC. We might not be handling that
correctly anymore.

On 8 August 2017 at 11:08, Marc Savy <marc.savy at redhat.com> wrote:
> Hi,
>
> If I understand your description correctly, this should work. And in
> my quick tests, it seems to work.  I might not be replicating
> your setup perfectly though.
>
> For example let's imagine we have a setup such that:
>
> Client Policies [] // None
> Plan Policies [Foo, Bar]
> API Policies [Baz]
>
> This ultimately flattens to a policy chain of:
>
> Caller <-> [ Foo <-> Bar <-> Baz ] <-> API
>
> So if your setup is (N of):
>
> Plan [ Keycloak Auth ]
> API [ Authz ]
>
> This should always result in: Keycloak *then* Authz, passing roles as
> defined in config.
>
> If that isn't happening then there's a bug. I may may need to collect
> some more information from you to see whether I can replicate the
> issue.
>
> Regards,
> Marc
>
> On 5 August 2017 at 01:21, Stephen Henrie <stephen at saasindustries.com> wrote:
>>
>> My goal is minimize the amount of Apiman configuration that I need to do by
>> sharing a single, common authentication Plan using the Keycloak plugin
>> across all APIs while using an API specific authorization policy for each
>> individual API.
>>
>> As such,  I am trying to configure a single, global plan within Apiman that
>> can be used for ensuring authentication policy using the Keycloak plugin
>> which forwards all of my realm roles. This single plan would be assigned to
>> all of my APIs in the Org, which would allow me to only have to configure
>> the Keycloak realm information in one place. Then for each individual API, I
>> was hoping to add a single Authorization policy plugin configured with
>> endpoints and paths specific for each API.
>>
>> Something like
>>
>> Api1 ---> Keycloak Plan Abc
>>   +---->Authorization Policy (123)
>>
>> Api2 ---> Keycloak Plan Abc
>>   +---->Authorization Policy (456)
>>
>>
>> When I do this and call one of the API endpoints, I am getting the following
>> error:
>>
>> curl -k  -H "Authorization: Bearer $T"
>> https://localhost:9443/apiman-gateway/chassi/chassi-tenant-bff/1.0/mytenants
>>
>> {"type":"Other","failureCode":10010,"responseCode":0,"message":"No roles
>> have been extracted during authentication.  Make sure the authorization
>> policy comes *after* a compatible authentication policy in your
>> configuration.","headers":[]}
>>
>> It would seem that the Keycloak plugin that is configured in the Plan
>> assigned to the API is not forwarding the realm roles to the Authentication
>> policy which is also assigned to the same API.
>>
>> Is this by design? Do the authentication and authorization policies have to
>> be within the same entity (ie. Plan, Api, etc) and not passed out of a plan
>> to be used by downstream policies?  If so, is there another way to configure
>> plans and policies that will allow me to accomplish my goal?
>>
>> Thanks in advance!
>> Stephen
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

From marc.savy at redhat.com  Thu Aug 10 05:43:54 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 10 Aug 2017 10:43:54 +0100
Subject: [Apiman-user] Any expiry settings for Clients ?
In-Reply-To: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
Message-ID: <CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>

It sounds like someone might have accidentally deleted your gateway's
indexes in Elasticsearch.

Apiman Gateway and Apiman Manager have separate storage (even if you
use the same Elasticsearch instance, they have separate indices).

I suggest looking into your ES instance (using a management tool like
elasticsearch-head might be helpful [1]) and seeing whether the
`apiman-gateway` index is there, and that it contains the entries you
expect.

If you are feeling more adventurous, then you might try find the
following query useful[2]:

curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
-H 'Content-Type: application/json' -d'
{
  "query": { "match_all": {} }
}
'

Regards,
Marc

[1] https://github.com/dzharii/awesome-elasticsearch
[2] https://www.elastic.co/guide/en/elasticsearch/reference/current/_introducing_the_query_language.html

On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
> Hi,
>
>
>
> We recently faced a strange issue on our APIman setup (QA/UAT environment so
> far). Suddenly one by one (not all APIs yet) API Clients are complaining
> that they are getting below exception. Here, none of the Client details
> (register / unregister) changed under APIManUI and even though below
> exception. The fix we applied selectively is, break any one API from client
> and add the same again through ?New Contract? -> it will enable the
> ?Re-Register? button -> click it and issue is resolved. This leads me to
> think, is there any Client API expiry settings ? after which we have to
> re-register the client ? OR am I missing something here ?
>
>
>
> Any help is greatly appreciated.
>
>
>
> App Server: Wildfly 10.0.0-Final
>
> APIMan: 1.2.7.Final
>
> OS: Ubuntu
>
>
>
> Exception:
>
>
>
> [apiResponse] => Array
>
>         (
>
>             [responseCode] => 500
>
>             [message] => No client found for API Key
> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>
>             [trace] =>
> io.apiman.gateway.engine.beans.exceptions.InvalidContractException: No
> client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>
>     at
> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)
>
>     at
> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)
>
>     at
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)
>
>     at
> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)
>
>     at
> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)
>
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
>     at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>
>     at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>
>     at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>
>
>
>
>
> Thanks & Regards,
>
> Ashish Patel
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From marc.savy at redhat.com  Thu Aug 10 05:44:59 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 10 Aug 2017 10:44:59 +0100
Subject: [Apiman-user] Any expiry settings for Clients ?
In-Reply-To: <CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
	<CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
Message-ID: <CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>

Correction:

> and seeing whether the `apiman-gateway` index is there

Should read:

> and seeing whether the `apiman_gateway` index is there

On 10 August 2017 at 10:43, Marc Savy <marc.savy at redhat.com> wrote:
> It sounds like someone might have accidentally deleted your gateway's
> indexes in Elasticsearch.
>
> Apiman Gateway and Apiman Manager have separate storage (even if you
> use the same Elasticsearch instance, they have separate indices).
>
> I suggest looking into your ES instance (using a management tool like
> elasticsearch-head might be helpful [1]) and seeing whether the
> `apiman-gateway` index is there, and that it contains the entries you
> expect.
>
> If you are feeling more adventurous, then you might try find the
> following query useful[2]:
>
> curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
> -H 'Content-Type: application/json' -d'
> {
>   "query": { "match_all": {} }
> }
> '
>
> Regards,
> Marc
>
> [1] https://github.com/dzharii/awesome-elasticsearch
> [2] https://www.elastic.co/guide/en/elasticsearch/reference/current/_introducing_the_query_language.html
>
> On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
>> Hi,
>>
>>
>>
>> We recently faced a strange issue on our APIman setup (QA/UAT environment so
>> far). Suddenly one by one (not all APIs yet) API Clients are complaining
>> that they are getting below exception. Here, none of the Client details
>> (register / unregister) changed under APIManUI and even though below
>> exception. The fix we applied selectively is, break any one API from client
>> and add the same again through ?New Contract? -> it will enable the
>> ?Re-Register? button -> click it and issue is resolved. This leads me to
>> think, is there any Client API expiry settings ? after which we have to
>> re-register the client ? OR am I missing something here ?
>>
>>
>>
>> Any help is greatly appreciated.
>>
>>
>>
>> App Server: Wildfly 10.0.0-Final
>>
>> APIMan: 1.2.7.Final
>>
>> OS: Ubuntu
>>
>>
>>
>> Exception:
>>
>>
>>
>> [apiResponse] => Array
>>
>>         (
>>
>>             [responseCode] => 500
>>
>>             [message] => No client found for API Key
>> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>
>>             [trace] =>
>> io.apiman.gateway.engine.beans.exceptions.InvalidContractException: No
>> client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>
>>     at
>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)
>>
>>     at
>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)
>>
>>     at
>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)
>>
>>     at
>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)
>>
>>     at
>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)
>>
>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>
>>     at
>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>
>>     at
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>
>>     at
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>> Ashish Patel
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>


From ashish.patel at futuregroup.in  Thu Aug 10 06:19:31 2017
From: ashish.patel at futuregroup.in (Ashish Patel)
Date: Thu, 10 Aug 2017 10:19:31 +0000
Subject: [Apiman-user] Any expiry settings for Clients ?
In-Reply-To: <CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
	<CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
	<CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>
Message-ID: <ba829085e50b44d7a350fb9f2d81b910@futuregroup.in>

Thanks Marc.

Yes I can see apiman_gateway index there. It's QA setup so using embedded ES/KeyCloak. Another update is Issue doesn't go after restarting services.

Thanks & Regards,
Ashish Patel
(M) +91 93270 15128


-----Original Message-----
From: Marc Savy [mailto:marc.savy at redhat.com] 
Sent: Thursday, August 10, 2017 15:15
To: Ashish Patel
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Any expiry settings for Clients ?

Correction:

> and seeing whether the `apiman-gateway` index is there

Should read:

> and seeing whether the `apiman_gateway` index is there

On 10 August 2017 at 10:43, Marc Savy <marc.savy at redhat.com> wrote:
> It sounds like someone might have accidentally deleted your gateway's 
> indexes in Elasticsearch.
>
> Apiman Gateway and Apiman Manager have separate storage (even if you 
> use the same Elasticsearch instance, they have separate indices).
>
> I suggest looking into your ES instance (using a management tool like 
> elasticsearch-head might be helpful [1]) and seeing whether the 
> `apiman-gateway` index is there, and that it contains the entries you 
> expect.
>
> If you are feeling more adventurous, then you might try find the 
> following query useful[2]:
>
> curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
> -H 'Content-Type: application/json' -d'
> {
>   "query": { "match_all": {} }
> }
> '
>
> Regards,
> Marc
>
> [1] https://github.com/dzharii/awesome-elasticsearch
> [2] 
> https://www.elastic.co/guide/en/elasticsearch/reference/current/_intro
> ducing_the_query_language.html
>
> On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
>> Hi,
>>
>>
>>
>> We recently faced a strange issue on our APIman setup (QA/UAT 
>> environment so far). Suddenly one by one (not all APIs yet) API 
>> Clients are complaining that they are getting below exception. Here, 
>> none of the Client details (register / unregister) changed under 
>> APIManUI and even though below exception. The fix we applied 
>> selectively is, break any one API from client and add the same again 
>> through ?New Contract? -> it will enable the ?Re-Register? button -> 
>> click it and issue is resolved. This leads me to think, is there any 
>> Client API expiry settings ? after which we have to re-register the client ? OR am I missing something here ?
>>
>>
>>
>> Any help is greatly appreciated.
>>
>>
>>
>> App Server: Wildfly 10.0.0-Final
>>
>> APIMan: 1.2.7.Final
>>
>> OS: Ubuntu
>>
>>
>>
>> Exception:
>>
>>
>>
>> [apiResponse] => Array
>>
>>         (
>>
>>             [responseCode] => 500
>>
>>             [message] => No client found for API Key
>> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>
>>             [trace] =>
>> io.apiman.gateway.engine.beans.exceptions.InvalidContractException: 
>> No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>
>>     at
>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRe
>> gistry.java:78)
>>
>>     at
>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(Secur
>> eRegistryWrapper.java:154)
>>
>>     at
>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiReque
>> stExecutorImpl.java:357)
>>
>>     at
>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewaySe
>> rvlet.java:179)
>>
>>     at
>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewaySer
>> vlet.java:79)
>>
>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>
>>     at
>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHand
>> ler.java:85)
>>
>>     at
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.hand
>> leRequest(ServletSecurityRoleHandler.java:62)
>>
>>     at
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(
>> ServletDispatchingHandler.java:36)
>>
>>
>>
>>
>>
>> Thanks & Regards,
>>
>> Ashish Patel
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>


From marc.savy at redhat.com  Thu Aug 10 08:20:55 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 10 Aug 2017 13:20:55 +0100
Subject: [Apiman-user] Any expiry settings for Clients ?
In-Reply-To: <ba829085e50b44d7a350fb9f2d81b910@futuregroup.in>
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
	<CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
	<CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>
	<ba829085e50b44d7a350fb9f2d81b910@futuregroup.in>
Message-ID: <CAA7j38Jhbj23ojiWf8Zym01eYLKwXS5P9qkXZ_agRm+8hK6CTw@mail.gmail.com>

When you explicitly inspected the apiman_gateway index in ES, were the
records you expected missing?

There's certainly no functionality in Apiman that expires/auto-deletes
Client Apps, and I'm not aware of any other community users (most of
whom are using ES, I think) experiencing this problem.

A few thoughts:

- Could you be running some scripts that auto-retire records or data
in your ES cluster?
- Is some other part of your system retiring those resources (i.e. not
Apiman but some script you've written)

I've added in Miro & Jakub to see whether they have any thoughts with
their QE experience.


On 10 August 2017 at 11:19, Ashish Patel <ashish.patel at futuregroup.in> wrote:
> Thanks Marc.
>
> Yes I can see apiman_gateway index there. It's QA setup so using embedded ES/KeyCloak. Another update is Issue doesn't go after restarting services.
>
> Thanks & Regards,
> Ashish Patel
> (M) +91 93270 15128
>
>
> -----Original Message-----
> From: Marc Savy [mailto:marc.savy at redhat.com]
> Sent: Thursday, August 10, 2017 15:15
> To: Ashish Patel
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Any expiry settings for Clients ?
>
> Correction:
>
>> and seeing whether the `apiman-gateway` index is there
>
> Should read:
>
>> and seeing whether the `apiman_gateway` index is there
>
> On 10 August 2017 at 10:43, Marc Savy <marc.savy at redhat.com> wrote:
>> It sounds like someone might have accidentally deleted your gateway's
>> indexes in Elasticsearch.
>>
>> Apiman Gateway and Apiman Manager have separate storage (even if you
>> use the same Elasticsearch instance, they have separate indices).
>>
>> I suggest looking into your ES instance (using a management tool like
>> elasticsearch-head might be helpful [1]) and seeing whether the
>> `apiman-gateway` index is there, and that it contains the entries you
>> expect.
>>
>> If you are feeling more adventurous, then you might try find the
>> following query useful[2]:
>>
>> curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
>> -H 'Content-Type: application/json' -d'
>> {
>>   "query": { "match_all": {} }
>> }
>> '
>>
>> Regards,
>> Marc
>>
>> [1] https://github.com/dzharii/awesome-elasticsearch
>> [2]
>> https://www.elastic.co/guide/en/elasticsearch/reference/current/_intro
>> ducing_the_query_language.html
>>
>> On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
>>> Hi,
>>>
>>>
>>>
>>> We recently faced a strange issue on our APIman setup (QA/UAT
>>> environment so far). Suddenly one by one (not all APIs yet) API
>>> Clients are complaining that they are getting below exception. Here,
>>> none of the Client details (register / unregister) changed under
>>> APIManUI and even though below exception. The fix we applied
>>> selectively is, break any one API from client and add the same again
>>> through ?New Contract? -> it will enable the ?Re-Register? button ->
>>> click it and issue is resolved. This leads me to think, is there any
>>> Client API expiry settings ? after which we have to re-register the client ? OR am I missing something here ?
>>>
>>>
>>>
>>> Any help is greatly appreciated.
>>>
>>>
>>>
>>> App Server: Wildfly 10.0.0-Final
>>>
>>> APIMan: 1.2.7.Final
>>>
>>> OS: Ubuntu
>>>
>>>
>>>
>>> Exception:
>>>
>>>
>>>
>>> [apiResponse] => Array
>>>
>>>         (
>>>
>>>             [responseCode] => 500
>>>
>>>             [message] => No client found for API Key
>>> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>             [trace] =>
>>> io.apiman.gateway.engine.beans.exceptions.InvalidContractException:
>>> No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>     at
>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRe
>>> gistry.java:78)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(Secur
>>> eRegistryWrapper.java:154)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiReque
>>> stExecutorImpl.java:357)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewaySe
>>> rvlet.java:179)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewaySer
>>> vlet.java:79)
>>>
>>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHand
>>> ler.java:85)
>>>
>>>     at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.hand
>>> leRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(
>>> ServletDispatchingHandler.java:36)
>>>
>>>
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Ashish Patel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From ashish.patel at futuregroup.in  Sat Aug 12 09:01:20 2017
From: ashish.patel at futuregroup.in (Ashish Patel)
Date: Sat, 12 Aug 2017 13:01:20 +0000
Subject: [Apiman-user] Any expiry settings for Clients ?
In-Reply-To: <CAA7j38Jhbj23ojiWf8Zym01eYLKwXS5P9qkXZ_agRm+8hK6CTw@mail.gmail.com>
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
	<CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
	<CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>
	<ba829085e50b44d7a350fb9f2d81b910@futuregroup.in>
	<CAA7j38Jhbj23ojiWf8Zym01eYLKwXS5P9qkXZ_agRm+8hK6CTw@mail.gmail.com>
Message-ID: <60c82a9a6b9944c8b5cc67d99d326fc3@futuregroup.in>

Thanks Marc.

Sorry for late reply on below thread as I was travelling.

When you explicitly inspected the apiman_gateway index in ES, were the records you expected missing? [Ashish] Didn't check at that time,  will check next time it occurs.

There's certainly no functionality in Apiman that expires/auto-deletes Client Apps [Ashish] Thanks, then it could be a bug where I have to find the reproducible steps.

- Could you be running some scripts that auto-retire records or data in your ES cluster?
- Is some other part of your system retiring those resources (i.e. not Apiman but some script you've written)

[Ashish]: Both of above question's answer is No. We don't have any scripts running in system.

Thanks & Regards,
Ashish Patel

-----Original Message-----
From: Marc Savy [mailto:marc.savy at redhat.com] 
Sent: Thursday, August 10, 2017 17:51
To: Ashish Patel
Cc: apiman-user at lists.jboss.org; Jakub Cechacek; Miroslav Jaros
Subject: Re: [Apiman-user] Any expiry settings for Clients ?

When you explicitly inspected the apiman_gateway index in ES, were the records you expected missing?

There's certainly no functionality in Apiman that expires/auto-deletes Client Apps, and I'm not aware of any other community users (most of whom are using ES, I think) experiencing this problem.

A few thoughts:

- Could you be running some scripts that auto-retire records or data in your ES cluster?
- Is some other part of your system retiring those resources (i.e. not Apiman but some script you've written)

I've added in Miro & Jakub to see whether they have any thoughts with their QE experience.


On 10 August 2017 at 11:19, Ashish Patel <ashish.patel at futuregroup.in> wrote:
> Thanks Marc.
>
> Yes I can see apiman_gateway index there. It's QA setup so using embedded ES/KeyCloak. Another update is Issue doesn't go after restarting services.
>
> Thanks & Regards,
> Ashish Patel
> (M) +91 93270 15128
>
>
> -----Original Message-----
> From: Marc Savy [mailto:marc.savy at redhat.com]
> Sent: Thursday, August 10, 2017 15:15
> To: Ashish Patel
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Any expiry settings for Clients ?
>
> Correction:
>
>> and seeing whether the `apiman-gateway` index is there
>
> Should read:
>
>> and seeing whether the `apiman_gateway` index is there
>
> On 10 August 2017 at 10:43, Marc Savy <marc.savy at redhat.com> wrote:
>> It sounds like someone might have accidentally deleted your gateway's 
>> indexes in Elasticsearch.
>>
>> Apiman Gateway and Apiman Manager have separate storage (even if you 
>> use the same Elasticsearch instance, they have separate indices).
>>
>> I suggest looking into your ES instance (using a management tool like 
>> elasticsearch-head might be helpful [1]) and seeing whether the 
>> `apiman-gateway` index is there, and that it contains the entries you 
>> expect.
>>
>> If you are feeling more adventurous, then you might try find the 
>> following query useful[2]:
>>
>> curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
>> -H 'Content-Type: application/json' -d'
>> {
>>   "query": { "match_all": {} }
>> }
>> '
>>
>> Regards,
>> Marc
>>
>> [1] https://github.com/dzharii/awesome-elasticsearch
>> [2]
>> https://www.elastic.co/guide/en/elasticsearch/reference/current/_intr
>> o
>> ducing_the_query_language.html
>>
>> On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
>>> Hi,
>>>
>>>
>>>
>>> We recently faced a strange issue on our APIman setup (QA/UAT 
>>> environment so far). Suddenly one by one (not all APIs yet) API 
>>> Clients are complaining that they are getting below exception. Here, 
>>> none of the Client details (register / unregister) changed under 
>>> APIManUI and even though below exception. The fix we applied 
>>> selectively is, break any one API from client and add the same again 
>>> through ?New Contract? -> it will enable the ?Re-Register? button -> 
>>> click it and issue is resolved. This leads me to think, is there any 
>>> Client API expiry settings ? after which we have to re-register the client ? OR am I missing something here ?
>>>
>>>
>>>
>>> Any help is greatly appreciated.
>>>
>>>
>>>
>>> App Server: Wildfly 10.0.0-Final
>>>
>>> APIMan: 1.2.7.Final
>>>
>>> OS: Ubuntu
>>>
>>>
>>>
>>> Exception:
>>>
>>>
>>>
>>> [apiResponse] => Array
>>>
>>>         (
>>>
>>>             [responseCode] => 500
>>>
>>>             [message] => No client found for API Key
>>> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>             [trace] =>
>>> io.apiman.gateway.engine.beans.exceptions.InvalidContractException:
>>> No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>     at
>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESR
>>> e
>>> gistry.java:78)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(Secu
>>> r
>>> eRegistryWrapper.java:154)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequ
>>> e
>>> stExecutorImpl.java:357)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayS
>>> e
>>> rvlet.java:179)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewaySe
>>> r
>>> vlet.java:79)
>>>
>>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan
>>> d
>>> ler.java:85)
>>>
>>>     at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han
>>> d
>>> leRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest
>>> (
>>> ServletDispatchingHandler.java:36)
>>>
>>>
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Ashish Patel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From ashish.patel at futuregroup.in  Wed Aug 16 02:26:37 2017
From: ashish.patel at futuregroup.in (Ashish Patel)
Date: Wed, 16 Aug 2017 06:26:37 +0000
Subject: [Apiman-user] Any expiry settings for Clients ?
References: <399a2db12cc14e1197b5f97e3d8bd1de@futuregroup.in>
	<CAA7j38JJhRyzGYSjofxjqi+LbArDqSGU5cjHNMRW1rcjKQpa5Q@mail.gmail.com>
	<CAA7j38LSrhyRJ0SKoqhn=aO3dv71sr9qFCueHdzGYOGZPdRvKg@mail.gmail.com>
	<ba829085e50b44d7a350fb9f2d81b910@futuregroup.in>
	<CAA7j38Jhbj23ojiWf8Zym01eYLKwXS5P9qkXZ_agRm+8hK6CTw@mail.gmail.com> 
Message-ID: <02ab7c76eb124391b84762187a439fb5@futuregroup.in>

Hi Marc,

Issue occurred again and following are observations.

1. yes records from ES w.r.t. the api_key were missing.
2. Observed logs and found when we "un-register" client explicitly, it deletes ALL indexes of type client ("_type" : "client")  - ideally it should only delete the type client of that client id (_id = respective clientId). This seems to be a bug, am still doing more tests to confirm. Here, if you add / remove any contracts and "re-register" the client then it adds the new client apikey in the ES Index (means it works fine for re-register on append mode).

As our QA instance is shared among various teams, also asking them on why are they doing "un-register" and then register for an existing client ?

Thanks & Regards,
Ashish Patel
(M) +91 93270 15128


-----Original Message-----
From: Ashish Patel 
Sent: Saturday, August 12, 2017 18:31
To: 'Marc Savy'
Cc: apiman-user at lists.jboss.org; Jakub Cechacek; Miroslav Jaros
Subject: RE: [Apiman-user] Any expiry settings for Clients ?

Thanks Marc.

Sorry for late reply on below thread as I was travelling.

When you explicitly inspected the apiman_gateway index in ES, were the records you expected missing? [Ashish] Didn't check at that time,  will check next time it occurs.

There's certainly no functionality in Apiman that expires/auto-deletes Client Apps [Ashish] Thanks, then it could be a bug where I have to find the reproducible steps.

- Could you be running some scripts that auto-retire records or data in your ES cluster?
- Is some other part of your system retiring those resources (i.e. not Apiman but some script you've written)

[Ashish]: Both of above question's answer is No. We don't have any scripts running in system.

Thanks & Regards,
Ashish Patel

-----Original Message-----
From: Marc Savy [mailto:marc.savy at redhat.com]
Sent: Thursday, August 10, 2017 17:51
To: Ashish Patel
Cc: apiman-user at lists.jboss.org; Jakub Cechacek; Miroslav Jaros
Subject: Re: [Apiman-user] Any expiry settings for Clients ?

When you explicitly inspected the apiman_gateway index in ES, were the records you expected missing?

There's certainly no functionality in Apiman that expires/auto-deletes Client Apps, and I'm not aware of any other community users (most of whom are using ES, I think) experiencing this problem.

A few thoughts:

- Could you be running some scripts that auto-retire records or data in your ES cluster?
- Is some other part of your system retiring those resources (i.e. not Apiman but some script you've written)

I've added in Miro & Jakub to see whether they have any thoughts with their QE experience.


On 10 August 2017 at 11:19, Ashish Patel <ashish.patel at futuregroup.in> wrote:
> Thanks Marc.
>
> Yes I can see apiman_gateway index there. It's QA setup so using embedded ES/KeyCloak. Another update is Issue doesn't go after restarting services.
>
> Thanks & Regards,
> Ashish Patel
> (M) +91 93270 15128
>
>
> -----Original Message-----
> From: Marc Savy [mailto:marc.savy at redhat.com]
> Sent: Thursday, August 10, 2017 15:15
> To: Ashish Patel
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Any expiry settings for Clients ?
>
> Correction:
>
>> and seeing whether the `apiman-gateway` index is there
>
> Should read:
>
>> and seeing whether the `apiman_gateway` index is there
>
> On 10 August 2017 at 10:43, Marc Savy <marc.savy at redhat.com> wrote:
>> It sounds like someone might have accidentally deleted your gateway's 
>> indexes in Elasticsearch.
>>
>> Apiman Gateway and Apiman Manager have separate storage (even if you 
>> use the same Elasticsearch instance, they have separate indices).
>>
>> I suggest looking into your ES instance (using a management tool like 
>> elasticsearch-head might be helpful [1]) and seeing whether the 
>> `apiman-gateway` index is there, and that it contains the entries you 
>> expect.
>>
>> If you are feeling more adventurous, then you might try find the 
>> following query useful[2]:
>>
>> curl -XGET '<YOUR_ELASTICSEARCH>:9200/apiman_gateway/_search?pretty'
>> -H 'Content-Type: application/json' -d'
>> {
>>   "query": { "match_all": {} }
>> }
>> '
>>
>> Regards,
>> Marc
>>
>> [1] https://github.com/dzharii/awesome-elasticsearch
>> [2]
>> https://www.elastic.co/guide/en/elasticsearch/reference/current/_intr
>> o
>> ducing_the_query_language.html
>>
>> On 10 August 2017 at 10:18, Ashish Patel <ashish.patel at futuregroup.in> wrote:
>>> Hi,
>>>
>>>
>>>
>>> We recently faced a strange issue on our APIman setup (QA/UAT 
>>> environment so far). Suddenly one by one (not all APIs yet) API 
>>> Clients are complaining that they are getting below exception. Here, 
>>> none of the Client details (register / unregister) changed under 
>>> APIManUI and even though below exception. The fix we applied 
>>> selectively is, break any one API from client and add the same again 
>>> through ?New Contract? -> it will enable the ?Re-Register? button -> 
>>> click it and issue is resolved. This leads me to think, is there any 
>>> Client API expiry settings ? after which we have to re-register the client ? OR am I missing something here ?
>>>
>>>
>>>
>>> Any help is greatly appreciated.
>>>
>>>
>>>
>>> App Server: Wildfly 10.0.0-Final
>>>
>>> APIMan: 1.2.7.Final
>>>
>>> OS: Ubuntu
>>>
>>>
>>>
>>> Exception:
>>>
>>>
>>>
>>> [apiResponse] => Array
>>>
>>>         (
>>>
>>>             [responseCode] => 500
>>>
>>>             [message] => No client found for API Key
>>> 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>             [trace] =>
>>> io.apiman.gateway.engine.beans.exceptions.InvalidContractException:
>>> No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
>>>
>>>     at
>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESR
>>> e
>>> gistry.java:78)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(Secu
>>> r
>>> eRegistryWrapper.java:154)
>>>
>>>     at
>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequ
>>> e
>>> stExecutorImpl.java:357)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayS
>>> e
>>> rvlet.java:179)
>>>
>>>     at
>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewaySe
>>> r
>>> vlet.java:79)
>>>
>>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan
>>> d
>>> ler.java:85)
>>>
>>>     at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han
>>> d
>>> leRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>     at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest
>>> (
>>> ServletDispatchingHandler.java:36)
>>>
>>>
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Ashish Patel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From stephen at saasindustries.com  Fri Aug 18 23:16:08 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Fri, 18 Aug 2017 20:16:08 -0700
Subject: [Apiman-user] Proxy headers missing for processing policies
Message-ID: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>

I have Apiman running in an openshift environment, which is essentially a
similar configuration to running in kubernetes. Each container/pod is
always receiving http/s requests through an HA Proxy server, so that the
x-forwarded-* set of headers get added to each request by the proxy server.

Unfortunately, it appears that the headers which are provided in the
ApiRequet bean when the policy chain processor doApply() method is called
does not include these proxy related headers.  This means that the standard
policies for the IP white and black listing policies do not work when the
apiman gateway is behind a proxy server.  The request.getRemoteAddr()
method returns the ip address to the proxy server, so there is no way to
get the ip address of the originator since the x-forwarded-for header ( and
related headers ) are not found.

Has anyone else experienced this?  If so, is this by design?

Thanks!

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170818/b4226238/attachment.html 

From eric.wittmann at redhat.com  Mon Aug 21 10:04:06 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 21 Aug 2017 10:04:06 -0400
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
Message-ID: <CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>

That's very interesting because I don't believe Apiman is stripping out any
headers from the request (at any point).  If that's happening I can't think
of what the root cause might be.  IIRC we just copy all request headers
from the inbound HttpServletRequest into the ApiRequest bean.

GitHub is currently down so I can't send a link to the relevant code....

On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie <stephen at saasindustries.com
> wrote:

>
> I have Apiman running in an openshift environment, which is essentially a
> similar configuration to running in kubernetes. Each container/pod is
> always receiving http/s requests through an HA Proxy server, so that the
> x-forwarded-* set of headers get added to each request by the proxy server.
>
> Unfortunately, it appears that the headers which are provided in the
> ApiRequet bean when the policy chain processor doApply() method is called
> does not include these proxy related headers.  This means that the standard
> policies for the IP white and black listing policies do not work when the
> apiman gateway is behind a proxy server.  The request.getRemoteAddr()
> method returns the ip address to the proxy server, so there is no way to
> get the ip address of the originator since the x-forwarded-for header ( and
> related headers ) are not found.
>
> Has anyone else experienced this?  If so, is this by design?
>
> Thanks!
>
> Stephen
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170821/33f5a464/attachment.html 

From eric.wittmann at redhat.com  Mon Aug 21 10:50:57 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 21 Aug 2017 10:50:57 -0400
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
Message-ID: <CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>

GitHub is back up.  Here is the code (when running the servlet version of
the gateway, not the vert.x version) that reads the inbound HTTP request
headers, copying them into the ApiRequest bean:

https://github.com/apiman/apiman/blob/master/gateway/platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/GatewayServlet.java#L263-L280

The only header that gets skipped is X-API-Version.

-Eric


On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> That's very interesting because I don't believe Apiman is stripping out
> any headers from the request (at any point).  If that's happening I can't
> think of what the root cause might be.  IIRC we just copy all request
> headers from the inbound HttpServletRequest into the ApiRequest bean.
>
> GitHub is currently down so I can't send a link to the relevant code....
>
> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie <
> stephen at saasindustries.com> wrote:
>
>>
>> I have Apiman running in an openshift environment, which is essentially a
>> similar configuration to running in kubernetes. Each container/pod is
>> always receiving http/s requests through an HA Proxy server, so that the
>> x-forwarded-* set of headers get added to each request by the proxy server.
>>
>> Unfortunately, it appears that the headers which are provided in the
>> ApiRequet bean when the policy chain processor doApply() method is called
>> does not include these proxy related headers.  This means that the standard
>> policies for the IP white and black listing policies do not work when the
>> apiman gateway is behind a proxy server.  The request.getRemoteAddr()
>> method returns the ip address to the proxy server, so there is no way to
>> get the ip address of the originator since the x-forwarded-for header ( and
>> related headers ) are not found.
>>
>> Has anyone else experienced this?  If so, is this by design?
>>
>> Thanks!
>>
>> Stephen
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170821/64b792e6/attachment-0001.html 

From stephen at saasindustries.com  Tue Aug 22 12:01:04 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Tue, 22 Aug 2017 11:01:04 -0500
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
Message-ID: <CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>

Eric, thanks for the response.

I had reviewed that code as well, so I believe you when you say that it
should be passing all of those proxy headers along. However, check out
below what I am seeing when posting a request to a test service that I am
running. It simply dumps the headers The first request is made directly to
the service without going through apiman and the second request is made
through apiman.

I don't think that the issue is in the servlet code, but when these headers
are passed into where policies applied, like somewhere where the ApiRequest
class is created.

Thanks
Stephen


2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : HEADERS:
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
(darwin15.6.0)
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : accept: */*
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : accept-encoding: identity
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : host:
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : x-forwarded-host:
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : x-forwarded-port: 80
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : x-forwarded-proto: http
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : forwarded:
for=71.86.141.114;host=
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com;proto=http
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : x-forwarded-for: 71.86.141.114
2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1



2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : HEADERS:
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
(darwin15.6.0)
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : accept-encoding: identity
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : connection: Keep-Alive
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : accept: */*
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : host:
spring-boot-oauth-demo.user-dev.svc:8080
2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6


On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> GitHub is back up.  Here is the code (when running the servlet version of
> the gateway, not the vert.x version) that reads the inbound HTTP request
> headers, copying them into the ApiRequest bean:
>
> https://github.com/apiman/apiman/blob/master/gateway/
> platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/
> GatewayServlet.java#L263-L280
>
> The only header that gets skipped is X-API-Version.
>
> -Eric
>
>
> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> That's very interesting because I don't believe Apiman is stripping out
>> any headers from the request (at any point).  If that's happening I can't
>> think of what the root cause might be.  IIRC we just copy all request
>> headers from the inbound HttpServletRequest into the ApiRequest bean.
>>
>> GitHub is currently down so I can't send a link to the relevant code....
>>
>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie <
>> stephen at saasindustries.com> wrote:
>>
>>>
>>> I have Apiman running in an openshift environment, which is essentially
>>> a similar configuration to running in kubernetes. Each container/pod is
>>> always receiving http/s requests through an HA Proxy server, so that the
>>> x-forwarded-* set of headers get added to each request by the proxy server.
>>>
>>> Unfortunately, it appears that the headers which are provided in the
>>> ApiRequet bean when the policy chain processor doApply() method is called
>>> does not include these proxy related headers.  This means that the standard
>>> policies for the IP white and black listing policies do not work when the
>>> apiman gateway is behind a proxy server.  The request.getRemoteAddr()
>>> method returns the ip address to the proxy server, so there is no way to
>>> get the ip address of the originator since the x-forwarded-for header ( and
>>> related headers ) are not found.
>>>
>>> Has anyone else experienced this?  If so, is this by design?
>>>
>>> Thanks!
>>>
>>> Stephen
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170822/a75a276c/attachment.html 

From stephen at saasindustries.com  Tue Aug 22 12:13:16 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Tue, 22 Aug 2017 11:13:16 -0500
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
Message-ID: <CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>

FWIW, it is in the policy code where I am not seeing these headers being
set correctly:

https://github.com/apiman/apiman/blob/master/gateway/engine/policies/src/main/java/io/apiman/gateway/engine/policies/IPWhitelistPolicy.java#L55



On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie <stephen at saasindustries.com
> wrote:

> Eric, thanks for the response.
>
> I had reviewed that code as well, so I believe you when you say that it
> should be passing all of those proxy headers along. However, check out
> below what I am seeing when posting a request to a test service that I am
> running. It simply dumps the headers The first request is made directly to
> the service without going through apiman and the second request is made
> through apiman.
>
> I don't think that the issue is in the servlet code, but when these
> headers are passed into where policies applied, like somewhere where the
> ApiRequest class is created.
>
> Thanks
> Stephen
>
>
> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : HEADERS:
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : user-agent: Wget/1.19.1 (darwin15.6.0)
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : accept: */*
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : accept-encoding: identity
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : host: spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2
> FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LT
> RlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZi
> I6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2
> Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2
> ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZW
> JlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYX
> BwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNj
> E3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZW
> Qtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZX
> Yucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dG
> guZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi
> 5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLn
> NhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS
> 11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG
> 9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbT
> o4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZG
> V2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2Zvcm
> dlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2
> UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2
> ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW
> 5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLC
> J1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY2
> 91bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3
> VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIE
> hlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLm
> NvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW
> 5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.
> AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : x-forwarded-host: spring-boot-oauth-demo-user-
> dev.router.dev1.saasforge.com
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : x-forwarded-port: 80
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : x-forwarded-proto: http
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : forwarded: for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.
> router.dev1.saasforge.com;proto=http
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : x-forwarded-for: 71.86.141.114
> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7] com.saas.controller.ApiRestController
> : RemoteAddr: 172.17.0.1
>
>
>
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : HEADERS:
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : user-agent: Wget/1.19.1 (darwin15.6.0)
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : accept-encoding: identity
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : connection: Keep-Alive
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2
> FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LT
> RlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZi
> I6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2
> Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2
> ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZW
> JlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYX
> BwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNj
> E3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZW
> Qtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZX
> Yucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dG
> guZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi
> 5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLn
> NhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS
> 11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG
> 9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbT
> o4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZG
> V2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2Zvcm
> dlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2
> UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2
> ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW
> 5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLC
> J1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY2
> 91bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3
> VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIE
> hlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLm
> NvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW
> 5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.
> AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : accept: */*
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : host: spring-boot-oauth-demo.user-dev.svc:8080
> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9] com.saas.controller.ApiRestController
> : RemoteAddr: 172.17.0.6
>
>
> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> GitHub is back up.  Here is the code (when running the servlet version of
>> the gateway, not the vert.x version) that reads the inbound HTTP request
>> headers, copying them into the ApiRequest bean:
>>
>> https://github.com/apiman/apiman/blob/master/gateway/platfor
>> ms/servlet/src/main/java/io/apiman/gateway/platforms/
>> servlet/GatewayServlet.java#L263-L280
>>
>> The only header that gets skipped is X-API-Version.
>>
>> -Eric
>>
>>
>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann <eric.wittmann at redhat.com
>> > wrote:
>>
>>> That's very interesting because I don't believe Apiman is stripping out
>>> any headers from the request (at any point).  If that's happening I can't
>>> think of what the root cause might be.  IIRC we just copy all request
>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
>>>
>>> GitHub is currently down so I can't send a link to the relevant code....
>>>
>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie <
>>> stephen at saasindustries.com> wrote:
>>>
>>>>
>>>> I have Apiman running in an openshift environment, which is essentially
>>>> a similar configuration to running in kubernetes. Each container/pod is
>>>> always receiving http/s requests through an HA Proxy server, so that the
>>>> x-forwarded-* set of headers get added to each request by the proxy server.
>>>>
>>>> Unfortunately, it appears that the headers which are provided in the
>>>> ApiRequet bean when the policy chain processor doApply() method is called
>>>> does not include these proxy related headers.  This means that the standard
>>>> policies for the IP white and black listing policies do not work when the
>>>> apiman gateway is behind a proxy server.  The request.getRemoteAddr()
>>>> method returns the ip address to the proxy server, so there is no way to
>>>> get the ip address of the originator since the x-forwarded-for header ( and
>>>> related headers ) are not found.
>>>>
>>>> Has anyone else experienced this?  If so, is this by design?
>>>>
>>>> Thanks!
>>>>
>>>> Stephen
>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170822/3c025b5a/attachment-0001.html 

From marc.savy at redhat.com  Wed Aug 23 07:59:01 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 23 Aug 2017 12:59:01 +0100
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
	<CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
Message-ID: <CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>

Hi Stephen,

Out of interest: can you replicate your setup, but with no policies in
the chain to see what happens?

Second, perhaps you can try the simple-header-policy
(https://apiman.gitbooks.io/apiman-user-guide/user-guide/gateway/policies.html#_simple_header_policy)
and let me know what happens (just put some dummy config in and see
whether the headers still disappear).

I'll try to replicate your setup soon.

Regards,
Marc

On 22 August 2017 at 17:13, Stephen Henrie <stephen at saasindustries.com> wrote:
> FWIW, it is in the policy code where I am not seeing these headers being set
> correctly:
>
> https://github.com/apiman/apiman/blob/master/gateway/engine/policies/src/main/java/io/apiman/gateway/engine/policies/IPWhitelistPolicy.java#L55
>
>
>
> On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie
> <stephen at saasindustries.com> wrote:
>>
>> Eric, thanks for the response.
>>
>> I had reviewed that code as well, so I believe you when you say that it
>> should be passing all of those proxy headers along. However, check out below
>> what I am seeing when posting a request to a test service that I am running.
>> It simply dumps the headers The first request is made directly to the
>> service without going through apiman and the second request is made through
>> apiman.
>>
>> I don't think that the issue is in the servlet code, but when these
>> headers are passed into where policies applied, like somewhere where the
>> ApiRequest class is created.
>>
>> Thanks
>> Stephen
>>
>>
>> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : HEADERS:
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
>> (darwin15.6.0)
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : accept: */*
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : accept-encoding: identity
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : host:
>> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : authorization: Bearer
>> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : x-forwarded-host:
>> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : x-forwarded-port: 80
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : x-forwarded-proto: http
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : forwarded:
>> for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com;proto=http
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : x-forwarded-for: 71.86.141.114
>> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1
>>
>>
>>
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : HEADERS:
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
>> (darwin15.6.0)
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : accept-encoding: identity
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : connection: Keep-Alive
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : authorization: Bearer
>> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : accept: */*
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : host:
>> spring-boot-oauth-demo.user-dev.svc:8080
>> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6
>>
>>
>> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <eric.wittmann at redhat.com>
>> wrote:
>>>
>>> GitHub is back up.  Here is the code (when running the servlet version of
>>> the gateway, not the vert.x version) that reads the inbound HTTP request
>>> headers, copying them into the ApiRequest bean:
>>>
>>>
>>> https://github.com/apiman/apiman/blob/master/gateway/platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/GatewayServlet.java#L263-L280
>>>
>>> The only header that gets skipped is X-API-Version.
>>>
>>> -Eric
>>>
>>>
>>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann
>>> <eric.wittmann at redhat.com> wrote:
>>>>
>>>> That's very interesting because I don't believe Apiman is stripping out
>>>> any headers from the request (at any point).  If that's happening I can't
>>>> think of what the root cause might be.  IIRC we just copy all request
>>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
>>>>
>>>> GitHub is currently down so I can't send a link to the relevant code....
>>>>
>>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie
>>>> <stephen at saasindustries.com> wrote:
>>>>>
>>>>>
>>>>> I have Apiman running in an openshift environment, which is essentially
>>>>> a similar configuration to running in kubernetes. Each container/pod is
>>>>> always receiving http/s requests through an HA Proxy server, so that the
>>>>> x-forwarded-* set of headers get added to each request by the proxy server.
>>>>>
>>>>> Unfortunately, it appears that the headers which are provided in the
>>>>> ApiRequet bean when the policy chain processor doApply() method is called
>>>>> does not include these proxy related headers.  This means that the standard
>>>>> policies for the IP white and black listing policies do not work when the
>>>>> apiman gateway is behind a proxy server.  The request.getRemoteAddr() method
>>>>> returns the ip address to the proxy server, so there is no way to get the ip
>>>>> address of the originator since the x-forwarded-for header ( and related
>>>>> headers ) are not found.
>>>>>
>>>>> Has anyone else experienced this?  If so, is this by design?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Wed Aug 23 08:13:57 2017
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 23 Aug 2017 08:13:57 -0400
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
	<CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
	<CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
Message-ID: <CAP4n9Q9v_b+RbH2d5uM09VgMY5Keq8gZBT-Zpe1K_=aw03EcSw@mail.gmail.com>

There is also the Log policy that could be added, which will output the
request headers to the wildfly console *before* proxying to the back-end
API.

On Wed, Aug 23, 2017 at 7:59 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi Stephen,
>
> Out of interest: can you replicate your setup, but with no policies in
> the chain to see what happens?
>
> Second, perhaps you can try the simple-header-policy
> (https://apiman.gitbooks.io/apiman-user-guide/user-guide/
> gateway/policies.html#_simple_header_policy)
> and let me know what happens (just put some dummy config in and see
> whether the headers still disappear).
>
> I'll try to replicate your setup soon.
>
> Regards,
> Marc
>
> On 22 August 2017 at 17:13, Stephen Henrie <stephen at saasindustries.com>
> wrote:
> > FWIW, it is in the policy code where I am not seeing these headers being
> set
> > correctly:
> >
> > https://github.com/apiman/apiman/blob/master/gateway/
> engine/policies/src/main/java/io/apiman/gateway/engine/
> policies/IPWhitelistPolicy.java#L55
> >
> >
> >
> > On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie
> > <stephen at saasindustries.com> wrote:
> >>
> >> Eric, thanks for the response.
> >>
> >> I had reviewed that code as well, so I believe you when you say that it
> >> should be passing all of those proxy headers along. However, check out
> below
> >> what I am seeing when posting a request to a test service that I am
> running.
> >> It simply dumps the headers The first request is made directly to the
> >> service without going through apiman and the second request is made
> through
> >> apiman.
> >>
> >> I don't think that the issue is in the servlet code, but when these
> >> headers are passed into where policies applied, like somewhere where the
> >> ApiRequest class is created.
> >>
> >> Thanks
> >> Stephen
> >>
> >>
> >> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-port: 80
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-proto: http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : forwarded:
> >> for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.
> router.dev1.saasforge.com;proto=http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-for:
> 71.86.141.114
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1
> >>
> >>
> >>
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : connection: Keep-Alive
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo.user-dev.svc:8080
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6
> >>
> >>
> >> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <
> eric.wittmann at redhat.com>
> >> wrote:
> >>>
> >>> GitHub is back up.  Here is the code (when running the servlet version
> of
> >>> the gateway, not the vert.x version) that reads the inbound HTTP
> request
> >>> headers, copying them into the ApiRequest bean:
> >>>
> >>>
> >>> https://github.com/apiman/apiman/blob/master/gateway/
> platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/
> GatewayServlet.java#L263-L280
> >>>
> >>> The only header that gets skipped is X-API-Version.
> >>>
> >>> -Eric
> >>>
> >>>
> >>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann
> >>> <eric.wittmann at redhat.com> wrote:
> >>>>
> >>>> That's very interesting because I don't believe Apiman is stripping
> out
> >>>> any headers from the request (at any point).  If that's happening I
> can't
> >>>> think of what the root cause might be.  IIRC we just copy all request
> >>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
> >>>>
> >>>> GitHub is currently down so I can't send a link to the relevant
> code....
> >>>>
> >>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie
> >>>> <stephen at saasindustries.com> wrote:
> >>>>>
> >>>>>
> >>>>> I have Apiman running in an openshift environment, which is
> essentially
> >>>>> a similar configuration to running in kubernetes. Each container/pod
> is
> >>>>> always receiving http/s requests through an HA Proxy server, so that
> the
> >>>>> x-forwarded-* set of headers get added to each request by the proxy
> server.
> >>>>>
> >>>>> Unfortunately, it appears that the headers which are provided in the
> >>>>> ApiRequet bean when the policy chain processor doApply() method is
> called
> >>>>> does not include these proxy related headers.  This means that the
> standard
> >>>>> policies for the IP white and black listing policies do not work
> when the
> >>>>> apiman gateway is behind a proxy server.  The
> request.getRemoteAddr() method
> >>>>> returns the ip address to the proxy server, so there is no way to
> get the ip
> >>>>> address of the originator since the x-forwarded-for header ( and
> related
> >>>>> headers ) are not found.
> >>>>>
> >>>>> Has anyone else experienced this?  If so, is this by design?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Stephen
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Apiman-user mailing list
> >>>>> Apiman-user at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170823/70642bb1/attachment-0001.html 

From sbalu27 at gmail.com  Mon Aug 28 09:05:16 2017
From: sbalu27 at gmail.com (Balu S)
Date: Mon, 28 Aug 2017 15:05:16 +0200
Subject: [Apiman-user] policy error/failure writer cannot find logger
Message-ID: <CAEDnbHCmr_ZB5aFt+kQ7S8N0K=jboOBL=nLy7n-DLCa1Eqr2bA@mail.gmail.com>

Hello,

I have a custom error and failure writers that
implements IPolicyErrorWriter and IPolicyFailureWriter respectively. But
these implementation methods does not provide IPolicyContext object to
access loggers. However this is possible from IDataPolicy.

So I have tried to inject the ApimanLogger like below, but it always yields
null. I have include the neccesary jar as "provided" scope in pom.xml.


*example:*
public class MyPolicyErrorWriter implements IPolicyErrorWriter{

@Inject @ApimanLogger(MyPolicyErrorWriter.class)
IApimanLogger logger;

@Override
public void write(ApiRequest request, Throwable error,
IApiClientResponse response) {

 // here logger is always null?
            logger.info("
         }
......

Could you please suggest how can I add IApimanLogger to my custom error or
failure writers ?

Best regards
Balu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170828/300114a7/attachment.html 

From stephen at saasindustries.com  Mon Aug 28 20:38:09 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Mon, 28 Aug 2017 19:38:09 -0500
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
	<CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
	<CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
Message-ID: <CA+iPe9vtGu7VapSRvNQzPgta2WxNZC4gTcueLQWRhpP7EbOzKQ@mail.gmail.com>

Hi Marc,

Sorry that it took me so long to respond. I was traveling last week and
only now getting back to this.

Per your request, I removed all policies and I still see the same issue
where only the proxy related errors are missing. Here are the two examples,
the first going though Apiman and the second hitting the service API
directly:

*wget --header="Content-Type: application/json" -S -nv  -O -
--no-check-certificate --content-on-error  --header="Authorization: Bearer
$T"
https://api.dev1.saasforge.com/apiman-gateway/chassi-services/greeting/1.0/greeting/help
<https://api.dev1.saasforge.com/apiman-gateway/chassi-services/greeting/1.0/greeting/help>*

2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : HEADERS:
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
(darwin15.6.0)
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : content-type: application/json
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : accept-encoding: identity
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : connection: Keep-Alive
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI2MTkwODk2My03YmNmLTQ1MTctYjI3NS03ZGNlMWJmMmM0MTUiLCJleHAiOjE1MDM5NjY2MjEsIm5iZiI6MCwiaWF0IjoxNTAzOTY2MzIxLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiODY4YWQzNmEtNjFhNy00NjAxLTgzZDEtMDFhNTIzNjU0NWE3IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.fwnBfL6dVGBx_pQqNzIyZEEQvzNB7nNuZULqX03fx6huY15u8Hm2f_doX40qX5Qbic_j_sC9Ho4P2N4jJEkq51swwzlzGa4jPGUo9se1UXFBsjJrDCTX9ayyr9EHmV-eUa6m6YYmMHph6gUNkmidP1BKu5aHGJajfylOSMK8inPrnY5Y9Rt7MFj1oJY2lHAFAVyyiz6JNiEg87Zy8Rlfp5D-vVkQofnjumOBj74CDSHX9d0YHUI1hNBmPMLgYtFZsK9REg3EsQ3QPr4NEuMiFg25FD9-sZ7mm4_oA9uXeJlGPRrLKzwiC5_JCoWpWqm49vpwAon3TCFQVSuJQ5j9nw
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : accept: */*
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : host:
spring-boot-oauth-demo.user-dev.svc:8080
2017-08-29 00:25:24.577 DEBUG 1 --- [io-8080-exec-10]
com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6


*curl -v
http://spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com/greeting/help
<http://spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com/greeting/help>
-H "Content-Type: application/json" -H "Authorization: Bearer $T"*

2017-08-29 00:25:57.429 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : HEADERS:
2017-08-29 00:25:57.429 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : host:
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
2017-08-29 00:25:57.429 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : user-agent: curl/7.43.0
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : accept: */*
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : content-type: application/json
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI2MTkwODk2My03YmNmLTQ1MTctYjI3NS03ZGNlMWJmMmM0MTUiLCJleHAiOjE1MDM5NjY2MjEsIm5iZiI6MCwiaWF0IjoxNTAzOTY2MzIxLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiODY4YWQzNmEtNjFhNy00NjAxLTgzZDEtMDFhNTIzNjU0NWE3IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.fwnBfL6dVGBx_pQqNzIyZEEQvzNB7nNuZULqX03fx6huY15u8Hm2f_doX40qX5Qbic_j_sC9Ho4P2N4jJEkq51swwzlzGa4jPGUo9se1UXFBsjJrDCTX9ayyr9EHmV-eUa6m6YYmMHph6gUNkmidP1BKu5aHGJajfylOSMK8inPrnY5Y9Rt7MFj1oJY2lHAFAVyyiz6JNiEg87Zy8Rlfp5D-vVkQofnjumOBj74CDSHX9d0YHUI1hNBmPMLgYtFZsK9REg3EsQ3QPr4NEuMiFg25FD9-sZ7mm4_oA9uXeJlGPRrLKzwiC5_JCoWpWqm49vpwAon3TCFQVSuJQ5j9nw
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : x-forwarded-host:
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : x-forwarded-port: 80
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : x-forwarded-proto: http
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : forwarded:
for=70.162.10.131;host=
spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com;proto=http
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : x-forwarded-for: 70.162.10.131
2017-08-29 00:25:57.430 DEBUG 1 --- [nio-8080-exec-1]
com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1

You can see where the proxy headers are not being passed.

Per your request, I also added the simple header policy and added two
headers (highlighted below) and they were passed on properly as you can
see.

I still think that something is stripping the proxy headers before they are
passed into the ApiRequest object for policy processing.



*wget --header="Content-Type: application/json" -S -nv  -O -
--no-check-certificate --content-on-error  --header="Authorization: Bearer
$T"
https://api.dev1.saasforge.com/apiman-gateway/chassi-services/greeting/1.0/greeting/help
<https://api.dev1.saasforge.com/apiman-gateway/chassi-services/greeting/1.0/greeting/help>*2017-08-29
00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : HEADERS:
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
(darwin15.6.0)
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : hello: world
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : x-forwarded-for: 0.0.0.0
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : content-type: application/json
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : accept-encoding: identity
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : connection: Keep-Alive
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiJlNTAxNGU3Ni1iY2Y4LTQxMTAtYmQyNC01OWQyN2E3Mjg1MzkiLCJleHAiOjE1MDM5NjcxMjQsIm5iZiI6MCwiaWF0IjoxNTAzOTY2ODI0LCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiNTgxNGZmMjktNzRiYS00ZDNhLTlkMWUtZDg1NDY0MTNiZTVjIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.A0H18cUglTdr-SyqV-olCaGAtWI9U_ohhPkNsXStC8k4uQJTYdxQ_ehulcDMOyIeOt7ETsMH_7FLdRureSssxpgrRQhRHrnri9lCXjQATkKeRPnkC1EvHA5t_RG3LZ5f8akwgjnTeVaEkzX0nsODYvKYAGJ8s9DRWzUu0TqwDsnC-L9z0014fNFw2r7qAC0Ga1N4DhswtAlUGo_H1ljNdZbwMC0AlNE-GugigBn6OWk9kfmfK02UdX23_qS3t8WOaVjpYiNE0vqbbj_jLy40lOTo4fMXqqaRF_wWttnE73kcPgP1U1Er0vpBoxeKzqgmV1hOqM1_OGsuYOAsGU26Fw
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : accept: */*
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : host:
spring-boot-oauth-demo.user-dev.svc:8080
2017-08-29 00:33:49.631 DEBUG 1 --- [nio-8080-exec-4]
com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6

Thanks!

Stephen

On Wed, Aug 23, 2017 at 6:59 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi Stephen,
>
> Out of interest: can you replicate your setup, but with no policies in
> the chain to see what happens?
>
> Second, perhaps you can try the simple-header-policy
> (https://apiman.gitbooks.io/apiman-user-guide/user-guide/
> gateway/policies.html#_simple_header_policy)
> and let me know what happens (just put some dummy config in and see
> whether the headers still disappear).
>
> I'll try to replicate your setup soon.
>
> Regards,
> Marc
>
> On 22 August 2017 at 17:13, Stephen Henrie <stephen at saasindustries.com>
> wrote:
> > FWIW, it is in the policy code where I am not seeing these headers being
> set
> > correctly:
> >
> > https://github.com/apiman/apiman/blob/master/gateway/
> engine/policies/src/main/java/io/apiman/gateway/engine/
> policies/IPWhitelistPolicy.java#L55
> >
> >
> >
> > On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie
> > <stephen at saasindustries.com> wrote:
> >>
> >> Eric, thanks for the response.
> >>
> >> I had reviewed that code as well, so I believe you when you say that it
> >> should be passing all of those proxy headers along. However, check out
> below
> >> what I am seeing when posting a request to a test service that I am
> running.
> >> It simply dumps the headers The first request is made directly to the
> >> service without going through apiman and the second request is made
> through
> >> apiman.
> >>
> >> I don't think that the issue is in the servlet code, but when these
> >> headers are passed into where policies applied, like somewhere where the
> >> ApiRequest class is created.
> >>
> >> Thanks
> >> Stephen
> >>
> >>
> >> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-port: 80
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-proto: http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : forwarded:
> >> for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.
> router.dev1.saasforge.com;proto=http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-for:
> 71.86.141.114
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1
> >>
> >>
> >>
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : connection: Keep-Alive
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo.user-dev.svc:8080
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6
> >>
> >>
> >> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <
> eric.wittmann at redhat.com>
> >> wrote:
> >>>
> >>> GitHub is back up.  Here is the code (when running the servlet version
> of
> >>> the gateway, not the vert.x version) that reads the inbound HTTP
> request
> >>> headers, copying them into the ApiRequest bean:
> >>>
> >>>
> >>> https://github.com/apiman/apiman/blob/master/gateway/
> platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/
> GatewayServlet.java#L263-L280
> >>>
> >>> The only header that gets skipped is X-API-Version.
> >>>
> >>> -Eric
> >>>
> >>>
> >>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann
> >>> <eric.wittmann at redhat.com> wrote:
> >>>>
> >>>> That's very interesting because I don't believe Apiman is stripping
> out
> >>>> any headers from the request (at any point).  If that's happening I
> can't
> >>>> think of what the root cause might be.  IIRC we just copy all request
> >>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
> >>>>
> >>>> GitHub is currently down so I can't send a link to the relevant
> code....
> >>>>
> >>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie
> >>>> <stephen at saasindustries.com> wrote:
> >>>>>
> >>>>>
> >>>>> I have Apiman running in an openshift environment, which is
> essentially
> >>>>> a similar configuration to running in kubernetes. Each container/pod
> is
> >>>>> always receiving http/s requests through an HA Proxy server, so that
> the
> >>>>> x-forwarded-* set of headers get added to each request by the proxy
> server.
> >>>>>
> >>>>> Unfortunately, it appears that the headers which are provided in the
> >>>>> ApiRequet bean when the policy chain processor doApply() method is
> called
> >>>>> does not include these proxy related headers.  This means that the
> standard
> >>>>> policies for the IP white and black listing policies do not work
> when the
> >>>>> apiman gateway is behind a proxy server.  The
> request.getRemoteAddr() method
> >>>>> returns the ip address to the proxy server, so there is no way to
> get the ip
> >>>>> address of the originator since the x-forwarded-for header ( and
> related
> >>>>> headers ) are not found.
> >>>>>
> >>>>> Has anyone else experienced this?  If so, is this by design?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Stephen
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Apiman-user mailing list
> >>>>> Apiman-user at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170828/c8f722e9/attachment-0001.html 

From marc.savy at redhat.com  Thu Aug 31 07:35:31 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 31 Aug 2017 12:35:31 +0100
Subject: [Apiman-user] policy error/failure writer cannot find logger
In-Reply-To: <CAEDnbHCmr_ZB5aFt+kQ7S8N0K=jboOBL=nLy7n-DLCa1Eqr2bA@mail.gmail.com>
References: <CAEDnbHCmr_ZB5aFt+kQ7S8N0K=jboOBL=nLy7n-DLCa1Eqr2bA@mail.gmail.com>
Message-ID: <CAA7j38K33ngYBqrbwLhRC-zcHuTQKnY-RmufZjV2OJiE2vYMuQ@mail.gmail.com>

Hi Balu,

The Apiman Gateway does not have any support for injection. That's
only on the Apiman Manager side, I'm afraid (for performance reasons).

I understand the lack of easy logging availability in these components
is a point of frustration, and we will look to address that in a
future release.

A temporary workaround is to just directly use your logger of choice for now.

Regards,
Marc

On 28 August 2017 at 14:05, Balu S <sbalu27 at gmail.com> wrote:
> Hello,
>
> I have a custom error and failure writers that implements IPolicyErrorWriter
> and IPolicyFailureWriter respectively. But these implementation methods does
> not provide IPolicyContext object to access loggers. However this is
> possible from IDataPolicy.
>
> So I have tried to inject the ApimanLogger like below, but it always yields
> null. I have include the neccesary jar as "provided" scope in pom.xml.
>
>
> example:
> public class MyPolicyErrorWriter implements IPolicyErrorWriter{
>
> @Inject @ApimanLogger(MyPolicyErrorWriter.class)
> IApimanLogger logger;
>
> @Override
> public void write(ApiRequest request, Throwable error,
> IApiClientResponse response) {
>
>  // here logger is always null?
>             logger.info("
>          }
> ......
>
> Could you please suggest how can I add IApimanLogger to my custom error or
> failure writers ?
>
> Best regards
> Balu
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From sbalu27 at gmail.com  Thu Aug 31 11:59:36 2017
From: sbalu27 at gmail.com (Balu S)
Date: Thu, 31 Aug 2017 17:59:36 +0200
Subject: [Apiman-user] policy error/failure writer cannot find logger
In-Reply-To: <CAA7j38K33ngYBqrbwLhRC-zcHuTQKnY-RmufZjV2OJiE2vYMuQ@mail.gmail.com>
References: <CAEDnbHCmr_ZB5aFt+kQ7S8N0K=jboOBL=nLy7n-DLCa1Eqr2bA@mail.gmail.com>
	<CAA7j38K33ngYBqrbwLhRC-zcHuTQKnY-RmufZjV2OJiE2vYMuQ@mail.gmail.com>
Message-ID: <CAEDnbHCi_JnFNrB96TmG0x+ZreM5MRM=j3OdKzoCUXsyTdMtyg@mail.gmail.com>

Hi Marc,

Thanks for the confirmation.

yes, I have started using separate loggers for them for now :).

regards
Balu

On Thu, Aug 31, 2017 at 1:35 PM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi Balu,
>
> The Apiman Gateway does not have any support for injection. That's
> only on the Apiman Manager side, I'm afraid (for performance reasons).
>
> I understand the lack of easy logging availability in these components
> is a point of frustration, and we will look to address that in a
> future release.
>
> A temporary workaround is to just directly use your logger of choice for
> now.
>
> Regards,
> Marc
>
> On 28 August 2017 at 14:05, Balu S <sbalu27 at gmail.com> wrote:
> > Hello,
> >
> > I have a custom error and failure writers that implements
> IPolicyErrorWriter
> > and IPolicyFailureWriter respectively. But these implementation methods
> does
> > not provide IPolicyContext object to access loggers. However this is
> > possible from IDataPolicy.
> >
> > So I have tried to inject the ApimanLogger like below, but it always
> yields
> > null. I have include the neccesary jar as "provided" scope in pom.xml.
> >
> >
> > example:
> > public class MyPolicyErrorWriter implements IPolicyErrorWriter{
> >
> > @Inject @ApimanLogger(MyPolicyErrorWriter.class)
> > IApimanLogger logger;
> >
> > @Override
> > public void write(ApiRequest request, Throwable error,
> > IApiClientResponse response) {
> >
> >  // here logger is always null?
> >             logger.info("
> >          }
> > ......
> >
> > Could you please suggest how can I add IApimanLogger to my custom error
> or
> > failure writers ?
> >
> > Best regards
> > Balu
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170831/25bf142c/attachment.html 

From stephen at saasindustries.com  Thu Aug 31 13:34:09 2017
From: stephen at saasindustries.com (Stephen Henrie)
Date: Thu, 31 Aug 2017 10:34:09 -0700
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
	<CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
	<CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
Message-ID: <CA+iPe9uxUHaK_+=ZoDwvKKMQC87hkvCmAoz+cESoY8ZTv8Dpmw@mail.gmail.com>

Hi Marc,

Thanks for having had spent some time looking into this, but after a
discussion with my network architect this morning, which I have not been
able to get a hold of until today, I think we may have found the source of
the issue and it most likely has nothing to do with Apiman. We are going to
try to confirm it today. Apparently the default HAProxy configuration for
the HTTPS protocol within kubernetes does not set the proxy headers like
they do for http traffic; not sure why this is.

Stephen

On Wed, Aug 23, 2017 at 4:59 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi Stephen,
>
> Out of interest: can you replicate your setup, but with no policies in
> the chain to see what happens?
>
> Second, perhaps you can try the simple-header-policy
> (https://apiman.gitbooks.io/apiman-user-guide/user-guide/
> gateway/policies.html#_simple_header_policy)
> and let me know what happens (just put some dummy config in and see
> whether the headers still disappear).
>
> I'll try to replicate your setup soon.
>
> Regards,
> Marc
>
> On 22 August 2017 at 17:13, Stephen Henrie <stephen at saasindustries.com>
> wrote:
> > FWIW, it is in the policy code where I am not seeing these headers being
> set
> > correctly:
> >
> > https://github.com/apiman/apiman/blob/master/gateway/
> engine/policies/src/main/java/io/apiman/gateway/engine/
> policies/IPWhitelistPolicy.java#L55
> >
> >
> >
> > On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie
> > <stephen at saasindustries.com> wrote:
> >>
> >> Eric, thanks for the response.
> >>
> >> I had reviewed that code as well, so I believe you when you say that it
> >> should be passing all of those proxy headers along. However, check out
> below
> >> what I am seeing when posting a request to a test service that I am
> running.
> >> It simply dumps the headers The first request is made directly to the
> >> service without going through apiman and the second request is made
> through
> >> apiman.
> >>
> >> I don't think that the issue is in the servlet code, but when these
> >> headers are passed into where policies applied, like somewhere where the
> >> ApiRequest class is created.
> >>
> >> Thanks
> >> Stephen
> >>
> >>
> >> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-host:
> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-port: 80
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-proto: http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : forwarded:
> >> for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.
> router.dev1.saasforge.com;proto=http
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : x-forwarded-for:
> 71.86.141.114
> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1
> >>
> >>
> >>
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : HEADERS:
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
> >> (darwin15.6.0)
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept-encoding: identity
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : connection: Keep-Alive
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : authorization: Bearer
> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ct
> ckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.
> eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2Yi
> LCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJp
> c3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxt
> cy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIx
> ZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJl
> ciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNz
> aW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFl
> YzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hh
> c3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2Zvcmdl
> LmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoi
> LCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2Uu
> Y29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6
> Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNv
> bS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8v
> YXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9z
> dDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJo
> dHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0
> dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0Iiwi
> aHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2Fj
> Y2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5h
> bnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwi
> cmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdl
> LWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmls
> ZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2Vy
> bmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVw
> aGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVA
> Y2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-
> 6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VP
> egRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-
> DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_
> zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2
> bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : accept: */*
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : host:
> >> spring-boot-oauth-demo.user-dev.svc:8080
> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6
> >>
> >>
> >> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann <
> eric.wittmann at redhat.com>
> >> wrote:
> >>>
> >>> GitHub is back up.  Here is the code (when running the servlet version
> of
> >>> the gateway, not the vert.x version) that reads the inbound HTTP
> request
> >>> headers, copying them into the ApiRequest bean:
> >>>
> >>>
> >>> https://github.com/apiman/apiman/blob/master/gateway/
> platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/
> GatewayServlet.java#L263-L280
> >>>
> >>> The only header that gets skipped is X-API-Version.
> >>>
> >>> -Eric
> >>>
> >>>
> >>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann
> >>> <eric.wittmann at redhat.com> wrote:
> >>>>
> >>>> That's very interesting because I don't believe Apiman is stripping
> out
> >>>> any headers from the request (at any point).  If that's happening I
> can't
> >>>> think of what the root cause might be.  IIRC we just copy all request
> >>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
> >>>>
> >>>> GitHub is currently down so I can't send a link to the relevant
> code....
> >>>>
> >>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie
> >>>> <stephen at saasindustries.com> wrote:
> >>>>>
> >>>>>
> >>>>> I have Apiman running in an openshift environment, which is
> essentially
> >>>>> a similar configuration to running in kubernetes. Each container/pod
> is
> >>>>> always receiving http/s requests through an HA Proxy server, so that
> the
> >>>>> x-forwarded-* set of headers get added to each request by the proxy
> server.
> >>>>>
> >>>>> Unfortunately, it appears that the headers which are provided in the
> >>>>> ApiRequet bean when the policy chain processor doApply() method is
> called
> >>>>> does not include these proxy related headers.  This means that the
> standard
> >>>>> policies for the IP white and black listing policies do not work
> when the
> >>>>> apiman gateway is behind a proxy server.  The
> request.getRemoteAddr() method
> >>>>> returns the ip address to the proxy server, so there is no way to
> get the ip
> >>>>> address of the originator since the x-forwarded-for header ( and
> related
> >>>>> headers ) are not found.
> >>>>>
> >>>>> Has anyone else experienced this?  If so, is this by design?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Stephen
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Apiman-user mailing list
> >>>>> Apiman-user at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170831/43628a1e/attachment-0001.html 

From marc.savy at redhat.com  Thu Aug 31 14:02:25 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 31 Aug 2017 19:02:25 +0100
Subject: [Apiman-user] Proxy headers missing for processing policies
In-Reply-To: <CA+iPe9uxUHaK_+=ZoDwvKKMQC87hkvCmAoz+cESoY8ZTv8Dpmw@mail.gmail.com>
References: <CA+iPe9uqJ99n_Ld7v8BY8hEWTBqGijEywm4xDtp5ACrqS0Q+fg@mail.gmail.com>
	<CAP4n9Q--twb9jq5Gn61L0Hs7_tm0b0cv1CVD-nSJx7FRzBAsSQ@mail.gmail.com>
	<CAP4n9Q_T3fKK5dZtoXT9efW0UymkuprpY8sUHnD8AG+_vEx4Qg@mail.gmail.com>
	<CA+iPe9uXA_kQbPg3ueMXUSn+4OJnvgwwp0Xkh4p-PGkKbp-JOw@mail.gmail.com>
	<CA+iPe9v4QeGw3eO3NUAtBWpAqRosYzZLj+ocekt-SXVysd3wug@mail.gmail.com>
	<CAA7j38+6VFDY0R5ScMitkJgdpSQOa_3bq=gcDPBm2LbdrO65pA@mail.gmail.com>
	<CA+iPe9uxUHaK_+=ZoDwvKKMQC87hkvCmAoz+cESoY8ZTv8Dpmw@mail.gmail.com>
Message-ID: <CAA7j38+TEELJQEZSRcEvd2j-6p+5FdVg17h24Y=U+o1m2Ecc+w@mail.gmail.com>

Thanks for the update, Stephen. Useful to know this as I'm sure other
folk could run into the same issue.

On 31 August 2017 at 18:34, Stephen Henrie <stephen at saasindustries.com> wrote:
> Hi Marc,
>
> Thanks for having had spent some time looking into this, but after a
> discussion with my network architect this morning, which I have not been
> able to get a hold of until today, I think we may have found the source of
> the issue and it most likely has nothing to do with Apiman. We are going to
> try to confirm it today. Apparently the default HAProxy configuration for
> the HTTPS protocol within kubernetes does not set the proxy headers like
> they do for http traffic; not sure why this is.
>
> Stephen
>
> On Wed, Aug 23, 2017 at 4:59 AM, Marc Savy <marc.savy at redhat.com> wrote:
>>
>> Hi Stephen,
>>
>> Out of interest: can you replicate your setup, but with no policies in
>> the chain to see what happens?
>>
>> Second, perhaps you can try the simple-header-policy
>>
>> (https://apiman.gitbooks.io/apiman-user-guide/user-guide/gateway/policies.html#_simple_header_policy)
>> and let me know what happens (just put some dummy config in and see
>> whether the headers still disappear).
>>
>> I'll try to replicate your setup soon.
>>
>> Regards,
>> Marc
>>
>> On 22 August 2017 at 17:13, Stephen Henrie <stephen at saasindustries.com>
>> wrote:
>> > FWIW, it is in the policy code where I am not seeing these headers being
>> > set
>> > correctly:
>> >
>> >
>> > https://github.com/apiman/apiman/blob/master/gateway/engine/policies/src/main/java/io/apiman/gateway/engine/policies/IPWhitelistPolicy.java#L55
>> >
>> >
>> >
>> > On Tue, Aug 22, 2017 at 11:01 AM, Stephen Henrie
>> > <stephen at saasindustries.com> wrote:
>> >>
>> >> Eric, thanks for the response.
>> >>
>> >> I had reviewed that code as well, so I believe you when you say that it
>> >> should be passing all of those proxy headers along. However, check out
>> >> below
>> >> what I am seeing when posting a request to a test service that I am
>> >> running.
>> >> It simply dumps the headers The first request is made directly to the
>> >> service without going through apiman and the second request is made
>> >> through
>> >> apiman.
>> >>
>> >> I don't think that the issue is in the servlet code, but when these
>> >> headers are passed into where policies applied, like somewhere where
>> >> the
>> >> ApiRequest class is created.
>> >>
>> >> Thanks
>> >> Stephen
>> >>
>> >>
>> >> 2017-08-22 15:55:21.063 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : HEADERS:
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
>> >> (darwin15.6.0)
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : accept: */*
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : accept-encoding: identity
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : host:
>> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : authorization: Bearer
>> >>
>> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : x-forwarded-host:
>> >> spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : x-forwarded-port: 80
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : x-forwarded-proto: http
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : forwarded:
>> >>
>> >> for=71.86.141.114;host=spring-boot-oauth-demo-user-dev.router.dev1.saasforge.com;proto=http
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : x-forwarded-for:
>> >> 71.86.141.114
>> >> 2017-08-22 15:55:21.065 DEBUG 1 --- [nio-8080-exec-7]
>> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.1
>> >>
>> >>
>> >>
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : HEADERS:
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : user-agent: Wget/1.19.1
>> >> (darwin15.6.0)
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : accept-encoding: identity
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : connection: Keep-Alive
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : authorization: Bearer
>> >>
>> >> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ1bVJaV1ctckJrVnZGUTNyNlhCWkVCNGZwamxGV2FBcTBLWU1qZThEZnNjIn0.eyJqdGkiOiI5ZWQ0YTQwOC05ZGM3LTRlMzMtOTkxNy1mNjdkYWU1YjJjM2YiLCJleHAiOjE1MDM0MTc1NDAsIm5iZiI6MCwiaWF0IjoxNTAzNDE3MjQwLCJpc3MiOiJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9hdXRoL3JlYWxtcy9jaGFzc2kiLCJhdWQiOiJjaGFzc2ktd2ViLWFwcCIsInN1YiI6ImI0ZGIxZmU5LTNmYzUtNDJjMy04NTg0LWQwZWJlMzRhM2U5MyIsInR5cCI6IkJlYXJlciIsImF6cCI6ImNoYXNzaS13ZWItYXBwIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiN2NmZjVhZDEtNjE3NC00YzY1LTk5NGQtYzk4ZTdkNWFlYzNhIiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vY2hhc3NpLWF1dGgtcHJveHktdXNlci1kZXYucm91dGVyLmRldjIuc2Fhc2ZvcmdlLmNvbTo3ODg4IiwiaHR0cDovL2F1dGguZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXV0aC11c2VyLWRldi5yb3V0ZXIuZGV2MS5zYWFzZm9yZ2UuY29tIiwiaHR0cDovL2FwcC5kZXYxLnNhYXNmb3JnZS5jb20vKiIsImh0dHA6Ly9kZXYxLWFwcHMuczMtd2Vic2l0ZS11cy1lYXN0LTEuYW1hem9uYXdzLmNvbS9kYXNoYm9hcmQiLCJodHRwOi8vbG9jYWxob3N0OjMwMDEiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbTo4MC8qIiwiaHR0cDovL2xvY2FsaG9zdDozMDAwIiwiaHR0cHM6Ly9hcGkuZGV2MS5zYWFzZm9yZ2UuY29tLyoiLCJodHRwOi8vYXBwLmRldjEuc2Fhc2ZvcmdlLmNvbS9kYXNoYm9hcmQvKiIsImh0dHA6Ly9hcHAuZGV2MS5zYWFzZm9yZ2UuY29tL2JvYi1zbW9rZS10ZXN0IiwiaHR0cHM6Ly9hdXRoLmRldjEuc2Fhc2ZvcmdlLmNvbS8qIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJiaWxsaW5nLWFkbWluaXN0cmF0b3IiLCJ0ZW5hbnQtb3duZXIiLCJkZXZlbG9wZXIiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJTdGVwaGVuIEhlbnJpZSIsInByZWZlcnJlZF91c2VybmFtZSI6InNoZW5yaWVAY2hhc3NpLmNvbSIsImdpdmVuX25hbWUiOiJTdGVwaGVuIiwiZmFtaWx5X25hbWUiOiJIZW5yaWUiLCJlbWFpbCI6InNoZW5yaWVAY2hhc3NpLmNvbSJ9.AxhMpP3gMbh96BI7HNqLwZNjmUAiifzGhouoLpHwjggWDf6YX-6geJb7yhkWTg4b7i5wYBC7OQpstgmfg01RIjQ_BJsJz8jxEwouvIufEDwWkmbtp9z0VPegRYi8y405RQya18W2-m7lbi7LsBrK4cAJ-kgQ_-k5R_vxQFuAgmgZC-NYYtpvP0swrTNxHO-DHJEolYb9wXjk_hFYEY9MBTqLeILvFEyjpkA_66WEWWE_zA6RTw6ZU1uiwEDOCsDMHjejVDaZzXA78chQRAhlUcgQSG7ATZNKcU5hnDu2bhQ79hugOdCa83Snl0RZUWXYoIB9vgapJosAP5rBUbTdJA
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : accept: */*
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : host:
>> >> spring-boot-oauth-demo.user-dev.svc:8080
>> >> 2017-08-22 15:55:38.561 DEBUG 1 --- [nio-8080-exec-9]
>> >> com.saas.controller.ApiRestController    : RemoteAddr: 172.17.0.6
>> >>
>> >>
>> >> On Mon, Aug 21, 2017 at 9:50 AM, Eric Wittmann
>> >> <eric.wittmann at redhat.com>
>> >> wrote:
>> >>>
>> >>> GitHub is back up.  Here is the code (when running the servlet version
>> >>> of
>> >>> the gateway, not the vert.x version) that reads the inbound HTTP
>> >>> request
>> >>> headers, copying them into the ApiRequest bean:
>> >>>
>> >>>
>> >>>
>> >>> https://github.com/apiman/apiman/blob/master/gateway/platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/GatewayServlet.java#L263-L280
>> >>>
>> >>> The only header that gets skipped is X-API-Version.
>> >>>
>> >>> -Eric
>> >>>
>> >>>
>> >>> On Mon, Aug 21, 2017 at 10:04 AM, Eric Wittmann
>> >>> <eric.wittmann at redhat.com> wrote:
>> >>>>
>> >>>> That's very interesting because I don't believe Apiman is stripping
>> >>>> out
>> >>>> any headers from the request (at any point).  If that's happening I
>> >>>> can't
>> >>>> think of what the root cause might be.  IIRC we just copy all request
>> >>>> headers from the inbound HttpServletRequest into the ApiRequest bean.
>> >>>>
>> >>>> GitHub is currently down so I can't send a link to the relevant
>> >>>> code....
>> >>>>
>> >>>> On Fri, Aug 18, 2017 at 11:16 PM, Stephen Henrie
>> >>>> <stephen at saasindustries.com> wrote:
>> >>>>>
>> >>>>>
>> >>>>> I have Apiman running in an openshift environment, which is
>> >>>>> essentially
>> >>>>> a similar configuration to running in kubernetes. Each container/pod
>> >>>>> is
>> >>>>> always receiving http/s requests through an HA Proxy server, so that
>> >>>>> the
>> >>>>> x-forwarded-* set of headers get added to each request by the proxy
>> >>>>> server.
>> >>>>>
>> >>>>> Unfortunately, it appears that the headers which are provided in the
>> >>>>> ApiRequet bean when the policy chain processor doApply() method is
>> >>>>> called
>> >>>>> does not include these proxy related headers.  This means that the
>> >>>>> standard
>> >>>>> policies for the IP white and black listing policies do not work
>> >>>>> when the
>> >>>>> apiman gateway is behind a proxy server.  The
>> >>>>> request.getRemoteAddr() method
>> >>>>> returns the ip address to the proxy server, so there is no way to
>> >>>>> get the ip
>> >>>>> address of the originator since the x-forwarded-for header ( and
>> >>>>> related
>> >>>>> headers ) are not found.
>> >>>>>
>> >>>>> Has anyone else experienced this?  If so, is this by design?
>> >>>>>
>> >>>>> Thanks!
>> >>>>>
>> >>>>> Stephen
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Apiman-user mailing list
>> >>>>> Apiman-user at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>
>