During callback when issuing 307 redirect, use fully qualified location instead of relative location.

usrbinpikachu commented 6 years ago

We have multiple services hosted behind a single Ambassador service, with multiple domain names. Currently the 307 redirect step returns a location that's a relative path based on the CALLBACK_URL host. If the Ambassador Pro callback handler instead preserved the origin domain, it would allow us to automatically get routed back to the original requesting service.

ghost commented 5 years ago

@richarddli Any updates on this?

richarddli commented 5 years ago

@neurot1cal Jake told me that this was resolved by you guys with the latest version. Please reopen if this is not the case.

usrbinpikachu commented 5 years ago

Ah, sorry, that's on me. I meant the intermittent 404 issue was resolved. Using the fully qualified location is a feature request. My mistake.

richarddli commented 5 years ago

@kudakeru Have you tested FQDN with the latest version? It should be working there. cc @gsagula

gsagula commented 5 years ago

@kudakeru quay.io/datawire/ambassador-pro:0.0.5 should support FQDN. Please, let me know if that works. Thanks!

usrbinpikachu commented 5 years ago

We still have the same problem. A request to fonts-svc.dev.activedisclosure.com triggers an Auth0 interaction, and when the user gets redirected after successful auth, they get sent to console.dev.activedisclosure.com/callback because that's the CALLBACK_URL value. It doesn't appear to be possible to override the callback URL as part of a service's annotations, and Ambassador isn't preserving the domain.

gsagula commented 5 years ago

@kudakeru Thanks for reaching out. I looked into what you have requested and it's not correct to set location with a FQDN url. Please refer to the following RFCs: https://tools.ietf.org/html/rfc7231#section-7.1.2 https://tools.ietf.org/html/rfc3986#section-4.2

What I believe that is happening on your case is that fonts-svc.dev.activedisclosure.com is not in any path of you police. If this is true, your browser will redirect to whatever path is in location, in case the root /. Please refer to this policy example for more details: https://github.com/datawire/ambassador-pro/blob/master/httpbin-policy.yaml

Could you please confirm that fonts-svc.dev.activedisclosure.com is in any path described in your policy?

usrbinpikachu commented 5 years ago

We have it defined as a separate host in the policies file with the following:

host: "fonts-svc.dev.activedisclosure.com" path: /* public: false

On Fri, Nov 9, 2018 at 1:21 PM Gabriel Sagula notifications@github.com wrote:

@kudakeru https://github.com/kudakeru Thanks for reaching out. I looked into what you have requested and it's not correct to set location with a FQDN url. Please refer to the following RFCs: https://tools.ietf.org/html/rfc7231#section-7.1.2 https://tools.ietf.org/html/rfc3986#section-4.2

What I believe that is happening on your case is that fonts-svc.dev.activedisclosure.com is not in any path of you police. If this is true, your browser will redirect to whatever path is in location, in case the root /. Please refer to this policy example for more details: https://github.com/datawire/ambassador-pro/blob/master/httpbin-policy.yaml

Could you please confirm that fonts-svc.dev.activedisclosure.com is in any path described in your policy?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/datawire/ambassador-pro/issues/6#issuecomment-437499035, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjCH2PhwZG_2M3YZF32w3EfpC284_jyks5utfHvgaJpZM4XG_qQ .

gsagula commented 5 years ago

@kudakeru I'm still looking into this ^^^.

gsagula commented 5 years ago

@kudakeru Thank you for your patience. I was able to get the FQDN to work. We will have a new release tomorrow so you can try it out.

cc @rhs

iNoahNothing commented 5 years ago

@kudakeru The fix has been released in the private repo ambassador_pro. We are switching Ambassador Pro releases to this repo so we can have control over who has access to the image as we have released Ambassador Pro open-core to the public. To access the image, you will need to

1. Create the docker-registry secret

I sent the username and password to you over slack

2. Tell the deployment to use this secret when pulling the image

    spec:
      serviceAccountName: ambassador-pro
      imagePullSecrets:
      - name: ambassador-pro-registry-credentials

3. Pull from the private repo

        image: quay.io/datawire/ambassador_pro:auth-0.0.6

Reach out if you have any questions!

datawire / ambassador-pro