Skip to content
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

Plug.Conn.fetch_session(conn) with conn created by lib/phoenix/test/conn_test.ex conn/0 returns error #1008

Closed
jontonsoup opened this issue Jul 7, 2015 · 6 comments

Comments

@jontonsoup
Copy link

commented Jul 7, 2015

When I call Plug.Conn.fetch_session with a conn created by the conn_test file, I get the error:

    ** (ArgumentError) cannot fetch session without a configured session plug
        (plug) lib/plug/conn.ex:701: Plug.Conn.fetch_session/2

Not 100% sure, but it seems like a bug since fetch_cookies works perfectly fine. It seems like phoenix should configure the session plug for me?

@chrismccord

This comment has been minimized.

Copy link
Member

commented Jul 7, 2015

This is not a bug. The preferred approach is to test through your endpoint, which fetches the session for you and applies all your plug transformations. My guess is you are fetching the session because you want to put_session to "stub" a session value? You have two options in this case, one is to make a request to a path that authorizes that user, then "recycle" that conn to your next request, or 2, you can put a private assign into the conn in the test and then your application code checks for the private assign and fallback to session. We could do better with examples in our testing guides, but those are your best options.

@chrismccord chrismccord closed this Jul 7, 2015

@jontonsoup

This comment has been minimized.

Copy link
Author

commented Jul 7, 2015

thanks @chrismccord! I'll go with the recycle method.

As a side note, I'm wondering if this restriction would make feature tests prohibitively slow. Thoughtbot's https://github.com/thoughtbot/clearance runs blazing fast because it has a backdoor for user signin. It seems terribly inefficient to so a user login test before every other test that requires login.

Personally, one of the biggest draws to elixir is fast / asyc tests, so hopefully it doesn't make a perceptible difference.

@chrismccord

This comment has been minimized.

Copy link
Member

commented Jul 7, 2015

As a side note, I'm wondering if this restriction would make feature tests prohibitively slow.

In other languages yes. In Phoenix, no!!! Still blazing fast, no hacks/dependenices required :)

If you want to backdoor the user, use the private assigns like I said, but honestly tests are going to be fast when going through the endpoint.

@jontonsoup

This comment has been minimized.

Copy link
Author

commented Jul 7, 2015

@chrismccord Cool! Can you point me to an article or spot where private assigns are used?

@lessless

This comment has been minimized.

Copy link

commented Jun 29, 2016

Hello @chrismccord ,
is it still required to recycle conn between requests as of Phoenix v. 1.2?
Looks like it happens automatically within Phoenix.ConnTest.dispatch/5 https://github.com/phoenixframework/phoenix/blob/v1.2.0/lib/phoenix/test/conn_test.ex#L223

But

  conn =
    build_conn
    |> get("/")
    |> put_session(:user_id, user.id)
    |> post(...)

is throwing ** (Plug.Conn.AlreadySentError) the response was already sent

@josevalim

This comment has been minimized.

Copy link
Member

commented Jun 29, 2016

Yes, you need to recycle. If you call get right after post it will try to send the response twice.

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)

vanderhoop added a commit to stride-nyc/remote_retro that referenced this issue Feb 24, 2017

Displaying username!
  - Add session_user to root assigns
  - Conditionally display email with the appropriate button
  - to set the authenticated user on the connection in the controller tests, we visit the /auth/google/endpoint, per Chris McCord's comment: phoenixframework/phoenix#1008 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.