-
Notifications
You must be signed in to change notification settings - Fork 346
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
Sending back cookies #155
Comments
thank you @teamon, but if there are multiple cookies incl. the JSESSIONID? The "set-cookie" is a key in a map, and wouldn't be overwritten, in the case I need to set multiple "Set-Cookie" header entries? With the middleware workaround discussed in #37 , I can indeed have access to the original headers, excerpt:
but I am not sure how to send them back, since the "Set-Cookie" (normalized) is unique (in a map). |
Ahh right... This isn't possible right now. You can hack around it with: # create a custom adapter
defmodule MyClient do
use Tesla
adapter :custom_adapter
def custom_adapter(env, opts) do
headers = env.opts[:raw_headers]
env = %{env | headers: headers}
Tesla.Adapter.Hackney.call(env)
end
end
# set :raw_headers opt
get("/...", opts: [raw_headers: [{"set-cookie", "aaa"}, {"set-cookie", "bbb"}, ...]]) This should work with hackney and ibrowse adapters, it will break with httpc (because it does I'm adding this issue to the list of breaking changes for 1.0 (#129) |
Ahaaa :) Cool! I'll write my own adapter then, as you mentioned, thank you! Going forward, are the headers becoming a Keyword list, rather than a Map, for Tesla 1.0? |
👍 |
@teamon - in the absence of a cookie jar, what is the recommended method, in the current version (not future 1.x) for passing some of the Response headers, back to a built client env, so that these (Response) headers can be reused by get/post/etc, w/o explicitly setting them as get/post/etc I am using this issue (#37) as a reference: defmodule Client do
use Tesla
def new do
Tesla.build_client [], [
:keep_original_headers
]
end
def keep_original_headers(env, next) do
env = Tesla.run(env, next)
Tesla.put_opt(env, :original_headers, env.headers)
end
end I can see the |
Since everything in elixir is immutable the only way to use headers from once response in another reqeust is to pass it when performing the request. This should work, again, not tested. defmodule MyClient do
use Tesla
plug :keep_original_headers
adapter :run_with_original_headers
def new(prev_env) do
# add middleware with dynamic opts argument
Tesla.build_client [], [
{:apply_original_headers, prev_env.opts[:original_headers]}
]
end
def apply_original_headers(env, next, original_headers) do
# get that dynamic opts value and set it as :original_headers
env
|> Tesla.put_opt(:original_headers, original_headers)
|> Tesla.run(next)
end
def run_with_original_headers(env, opts) do
# override request headers with original_headers from opts
headers = env.opts[:original_headers]
env = %{env | headers: headers}
Tesla.Adapter.Hackney.call(env)
end
def keep_original_headers(env, next) do
# after the request put original_headers in opts
env = Tesla.run(env, next)
Tesla.put_opt(env, :original_headers, env.headers)
end
end
env1 = MyClient.new() |> MyClient.post("/login")
env2 = MyClient.new(env1) |> MyClient.get("/data") |
thank you @teamon! |
@florinpatrascu Please try tesla from # mix.exs
{:tesla, github: "teamon/tesla", branch: "1.0"} There is a Migration guide to help you convert from current version. |
Many thanks, @teamon! I’ll start testing as soon as possible! |
Much better, and lots of improvements. Now I’ll have to refactor my previous hack, and eventually build a cookie-jar :) Thank you, for all this work, @teamon ! |
This is just for people looking how to do it with a later version of tesla. To make it work with 1.4:
|
In #37 (comment) @florinpatrascu wrote
There isn't anything built-in specific to cookies, but you can do it yourself with something alongs these lines:
WARNING: Not tested!
The text was updated successfully, but these errors were encountered: