In order to change a service definition in an existing deployment you have
to follow this special little dance to make sure the changes get picked up:
1. change service definition
2. restart the gateway so that it loads the new service definition server
side
3. touch the topology that is hosting t
If you change the service.xml or rewrite.xml you also need to touch or
modify the topology to create a redeployment. You should see in the
gateway.log that the topology was redeployed. If you don't see that,
your changes probably didn't take effect.
Kevin Risden
On Thu, Dec 20, 2018 at 9:20 AM To
I changed line:
in service.xml
to:
and name of authentication provider I changed from anonymous to
ShiroProvider.
Nothing happened. Access is open as it was.
Tom
On Thu, 20 Dec 2018 at 14:39, larry mccay wrote:
> If you followed the proxying article and your service definition is
> indicati
If you followed the proxying article and your service definition is
indicating the anonymous authentication provider then that is the issue.
That overrides any provider configured in the topology.
On Thu, Dec 20, 2018, 8:27 AM Kevin Risden If your service.xml has
>
> classname="org.apache.knox.
If your service.xml has
Then all the headers including the AUTHORIZATION header are passed
through to the backend. This would mean that your backend is
responsible for authentication.
If you want Knox to do authentication, either remove the dispatch line
or change it to:
This will then pass
