Page MenuHomeElementl

[dagit] Add optional authorization header to HTTP requests
ClosedPublic

Authored by sidkmenon on May 7 2021, 7:01 PM.
Tags
None
Referenced Files
F2776953: D7810.id37158.diff
Wed, Feb 8, 11:31 AM
Unknown Object (File)
Tue, Feb 7, 2:31 PM
Unknown Object (File)
Sun, Feb 5, 4:58 PM
Unknown Object (File)
Fri, Feb 3, 2:07 AM
Unknown Object (File)
Wed, Jan 11, 6:40 PM
Unknown Object (File)
Dec 24 2022, 4:07 PM
Unknown Object (File)
Dec 9 2022, 5:18 AM
Unknown Object (File)
Dec 7 2022, 7:51 AM
Subscribers
None

Details

Summary

Used in conjunction with D7805

Test Plan

manual run in dagit & network tab confirms that the "authorization" header is present

Diff Detail

Repository
R1 dagster
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sidkmenon held this revision as a draft.

Refactoring to a generic auth token

sidkmenon retitled this revision from [test][dagit] Add auth headers for run attribution to [dagit] Add auth headers for run attribution.May 7 2021, 8:07 PM
sidkmenon retitled this revision from [dagit] Add auth headers for run attribution to [dagit] Add optional authorization header to HTTP requests .

Hmm I think this works for now because we're planning on using the authToken primarily to attribute runs, etc. to different users, but I think if we really wanted security we'd need to add auth to the websockets interface as well (or stop using it), right? I wonder if we should add a small comment in here explaining that there are still un-authorized GraphQL requests being made from the app in the few places we need websockets?

This revision is now accepted and ready to land.May 7 2021, 9:04 PM

Hmm I think this works for now because we're planning on using the authToken primarily to attribute runs, etc. to different users, but I think if we really wanted security we'd need to add auth to the websockets interface as well (or stop using it), right? I wonder if we should add a small comment in here explaining that there are still un-authorized GraphQL requests being made from the app in the few places we need websockets?

Yup this all makes sense. I'll add a comment - I think we're doing pretty extensive work on getting a more full-blown auth done on the backend, I just figured that this would be a way to get a pluggable header in the HTTP requests if needed. I think I'll rename to headerAuthToken instead of authToken so it's clear that the token is attached to a header.

sidkmenon retitled this revision from [dagit] Add optional authorization header to HTTP requests to [dagit] Add optional authorization header to HTTP requests.

Adding comment and renaming to headerAuthToken