CODEWITHSUNDEEP
wordpress
amarinediary
amarinediary

Reputation: 5449

Is the viewing (author.php) page user the matching user?

I'm currently playing around with Wordpress user's profile pages author.php and would like to implement a personal information front-end edit ability for users AND public statistical user data fallback for any other user viewing the page.

I'm looking for a secure way to determine if the user currently viewing the author.php user page, is the matching user.

Right now I'm comparing get_current_user_id() with get_queried_object()->ID.

If the ID's match, I'm revealing a specific sensible personal (credentials, emails ...) content. If not, I'm just showing some basic statistical data.

The following is just a minimal working representation from an author.php page.

<?php 
if ( get_current_user_id() === get_queried_object()->ID )
    echo "You're the one!";
else
    echo "Lies!";
?>

Should I be checking for anything else beside the ID, before showing any personal information ?

Edit

Following @Xhynk answer, here is what I'm currently using:

<?php if ( get_queried_object() instanceof \WP_User && get_current_user_id() === get_queried_object()->ID ) {
    //...
} else {
    //...
}; ?>

Upvotes: 0

Views: 199

Answers (1)

Xhynk
Xhynk

Reputation: 13880

get_current_user_id() will already accurately, and securely, get the logged in user's ID - there isn't really a way to override it without having server level access (aka, you can override it in a plugin/theme, but can't from the client).

One thing to consider though is that you may want to check that the get_queried_object() is actually a WP_User, because the queried object can be a Term, Post Type, Post, or User, and those ID's are not exclusive.

For instance, there can be a post with ID 1, a user with ID 1, and a term with ID 1, all 3 of which aren't really correlated.

If you're putting this in author.php, it's not a huge concern as the Template Hierarchy will essentially handle that for you, but if you ever made this function more abstract to expand it and moved it to functions.php or somethiung, you'd want to consider doing it, or do it now for an added level of "not forgetting to later".

One last bit is that you'll want to validate the data that's submitted from the front end regardless of the above, and make sure that the current indeed does have access to edit the information that's being sent and updated.

In short:

  • You should be okay showing the front-end editing as you are now (but I'd consider adding a redundant check for the queried object's type)
  • You should be validating the data sent to make sure the current user has appropriate permissions anyway, whether or not they can see the front-end editing

Documentation & Function Reference

Function Linked Description
get_queried_object() Retrieves the currently queried object.
get_current_user_id() Get the current user’s ID

Upvotes: 1

Related Questions