Opened 16 years ago
Closed 15 years ago
#9577 closed enhancement (wontfix)
use user_id rather than user_login in the authentication cookie
Reported by: | Denis-de-Bernardy | Owned by: | ryan |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | 2.8 |
Component: | Users | Keywords: | has-patch early |
Focuses: | Cc: |
Description
suggested enhancement:
- prevent username from matching /d+/
- use user_id, instead of user_login, in the authentication cookie
Attachments (1)
Change History (12)
#3
@
16 years ago
I think we went with username instead of ID in the cookie because we expose usernames in so many other places that isn't really very private.
#4
@
16 years ago
Sounds reasonable. It *could* be an issue when the username is an email, though. ;-)
#7
@
16 years ago
- Resolution set to wontfix
- Status changed from new to closed
Since you took care of the email case in your other patch, I'd like to say wontfix on this one.
#9
@
16 years ago
- Component changed from Security to Users
- Keywords early added
- Milestone set to 2.9
- Resolution wontfix deleted
- Status changed from closed to reopened
actually, the user_nicename and the cookie are separate issues.
the cookie currently contains the user_login, rather than the user_nicename. I could change the patch to use the user_nicename if you think it's preferrable.
Note: See
TracTickets for help on using
tickets.
this one might be worth a discussion in wp-hackers. it is meant to prevent the username to be passed in the cookie.
it *might* break a plugin or two that relies on the auth_cookie_bad_username hook. we could alternatively keep that hook's name unchanged, but the semantics would wrong. or we could fire both auth_cookie_bad_username *and* auth_cookie_bad_user_id, passing the user_id each time -- to ensure 100% backwards compat.