WordPress's native redirect_to login parameter not followed after login
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- authentication
Direzione di ricerca
Start with request parsing in WP_Auth0_LoginManager.php:71-73, then follow the state handling in WP_Auth0_Lock.php:34-37 and get_authorize_params() around lines 461-503. Compare the callback handling at WP_Auth0_LoginManager.php:237-238 and the v4 behavior; done means a valid WordPress redirect_to destination is preserved through Auth0 login and used after the callback, with readme.txt updated as noted.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Checklist
- I have looked into the Readme and the documentation, and have not found a suitable solution or answer.
- I have searched the issues and have not found a suitable solution or answer.
- I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- I agree to the terms within the Auth0 Code of Conduct.
Description
redirect_to is a standard WordPress convention. wp_login_form(), wp_loginout(), and core's own wp-login.php all use it to send a user back to whatever page they were trying to reach before being prompted to authenticate. v4 of this plugin supported it as a first-class, documented feature but for whatever reason, this support is missing in v5.
Reproduction
- As a logged-out user (or with an expired session), visit any deep admin URL requiring login, e.g.
wp-admin/edit.php?post_type=page. - Complete login via Auth0.
- Observe you land on the dashboard/site root instead of back on the page list you were trying to reach.
Additional context
v4 implementation for reference: request parsing in WP_Auth0_LoginManager.php:71-73, threaded through state in WP_Auth0_Lock.php:34-37 and get_authorize_params() (~461-503), honored on callback at WP_Auth0_LoginManager.php:237-238, documented in readme.txt:64.
Suggested fix: capture $_REQUEST['redirect_to'], thread through the state param sent to Auth0, validate with wp_validate_redirect() on return, use as the final destination.
wp-auth0 version
5.6.1
WordPress version
7.1
PHP version
8.4
- Lingua principale
- PHP
- Stelle
- 183
- Fork
- 104
- Merge medio
- 1g 20h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di auth0/wordpress
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Scope: Documentation
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Roadmap: Backlog
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Tutte le issue di auth0/wordpress
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Broken pathsAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Automattic/custom-metadata#167 ·
-
Daemon delete dialog: "Remove all ExApps" checkbox and `removeExApps` parameter have no effectAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno