Skip to content

Assume Viewer Credentials when running on Connect #398

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

Open
tdstein opened this issue Mar 11, 2025 · 1 comment
Open

Assume Viewer Credentials when running on Connect #398

tdstein opened this issue Mar 11, 2025 · 1 comment
Assignees
Labels
breaking This is a breaking change enhancement New feature or request sdk Used for automation

Comments

@tdstein
Copy link
Collaborator

tdstein commented Mar 11, 2025

The general expectation when running applications on Connect is that the application is running using the visitor's credentials. This is not the current behavior. Instead, the SDK uses the CONNECT_API_KEY variable, which belongs to the content owner, not the visitor.

Therefore, the default behavior should be as follows:

When running on Connect, assume that a visitor integration is configured. If the integration is not set, provide a sensible error message that directs the user to create the integration or explicitly overrides this behavior. When the integration is set, it assumes the visitor's credentials via the HTTP header.

When running off Connect, assume the current behavior (e.g., CONNECT_API_KEY is set).

@github-actions github-actions bot added the sdk Used for automation label Mar 11, 2025
@tdstein tdstein added enhancement New feature or request breaking This is a breaking change and removed sdk Used for automation labels Mar 11, 2025
@github-actions github-actions bot added the sdk Used for automation label Mar 11, 2025
@tdstein tdstein self-assigned this Mar 21, 2025
@tdstein
Copy link
Collaborator Author

tdstein commented Mar 21, 2025

I don't know if this is viable.

I haven't found a generic solution to capture the request headers outside an API framework context. The SDK client doesn't know how the request headers are captured since this is specific to the API framework implementation. For example, when using Flask, I can use flask.request.headers (see https://flask.palletsprojects.com/en/stable/quickstart/#context-locals). Similar solutions exist in each API framework, but they are specific to the framework. There isn't a generic solution.

The proper way to address this is actually within the Connect content proxy layer. A possible solution is to switch the authorization to the viewer, instead of the content owner.

cc @jonkeane

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This is a breaking change enhancement New feature or request sdk Used for automation
Projects
None yet
Development

No branches or pull requests

1 participant