-
Notifications
You must be signed in to change notification settings - Fork 65
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
Add docs related to auth when using Kino.Proxy #433
Conversation
|
||
Kino.Proxy.listen(fn | ||
%{path_info: ["export", "data"]} = conn -> | ||
["Bearer " <> ^token] = Plug.Conn.get_req_header(conn, "authorization") | ||
data = "some data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, using bearer tokens may be the best example, since tokens are most common for APIs (and Kino.Proxy would most likely be used for APIs?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed.
I'll change from HTTP basic auth to HTTP Bearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about leaving this example as simple as possible, with no auth. And the auth would be below, inside the admonition block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. Keeping it simple is a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josevalim maybe this version?
Although I'm not 100% satisfied with it. I accept suggestions.
|
||
Kino.Proxy.listen(fn | ||
%{path_info: ["export", "data"]} = conn -> | ||
["Bearer " <> ^token] = Plug.Conn.get_req_header(conn, "authorization") | ||
data = "some data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about leaving this example as simple as possible, with no auth. And the auth would be below, inside the admonition block.
> implement your own authentication mechanism. Here's a simple example. | ||
> | ||
> ```elixir | ||
> Kino.Proxy.listen(fn conn -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josevalim what about this code example with a simple Bearer auth?
Kino.Proxy.listen(fn conn ->
api_token = "my-secret-api-token"
with ["Bearer " <> client_token] <- Plug.Conn.get_req_header(conn, "authorization"),
true <- api_token == client_token do
Plug.Conn.send_resp(conn, 200, "hello")
else
_ ->
conn
|> Plug.Conn.put_resp_header("www-authenticate", "Bearer")
|> Plug.Conn.send_resp(401, "Unauthorized")
end
end)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kino.Proxy.listen(fn conn ->
api_token = "my-secret-api-token"
case Plug.Conn.get_req_header(conn, "authorization") do
["Bearer " <> ^api_token] ->
Plug.Conn.send_resp(conn, 200, "hello")
_ ->
conn
|> Plug.Conn.put_resp_header("www-authenticate", "Bearer")
|> Plug.Conn.send_resp(401, "Unauthorized")
end
end)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the example above is unsafe, we want to use Plug.Crypto.secure_compare
:( It may be worth keeping it as user:pass just for simplicity. Sorry for the back and forth. :(
> The paths exposed by `Kino.Proxy` don't use the authentication mechanisms | ||
> defined in your Livebook instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josevalim I started to wonder if we should put them in the /public
namespace. The main downside is that it differs more from the base app/session path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can always add more routes in the future. I think we have a good starting set. I can also see it being used for coordinating tasks inside their own infrastructure, but still not exposing it to the world.
@josevalim can I merge this? |
@hugobarauna to merge this, you should either use Plug.BasicAuth, or keep the token aprpoach, but use |
@josevalim now it should be ready to merge. Please take a last look. |
No description provided.