Currently, Goat Guardian takes a command line flag --redir-after-login-url. This determines where Goat Guardian will redirect the end-user after they login.
However, a better design would be for Goat Guardian's /twitter/login and /email/login endpoints to take a parameter called next or redirect-url to determine where to redirect the end-user after logging in.
For example, if the upstream web application sent the end user to /twitter/login?next=/my-cool-page, then after the end-user finishes logging in with Twitter, Goat Guardian will redirect them to /my-cool-page.
This should provide more flexibility for the upstream web application than using the --redirect-after-login-url flag.
Currently, Goat Guardian takes a command line flag
--redir-after-login-url
. This determines where Goat Guardian will redirect the end-user after they login.However, a better design would be for Goat Guardian's
/twitter/login
and/email/login
endpoints to take a parameter callednext
orredirect-url
to determine where to redirect the end-user after logging in.For example, if the upstream web application sent the end user to
/twitter/login?next=/my-cool-page
, then after the end-user finishes logging in with Twitter, Goat Guardian will redirect them to/my-cool-page
.This should provide more flexibility for the upstream web application than using the
--redirect-after-login-url
flag.