[wp-hackers] modify or extend wp-login.php form within plugin

[Alan J Castonguay]

I'm working on an authentication extension for Wordpress to allow users 
to register and comment via an OpenID identity. I intend to, upon 
successful external authentication, create real Wordpress users via 
wp_create_user(). However, the question I pose to you applies generally 
to any authentication mechanism, not just OpenID.

I intend to place login boxes in a handful of natural places, such as 
just above the comment field, and sidebar. This is subject to the 
template author's wishes. As a catch-all scenario, I want to add OpenID 
(or other authentication service) login field(s) and button to a form 
inside wp-login.php. I see the following methods for accomplishing this 
feat:

1. Add hooks in wp-login.php in and around the existing login form for 
inserting more fields or another form. The new authentication process 
can be done in wp_authenticate and ended with wp_redirect() and exit(). 
Otherwise return and let the normal wordpress code handle both the login 
attempt and form drawing.

This option seems the cleanest. It tends to follow (my impression of) 
the Wordpress way of doing things. It would be the most resilient to 
future modifications of the core wp-login.php. It breaks backwards 
compatibility with older revisions of Wordpress which lack the new 
hooks. It requires someone to actually add and approve the new hooks. 
Suggestions include some combination of pre_login_form, login_form, 
post_login_form.

2. Hook into wp_authenticate, handling both the new and old 
authentication processes (normally done after that hook in 
wp-login.php), wp_redirect()'ing if needed. If there was no 
authentication attempt, echo() my own form (which looks just like the 
one made by wp-login normally, plus a field or two), and exit().

This option fixes the backwards-compatibility problem. It might have 
forwards-compatibility issues if the core Wordpress wp-login.php does 
something different after wp_authenticate is called, or the form is changed.

3. Hook into wp_authenticate, handling both the new and old 
authentication processes. If there was no authentication attempt, we 
need to draw the form. Load the wp-login.php file into a string, use 
regexes to grab just the form html, modify the string with additional 
fields, and echo() it, and exit()

This tries to fix the forwards-compatibility problem by using whatever 
form design and fields are present in the wp-login.php file. It still 
fails if the code after wp_authenticate in wp-login.php changes.

4. On plugin load, misappropriate the /wp-login.php request, load the 
wp-login.php file into a string, use regexen to drop new content into 
the form, and eval() it. Hook into wp_authenticate to handle only the 
new authentication and exit(), otherwise return().

This option would permit modification of the form, assuming it doesn't 
change too drastically or unexpectedly. It uses the logic of 
wp-login.php, so is immune to changes there. I hate using eval().

5. Do something completely off the wall, like subject the call 
_e('Password Lost and Found') or its ilk to returning the original text, 
plus the ending A tag, plus a whole form, textbox, submit button, ending 
of form, and the beginning of a link to something to balance the 
upcoming ending A tag in the original html. Handle new authentication in 
wp_authenticate hook.

Since the output values are escaped, I cannot, afaik, do this. It's also 
a very Bad Idea. There has to be a better way.


Which of these options (or any other ideas) would be the preferred way 
of inserting additional fields into the form generated by wp-login.php?

--
Alan J Castonguay