sidoh/gist:ca6ef785b4bcb4dde613cb5b7cf35f8d

## gistfile1.txt
11:27 AM] sidoh: Hello!  I’m working on a custom auth provider and have a commit I’d like to open a PR for, but wanted to sanity check here beforehand.  The change is here: https://github.com/sidoh/home-assistant/commit/1c5bb8b0ef696532b8225e6ab6ceb8d42a74c2df.  It’s just adding headers and cookies from the /auth/login_flow request to the flow context dict.  The commit summarizes some scenarios where I think this would be useful.

(( sidebar -- I know custom auth providers aren’t directly supported yet; I’m just patching it into my home-assistant install right now to get this done. ))
[1:02 PM] balloob: @sidoh I don't fully see how headers would work, you would need to make your auth service aware of the auth provider
[1:02 PM] balloob: And then that one makes a POST request ?
[1:02 PM] balloob: because right now the POST request is made from the login page via JS
[1:03 PM] sidoh: Right, I discovered that as I was developing :slight_smile:
[1:03 PM] sidoh: In the second bullet, I think the header that'd be most useful is Referer, which could contain some query args.
[1:04 PM] sidoh: In my case, I'm using cookies.  I have a setup that auths using client certificates, and redirects to and endpoint with an issued JWT, which is set in the cookie.
[1:05 PM] sidoh: The headers thing was more hypothetical.  When I started on this path and saw that IP was available in the context, I sort of expected all/more stuff from the origin request to be present.  When I saw it wasn't, figured I'd add it :slight_smile:
[1:06 PM] balloob: I'm not a fan of adding things because we can. Anything we add has to be supported forever
[1:07 PM] sidoh: Certainly can relate to that instinct.   Does the cookie piece seem more passable?
[1:18 PM] sidoh: The thrust of what I'm trying to do here is to make it possible for something upstream of HomeAssistant (Openresty, nginx) to be in control of auth.  The sane mechanisms a reverse proxy have to communicate with an upstream are essentially all header-based.
	11:27 AM] sidoh: Hello! I’m working on a custom auth provider and have a commit I’d like to open a PR for, but wanted to sanity check here beforehand. The change is here: https://github.com/sidoh/home-assistant/commit/1c5bb8b0ef696532b8225e6ab6ceb8d42a74c2df. It’s just adding headers and cookies from the /auth/login_flow request to the flow context dict. The commit summarizes some scenarios where I think this would be useful.

	(( sidebar -- I know custom auth providers aren’t directly supported yet; I’m just patching it into my home-assistant install right now to get this done. ))
	[1:02 PM] balloob: @sidoh I don't fully see how headers would work, you would need to make your auth service aware of the auth provider
	[1:02 PM] balloob: And then that one makes a POST request ?
	[1:02 PM] balloob: because right now the POST request is made from the login page via JS
	[1:03 PM] sidoh: Right, I discovered that as I was developing :slight_smile:
	[1:03 PM] sidoh: In the second bullet, I think the header that'd be most useful is Referer, which could contain some query args.
	[1:04 PM] sidoh: In my case, I'm using cookies. I have a setup that auths using client certificates, and redirects to and endpoint with an issued JWT, which is set in the cookie.
	[1:05 PM] sidoh: The headers thing was more hypothetical. When I started on this path and saw that IP was available in the context, I sort of expected all/more stuff from the origin request to be present. When I saw it wasn't, figured I'd add it :slight_smile:
	[1:06 PM] balloob: I'm not a fan of adding things because we can. Anything we add has to be supported forever
	[1:07 PM] sidoh: Certainly can relate to that instinct. Does the cookie piece seem more passable?
	[1:18 PM] sidoh: The thrust of what I'm trying to do here is to make it possible for something upstream of HomeAssistant (Openresty, nginx) to be in control of auth. The sane mechanisms a reverse proxy have to communicate with an upstream are essentially all header-based.