Links always use public endpoint

[Haneef Ali]

Link always uses public port. It should use the port based on the request.

e.g if the call is curl https://localhost:35357/v3/users, I expect the link to have https://localhost:35357/v3/users/<userid> and not https://localhost:5000/v3/users. This defeats the whole purpose of having links for navigation. Port 5000 may not even be accessible to the caller

[Dolph Mathews (dolph)]

It's actually using the public_endpoint configuration, which happens to consume the public_port value.

The public endpoint should always be accessible to any caller. In the case of v3, the port used doesn't matter, as the same exact same API capabilities are deployed on both :5000/v3/ and :35357/v3/ by default, and authorization is instead dictated by policy. In the long run, I don't see a need to have two distinct ports out of the box, although that should remain a deployment option that clients should be aware of.

What would make a more significant impact is if the caller accessed keystone on an internal interface (which is how "admin" should be deployed), and subsequently followed a link across a public interface unintentionally.

Leaving this as wishlist because we don't have a client intelligent enough to do this, yet.

[Haneef Ali (haneef)]

Consider the following use case.

1) keystone is deployed under apache using mod-wsgi. So apache is lisening on some port which is not related to the configuration in keytone.conf. In this case keystone blindly returns links using the port from the configuration.

The correct behavior is to use the request url and use the port from the request url

2) Also your point is also valid. In v3 both public and admin have same contents. If I'm hittng via internal interface , why should I get public host and port in the link.

[Dolph Mathews (dolph)]

1) explicitly set the public_endpoint to whatever apache is serving on (or whatever your load balancer in front of apache is serving on)

[Scott Devoid (scott-devoid)]

1. This won't work in all cases. E.g. if you have multiple load balancers on different physical networks sending requests to keystone.

My suggestion (reported here: https://bugs.launchpad.net/keystone/+bug/1272103) is to use relative URLs in the JSON body.

[Scott Devoid (scott-devoid)]

Has there been any further discussion on this bug?

[Dolph Mathews (dolph)]

Subscribed Jamie Lennox who's done some work in this area recently.

[Alexey Miroshkin (amirosh)]

I think this bug was fixed by Jamie Lennox, at least in case when public_endpoint isn't set. If public_endpoint is set the base url will contain it by design.

[Jamie Lennox (jamielennox)]

Right, so if public_endpoint is set we have to continue to use it for compatibility. If public_endpoint is not set then all links should be relative to the URL that was used to call the service, so if you use the internal URL then it will be the internal links.

Ideally we would deprecate the public_endpoint etc values from conf and fix up our doc to say so, however i think there are catalog related uses of those options.

[Haneef Ali (haneef)]

I don't think the fix solves the problem

The reason we have these settings are to enable deployment using load balancer use case

If both admin and public url are under different load balancer, then we need we need to set these values in keystone.conf.
In that case we can't say, we are always going to return "public_endpoint" . Public_endpoint may not routable from internal network and vice versa for admin endpoint.

Typical configuration.
  Keystone running under apache
  Internal load balancer using internal certificate which serves admin/internal endpoint
  Hardware load balancer using public certficates which serves public endpoint
  keystone.conf
      admin-endpoint = internal load balancer
     public-endpoint = external load balancer

[Julian Edwards (julian-edwards)]

I filed bug 1558876 the other day and it seems to be closely related to this, if not the same problem (thanks Morgan for pointing out this one). The main difference is that my bug is a bit more of a showstopper since you can't even see the catalog when using v3.

I am with Haneef on this; the links returned should really be relative to the original request until you can start using the catalog endpoints at least

[Morgan Fainberg (mdrnstm)]

Marking as wont fix. The solution has been discussed and is recommended that the public_endpoint be unset.