Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose domain and endpoint list #1610

Open
cleve-fauna opened this issue Apr 30, 2024 · 2 comments
Open

Expose domain and endpoint list #1610

cleve-fauna opened this issue Apr 30, 2024 · 2 comments

Comments

@cleve-fauna
Copy link

cleve-fauna commented Apr 30, 2024

Note:
If you have a feature request, you should contact support so the request can be properly tracked.

I have contacted support as well.

Is your feature request related to a problem? Please describe.
My team is building an OAuth 2.0 integration with Datadog. We will act as the client and Datadog will act as the authorization server. When the integration is kicked off from the Datadog UI your system sends a 'domain' and 'site' query parameter to our service indicating to what URL we should deliver our authorization code request payload.

We will be checking the URL implied by these parameters to verify that:

  • it is actually datadog

We will do this via an allow list.

I would like it to be possible to automatically generate this allow list by leveraging one of your programming language clients. That way we do not couple our system to following the release of new datadog endpoints.

AWS does this for example with their SDKs - users can automatically configure a client to a given 'region' without needing to know any particular details and if a URL comes from outside a system, that system can check the URL agains AWS's set.

Describe the solution you'd like
I would like the clients to expose URL validation capabilities that ensure a URL is a valid datadog URL.
Describe alternatives you've considered

  1. We will build an allow list ourselves until this is launched.A
  2. we will also rely on typescript as a fail safe since your client has type guards on configuring a client.
    (1) is stronger than (2) and so while we will do both I would stll like to automate this.

Additional context

I have an open support ticket for this request. The case ID is 1671182

@skarimo
Copy link
Member

skarimo commented May 20, 2024

👋 this should already be possible using the ServerConfiguration object: https://github.com/DataDog/datadog-api-client-typescript/blob/master/packages/datadog-api-client-common/servers.ts#L64

By default, the typescript client uses server1 which validates the site to be oneof the enums here: https://github.com/DataDog/datadog-api-client-typescript/blob/master/packages/datadog-api-client-common/servers.ts#L69-L74

Does this work for your use case?

Copy link

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of this project.

  2. Comment that the issue is still reproducible and include updated details requested in the issue template.

@github-actions github-actions bot added the stale label Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants