Mirror external services as well
Benehiko opened this issue · comments
Preflight checklist
- I could not find a solution in the existing issues, docs, nor discussions.
- I agree to follow this project's Code of Conduct.
- I have read and am following this repository's Contribution Guidelines.
- This issue affects my Ory Cloud project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe your problem
When developing locally, some services might fall outside of the local environment, however, the cookie retrieved from Ory Cloud will be scoped to the Ory domain or CNAME domain which are translated to localhost with the ory tunnel. When we now communicate with external services we would need to pass along the cookie from the local environment and transform it back to the receiving domain to an external service, e.g Azure API Manager.
Describe your ideal solution
Be able to set more upstream URLs to mirror and not just Ory Cloud.
These upstream URLs should also translate the cookie from localhost to the original domain.
Workarounds or alternatives
None
Version
v0.1.36
Additional Context
https://ory-community.slack.com/archives/C02MR4DEEGH/p1660033017459529
I read through the thread, it's an interesting question. Basically the problem arises when you run basically three services:
- Local development system (e.g. a UI)
- Remote development system (e.g. something on Heroku)
- Ory Cloud
The problem is getting the credentials to the remote system while developing locally.
I don't really have a good solution for this at hand at the moment. It's a complex set of problems and it depends a bit on the use case. I do have some ideas, though - but they will require some time to manifest.
Thanks @aeneasr
The easiest solution would be to offer an API where you can exchange your session token / cookie for a JSON Web Token, probably. I had this in the back of my head for some time.
@richard-peters a potential workaround would be to set up a subdomain of the domain you use in Azure (so e.g. local.myazuredomain.com) which routes to 127.0.0.1, and then set up the ory tunnel to use that domain. It's a bit of effort to add a localhost rewrite for a domain (using e.g. /etc/hosts) and it's a bit different on every OS, but it is a workaround to get you unblocked :)
You can probably find how to do this on Stackoverflow for any OS flavor :)
@aeneasr this is the approach I've taken but I can't get it to work locally (I can see how it may work on a hosted staging instance) - the following will expose Ory APIs at //localhost:4000, which I don't think helps?
ory tunnel --dev --project xx-xx-xx http://local.mydomain.com:3000
If you check ory help tunnel it will show you different configs, one of them should be the one you need (it has two args iirc)
Would this need a custom domain added to Ory Cloud (with the same root domain) and for calls (via the tunnel) to Ory to be on http://auth.mydomain.com:4000?
No, it should all be doable in the Ory Tunnel completely:
ory tunnel --dev --project xx-xx-xx \
http://local.mydomain.com:3000 \
http://ory.mydomain.com:3000 \
--cookie-domain example.org
With an /etc/host of:
127.0.0.1 local.mydomain.com
127.0.0.1 ory.mydomain.com
That should do it!
Many thanks, I'm able to hit my API with the Ory session cookies with the above configuration.
Hello contributors!
I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
- open a PR referencing and resolving the issue;
- leave a comment on it and discuss ideas on how you could contribute towards resolving it;
- leave a comment and describe in detail why this issue is critical for your use case;
- open a new issue with updated details and a plan for resolving the issue.
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.
Unfortunately, burnout has become a topic of concern amongst open-source projects.
It can lead to severe personal and health issues as well as opening catastrophic attack vectors.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.
If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.
Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!
Thank you 🙏✌️