Opened 17 years ago
Closed 17 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 |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Users | Version: | 2.8 |
| Severity: | minor | Keywords: | has-patch early |
| Cc: | Focuses: |
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
@
17 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
@
17 years ago
Sounds reasonable. It *could* be an issue when the username is an email, though. ;-)
#7
@
17 years ago
- Resolution → wontfix
- Status new → closed
Since you took care of the email case in your other patch, I'd like to say wontfix on this one.
#9
@
17 years ago
- Component Security → Users
- Keywords early added
- Milestone → 2.9
- Resolution wontfix
- Status closed → 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.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
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.