phx.gen.auth should provide a way to generate /.well-known/change-password URL #6853

Activity

1. SteffenDE commented on Sep 25, 2026

   

   SteffenDE

   on Sep 25, 2026

   Member

   More actions

   I think we can generate one on the first run and log an error if we find a duplicate route
2. rhcarvalho commented on Oct 14, 2026

   

   rhcarvalho

   on Oct 14, 2026

   Last edited by rhcarvalho

   Collaborator

   More actions

   (sorry for the accidental early submission)

   phx.gen.auth should provide a way to generate /.well-known/change-password URL

   This could be done in user-land with something like:

   # lib/my_app_web/controllers/redirect_controller.ex
   defmodule MyAppWeb.RedirectController do
     use MyAppWeb, :controller
   
     def init(opts), do: opts
   
     def call(conn, to: to) do
       redirect(conn, to: to)
     end
   end
   
   # lib/my_app_web/router.ex
     scope "/", MyAppWeb do
       pipe_through :browser
   
       get "/", PageController, :home
   
       get "/.well-known/change-password", RedirectController, to: "/users/settings"
     end

   @hauleth what did you imagine that Phoenix would do natively or that would be generated as part of mix phx.gen.auth?
3. hauleth commented on Oct 14, 2026

   

   hauleth

   on Oct 14, 2026

   ContributorAuthor

   More actions

   I know it can be done in the userland. That is not the point. The point is that mix phx.gen.auth should do that by default to promote good behaviours from the users.
4. rhcarvalho commented on Oct 14, 2026

   

   rhcarvalho

   on Oct 14, 2026

   Collaborator

   More actions

   The point is that mix phx.gen.auth should do that by default to promote good behaviours from the users.

   Got it!

   AFAICT serving /.well-known/ out of the box has no precedent. Do you know of any other web framework that does that?

   In my experience, most mainstream web frameworks do not expose these URLs. Because /.well-known/ paths are domain-wide, the correct layer to configure them will depend on the deployment environment. E.g. if the app is served on a subpath of a domain, has a separate user-facing identity strategy (while concurrently using phx.gen.auth for an internal part of the app -- I've done that myself before), etc.

   I feel expecting users to understand and edit/remove an incorrectly-configured /.well-known/change-password is a higher ask than educating users to add that when relevant? Though again the Phoenix docs don't often talk about industry-wide practices, keeping the scope to Phoenix-specific concerns.

   Potential places if we go the documentation way:

   • https://phoenix.hexdocs.pm/mix_phx_gen_auth.html#security-considerations
   • https://phoenix.hexdocs.pm/security.html
   • https://phoenix.hexdocs.pm/deployment.html