Have you tried turning off HttpOnly (in this case not setting it to true) when setting the cookie?
amnu3387
1
jstlroot
Yes.
def sign_in(conn, %{"user" => user_params}) do
case Accounts.token_sign_in(conn, user_params["username"], user_params["password"]) do
{:ok, token, user} ->
conn
|> Plug.Conn.put_resp_cookie("token", token, http_only: false, secure: true, max_age: 604800)
|> render("signed_in.json", user: user)
_ ->
{:error, :unauthorized}
end
end
The access_secure_data gives me exactly the same output:
%Plug.Conn{
adapter: {Plug.Adapters.Cowboy.Conn, :...},
assigns: %{},
before_send: [#Function<1.92707701/1 in Plug.Logger.call/2>],
body_params: %{"withCredentials" => true},
cookies: %{},
halted: false,
host: "localhost",
method: "POST",
owner: #PID<0.799.0>,
params: %{"withCredentials" => true},
path_info: ["api", "access_secure_data"],
path_params: %{},
peer: {{127, 0, 0, 1}, 47456},
port: 4000,
private: %{
MyAppWeb.Router => {[], %{}},
:phoenix_action => :access_secure_data,
:phoenix_controller => MyAppWeb.UserController,
:phoenix_endpoint => MyAppWeb.Endpoint,
:phoenix_format => "json",
:phoenix_layout => {MyAppWeb.LayoutView, :app},
:phoenix_pipelines => [:api],
:phoenix_router => MyAppWeb.Router,
:phoenix_view => MyAppWeb.UserView,
:plug_session_fetch => #Function<1.45862765/1 in Plug.Session.fetch_session/1>
},
query_params: %{},
query_string: "",
remote_ip: {127, 0, 0, 1},
req_cookies: %{},
req_headers: [
{"host", "localhost:4000"},
{"connection", "keep-alive"},
{"content-length", "24"},
{"accept", "application/json, text/plain, */*"},
{"origin", "http://localhost:8080"},
{"user-agent",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36"},
{"content-type", "application/json;charset=UTF-8"},
{"referer", "http://localhost:8080/"},
{"accept-encoding", "gzip, deflate, br"},
{"accept-language", "en-US,en;q=0.9,fr;q=0.8"}
],
request_path: "/api/access_secure_data",
resp_body: nil,
resp_cookies: %{},
resp_headers: [
{"cache-control", "max-age=0, private, must-revalidate"},
{"vary", "Origin"},
{"access-control-allow-origin", "http://localhost:8080"},
{"access-control-expose-headers", ""},
{"access-control-allow-credentials", "true"}
],
scheme: :http,
script_name: [],
secret_key_base: "wEwpD63zVGtA3/JTdl5QBH6aZwE3FLD2gkAQWn6XD4Tfgk4lYlsDOoZHAREvfjoX",
state: :unset,
status: nil
}
Maybe something to add to the discussion, using Postman never helps either. i.e. In this case, it sees my cookie being set as expected on the sign_in call but the access_secure_data call is not sending back my cookie to the server even though I can see it in Postman…
1
OvermindDL1
Very very true. Plus if you encode, say, a JWT token into a web page (as is common with ‘any’ token for phoenix websockets sadly) then a page can quite literally just read another page and parse out information from it using your auth’d user (there are hazards they have to work around to do that, but there are still ways).
3
jstlroot
Oh my god I found it…
I knew it was gonna be stupid.
put_resp_cookie(conn, key, value, opts \\ [])
Options
:domain- the domain the cookie applies to:max_age- the cookie max-age, in seconds. Providing a value for this option will set both the max-age and expires cookie attributes:path- the path the cookie applies to:http_only- when false, the cookie is accessible beyond http:secure- if the cookie must be sent only over https. Defaults to true when the connection is https:extra- string to append to cookie. Use this to take advantage of non-standard cookie attributes.
I had :secure forced to true but I’m not using HTTPS in my dev environment.
I hope this discussion will help others determine how they want to implement token authentification with Phoenix and Vue.js 
Thank you all again for your time and support <3
11
acrolink
@jstlroot, glad to hear it is working now. I have already implemented your ideas (in regard to secure cookie storage for the token) using Phauxth library. I want to ask: what max_age do you use for the token/cookie expiration (should it be same value)? and do you implement some refresh token mechanism server or client side (for soon to get expired tokens)? Thank you.
0
jstlroot
Hi @acrolink
I was out for a couple of days, hence the delay, I’m sorry.
To be honest, I haven’t yet decided how the session expiration will work for my app. What I’d like is for the session to expire after a week of inactivity for the account. At least, that’s what I think my customers will find appropriate.
Many options seem possible. One would be to refresh the token and overwrite the cookie at each request, which shouldn’t be too much of a drag for the server as this process seems very light. Another option would be to be less aggressive about it and go for daily refreshes (first request of the day refreshes the token and cookie).
Another more lazy way would be to set the expiration 2 weeks after cookie/token creation and refresh them when there’s less than one week remaining. The only way this option would make sense to go for is to save server load, which I think is not really an issue, so I most likely won’t go for this one.
I’d be interested to know our thoughts on the subject!
Ah, and yes, I think the cookie and token should have the same expiration value as the behavior is pretty much the same should either of them expire before the other anyway (user needing to log back in).
Cheers! 
2
acrolink
Would be interesting to see what the optimal solution would look like If the client side is a pure JS application then it is possible to send back to the client application at authentication time (sign in) along with the cookie the value of token expiration (e.g. {"expires_at": unix_time}). A script running at fixed intervals on the client-side or on page navigation checks if there is say less than 24 hours to expiration. If so, a background call to the server is made which triggers the sever to issue a new cookie with new expiration time. Good to make distinction between original token and refreshed tokens since some actions may require providing username and password again.
2
jstlroot
Yep, makes sense.
Your idea of making distinction between original and refreshed tokens is interesting, thank you for sharing it!
Don’t hesitate to poke me as needed or to share any other idea. 
1