pow-auth / pow

Robust, modular, and extendable user authentication system
https://powauth.com
MIT License
1.58k stars 152 forks source link

Upgrading POW from 1.6 to 1.7 #704

Closed arnimikelsons closed 10 months ago

arnimikelsons commented 11 months ago

Trying to upgrade an app, with POW as authentication from 1.6 to 1.7, and getting non-authentication pages to show. But getting the following error on session/new. Are there any instructions on how to move a 1.6 app to 1.7 format?

ArgumentError at GET /session/new

no "new" html template defined for AafWeb.Pow.SessionHTML (the module does not exist)

ArgumentError at GET /session/new

Exception:

** (ArgumentError) no "new" html template defined for AafWeb.Pow.SessionHTML  (the module does not exist)
    (phoenix_template 1.0.3) lib/phoenix/template.ex:248: Phoenix.Template.render_with_fallback/4
    (phoenix_template 1.0.3) lib/phoenix/template.ex:197: Phoenix.Template.render_within_layout/4
    (phoenix 1.7.7) lib/phoenix/controller.ex:1000: anonymous fn/5 in Phoenix.Controller.template_render/4
    (telemetry 1.2.1) /Users/arnimikelsons/projects/aaf/deps/telemetry/src/telemetry.erl:321: :telemetry.span/3
    (phoenix 1.7.7) lib/phoenix/controller.ex:987: Phoenix.Controller.render_with_layouts/4
    (phoenix 1.7.7) lib/phoenix/controller.ex:974: Phoenix.Controller.render_and_send/4
    (pow 1.0.31) lib/pow/phoenix/controllers/session_controller.ex:1: Pow.Phoenix.SessionController.action/2
    (pow 1.0.31) lib/pow/phoenix/controllers/session_controller.ex:1: Pow.Phoenix.SessionController.phoenix_controller_pipeline/2
    (phoenix 1.7.7) lib/phoenix/router.ex:430: Phoenix.Router.__call__/5
    (aaf 0.1.0) lib/aaf_web/endpoint.ex:1: AafWeb.Endpoint.plug_builder_call/2
    (aaf 0.1.0) lib/aaf_web/endpoint.ex:3: anonymous fn/3 in AafWeb.Endpoint."call (overridable 3)"/2
    (appsignal 2.2.16) lib/appsignal/instrumentation.ex:12: Appsignal.Instrumentation.instrument/1
    (aaf 0.1.0) deps/plug/lib/plug/debugger.ex:136: AafWeb.Endpoint."call (overridable 4)"/2
    (aaf 0.1.0) lib/aaf_web/endpoint.ex:1: AafWeb.Endpoint."call (overridable 5)"/2
    (aaf 0.1.0) deps/plug/lib/plug/error_handler.ex:80: AafWeb.Endpoint.call/2
    (phoenix 1.7.7) lib/phoenix/endpoint/sync_code_reload_plug.ex:22: Phoenix.Endpoint.SyncCodeReloadPlug.do_call/4
    (plug_cowboy 2.6.1) lib/plug/cowboy/handler.ex:11: Plug.Cowboy.Handler.init/2
    (cowboy 2.10.0) /Users/arnimikelsons/projects/aaf/deps/cowboy/src/cowboy_handler.erl:37: :cowboy_handler.execute/2
    (cowboy 2.10.0) /Users/arnimikelsons/projects/aaf/deps/cowboy/src/cowboy_stream_h.erl:306: :cowboy_stream_h.execute/3
    (cowboy 2.10.0) /Users/arnimikelsons/projects/aaf/deps/cowboy/src/cowboy_stream_h.erl:295: :cowboy_stream_h.request_process/3
danschultzer commented 11 months ago

I believe this error happens when you are changing the controller to use :formats option. This is will change how Phoenix build the module name, so now it'll expect AafWeb.Pow.SessionHTML rather than AafWeb.Pow.SessionView.

You'll need to update the view module name to the new format, or remove the : formats option if you wish to keep the view module naming.

Easiest approach would likely be to just run mix pow.phoenix.gen.templates again, generating the new structure, and then move over the templates into the newly generated files.

Let me know if this solves the issue! I should probably add a 1.7 migration note regarding this.

arnimikelsons commented 11 months ago

created a new instace with Erlang 25.3.2.4, Elixir 1.14.5-otp-25, phoenix 1.7.7

add {:pow, "~> 1.0.31"} to mix.exs

run mix pow.phoenix.gen.templates

In upgraded existing instance:

mix pow.phoenix.gen.templates

update fields with additional fields that were created

deleted registration_view.ex and session_view.ex under app_web/views/pow

deleted app_web/templates/pow directory

ran mix phx.server and getting

% mix phx.server
Compiling 2 files (.ex)

== Compilation error in file lib/aaf_web/controllers/pow/registration_html.ex == ** (UndefinedFunctionError) function AafWeb.html/0 is undefined or private AafWeb.html() expanding macro: AafWeb.using/1 lib/aaf_web/controllers/pow/registration_html.ex:2: AafWeb.Pow.RegistrationHTML (module) (elixir 1.14.5) expanding macro: Kernel.use/2 lib/aaf_web/controllers/pow/registration_html.ex:2: AafWeb.Pow.RegistrationHTML (module) arnimikelsons@MacBook-Pro-2 aaf %

danschultzer commented 11 months ago

Oh I see. Phoenix.View has been removed as. default in Phoenix 1.7 so you'll need to update your web module plus all views to the new Phoenix 1.7 setup. This means that you need something like this in AafWeb (phoenix diff can show all the changes):

  def html do
    quote do
      use Phoenix.Component

      # Import convenience functions from controllers
      import Phoenix.Controller,
        only: [get_csrf_token: 0, view_module: 1, view_template: 1]

      # Include general helpers for rendering HTML
      unquote(html_helpers())
    end
  end

  defp html_helpers do
    quote do
      # HTML escaping functionality
      import Phoenix.HTML
      # Core UI components and translation
      import AafWeb.CoreComponents
      import AafWeb.Gettext

      # Shortcut for generating JS commands
      alias Phoenix.LiveView.JS

      # Routes generation with the ~p sigil
      unquote(verified_routes())
    end
  end

You can see in the above there's an expectation for AafWeb.CoreComponents to exist.

Backwards compability with Phoenix.View is still possible if you are not planning to move over the template components. You'll need to have phoenix_view as a dependency for this to work. You won't need to change anything, but you must not set :formats option for the controller in your web module.

If you do want to set that option and still keep the view module then I think you can get away with just renaming them (so it would be AafWeb.Pow.SessionHTML instead of AafWeb.Pow.SessionView).

Sorry for the back and fourth here. The Phoenix 1.7 upgrade does kinda work, but all these changes are significant so it means if you enable an option in Phoenix it'll have very different expectations of your project structure. I would have thought you would experience issues with your other view templates as well unless you have updated them to the new structure?

jaimeiniesta commented 10 months ago

Hi, I'm also upgrading to Phoenix 1.7 and found the same no "new" html template defined for AppWeb.Pow.SessionHTML (the module does not exist) error.

Adding the code that @danschultzer did not fix the issue.

Are there plans to support Phoenix 1.7 and Elixir 1.15?

danschultzer commented 10 months ago

I found the issue. There's was an incorrect assumption when Phoenix.View is available. I've fixed it in #709, which will be merged and new release out later today. Thanks for the reports!

danschultzer commented 10 months ago

Pow v1.0.32 is out, let me know if it's all working now!

jaimeiniesta commented 10 months ago

Thanks @danschultzer - using 1.0.32 fixed the issue for me.

ravensiris commented 10 months ago

@danschultzer Unfortunately it broke my app.

Request: GET /admin/session/new
** (exit) an exception was raised:
    ** (ArgumentError) no "new" html template defined for MyAppWeb.Pow.SessionView  (the module does not exist)

I was using MyAppWeb.Pow.SessionHTML before and it was working. Doesn't seem like I can pass an option to pow or anything like that to fix this.

I think

Code.ensure_loaded?(Phoenix.View)

is not good enough. Looking at my dependency graph there are some dependants. And there's also a case for projects migrating from Views to HTML where they might want to keep part of their code with views. There's no Phoenix.View referenced by itself in my app(checked with grep).

danschultzer commented 10 months ago

@ravensiris ugh, thanks for the report, I'll revert this change and find a better solution.

danschultzer commented 10 months ago

@ravensiris this should be fixed with #712. I'll get this out later today when I have some free time, but if you want to help please test this and let me know if it works for you:

{:pow, github: "pow-auth/pow", ref: "fix-phoenix-view-namespace"}

My preliminay testing did confirm this works with both your scenario, and resolves OP issue.

danschultzer commented 10 months ago

This should be fixed in v1.0.33, I couldn't reproduce any issue in any of the scenarios I've tested with in local.

ravensiris commented 10 months ago

@danschultzer Thanks! It's working with v1.0.33