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

Using the backdoor creates two tokens #3

Open
tarzan opened this issue Feb 9, 2018 · 4 comments
Open

Using the backdoor creates two tokens #3

tarzan opened this issue Feb 9, 2018 · 4 comments

Comments

@tarzan
Copy link

tarzan commented Feb 9, 2018

I am using guardian in tandem with guardian_db to persist the JWT tokens in the database. Upon writing the acceptance tests using Hound, I ran into the following issue:

  1. I followed the instructions in the README and created a hound_login() function with
{:ok, token, _claims} = MyApp.Guardian.encode_and_sign(resource)

navigate_to("/?token=#{token}")
  1. I followed the instruction for guardian_db, by implementing (among others) the following hook:
  def after_encode_and_sign(resource, claims, token, _options) do
    with {:ok, _} <- Guardian.DB.after_encode_and_sign(resource, claims["typ"], claims, token) do
      {:ok, token}
    end
  end
  1. I wrote an acceptance test that monitors the token is persisted and removed from the database.
  2. I observed that tokens are persisted in the database twice upon each login.

This has to do with the example implementation that guides the user to first manually encode and sign a token, while the Backdoor Plug picks up on this token, extracts the token and then calls the sign_in of the Guardian Plug, which itself encodes and signs the token again. This seems unnecessarily complex to me, isn't it possible to shortcut this somehow?

@doomspork doomspork assigned hassox and unassigned hassox Mar 9, 2018
@doomspork
Copy link
Member

Sorry for the delays @tarzan, I've been out of the country and dealing with a family emergency. One of the @ueberauth/developers will help you soon!

@yordis
Copy link
Member

yordis commented Mar 9, 2018

@tarzan what about having a App.Test.Guardian module under your test/support files that it doesn't use Guardian.DB.

To be honest, JWT + Guardian.DB is over killing for testing, you could avoid any database interaction from Guardian if you follow this approach.

@jayjun
Copy link
Contributor

jayjun commented Jul 3, 2018

@tarzan The example assumes MyApp.Guardian.encode_and_sign/1 is free from side effects. If we extend that function to skip callbacks, we can avoid Guardian.DB issues.

MyApp.Guardian.encode_and_sign(resource, claims, skip_callback: true)

Also, my pull request #4 lets you workaround by passing claims directly instead of tokens. That should avoid double tokens too.

@tarzan
Copy link
Author

tarzan commented Jul 3, 2018

Eventually, we decided to write our own plug for sidestepping authentication in acceptance tests. I put it in a gist right here: https://gist.github.com/tarzan/9d2aad9bb0191587ae4a31e1ded0beb7

This just serialises a user to a JWT token and can be called by implementing a login helper in ExUnit case template:

      def login(%{id: user_id}) do
        navigate_to("/?user_id=#{user_id}")
      end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants