That solution is correct if you’re wanting to get metadata returned from the authentication responses, as it otherwise isn’t. Rules allow you to tailor the responses to meet your application’s needs for situations like this. Returning the metadata using a rule rather than making management API calls will save you extra network requests and API calls that will impact your rate limit quota.
When using the Management API, you should use an access token suitable for Management API calls. You can retrieve a user’s detail through the Management API using the Auth0\SDK\API\Management\Users class’ get() method.
Assuming you are using SDK 7.x:
// 🧩 Your \Auth0\SDK\Auth0 configuration code here ...
try {
$user = $auth0->getUser();
} catch (\Exception $e) {
$user = null;
}
if ($user) {
// This is the type of ID you were asking about, I believe? This is what you'd issue Management API user endpoint requests with.
$userId = $user['sub'];
// Instantiate the Management API class.
$managementApi = new \Auth0\SDK\API\Management(AUTH0_MANAGEMENT_TOKEN, AUTH0_DOMAIN);
// Fetch the user from the /users endpoint by the authenticated user's ID.
$userResponse = $managementApi->users()->get($userId);
if ($userResponse) {
// Echo the Management API response, as it is:
var_dump($userResponse);
// Add or update a 'testing' property to the metadata with a random, unique ID.
$userMetadata = $userResponse['user_metadata'] ?? [];
$userMetadata['testing'] = uniqid();
// Send a PATCH request to update the user.
// Updatable properties can be referenced here https://auth0.com/docs/api/management/v2#!/Users/patch_users_by_id
$managementApi->users()->update($userId, (object) ['user_metadata' => $userMetadata]);
} else {
die("User not found.");
}
}
Or, with the new SDK 8.x that’s entering beta this week, the API is slightly updated:
// 🧩 Your \Auth0\SDK\Auth0 configuration code here ...
use Auth0\SDK\Utility\HttpResponse;
$session = $auth0->getCredentials();
if ($session !== null) {
// This is the type of ID you were asking about, I believe? This is what you'd issue Management API user endpoint requests with.
$userId = $session->user['sub'];
// Fetch the user from the /users endpoint by the authenticated user's ID.
$apiResponse = $auth0->management()->users()->get($userId);
// Will return false if the user was not found, or the network request failed.
if (! HttpResponse::wasSuccessful($apiResponse)) {
die("User not found.");
}
// Converts the PSR-7 HTTP Response from the network request into a PHP array representing the user.
$userResponse = HttpResponse::decodeContent($apiResponse);
// Echo the Management API response, as it is:
var_dump($userResponse);
// Add or update a 'testing' property to the metadata with a random, unique ID.
$userMetadata = $userResponse['user_metadata'] ?? [];
$userMetadata['testing'] = uniqid();
// Send a PATCH request to update the user.
// Updatable properties can be referenced here https://auth0.com/docs/api/management/v2#!/Users/patch_users_by_id
$auth0->management()->users()->update($userId, ['user_metadata' => $userMetadata]);
}
(Writing this from my phone as I’m out at lunch at the moment, so apologies for any obvious code errors, but that is a general idea.)
Hope this answers your questions, and let us know if we can help further.
FWIW, Auth0 tries to be very platform-independent, and so some examples may need a bit of help. when i was first using Auth0-PHP i struggled a great deal because a PHP example was incorrect/incomplete.
Hopefully that is fixed now, but i have not checked recently. here was my issue:
i also had to HIRE a consultant to solve a couple of very basic PHP issues:
i keep hoping the Auth0 will create user-driven cookbook-solution sections. these PHP issues are very common.
Konrad Sopala and Dan Woda both do excellent job supporting us, but of course they are spread too thin, as are most of the Auth0 staff. that is why i think a user driven cookbook might be the best approach.
Hey @edwardsmarkf Very sorry to hear about the issues you had; I only came only recently and wish I’d been able to help.
One of my goals with the new QuickStart for 8.0 was to introduce a cookbook-like, modular solution to the base QuickStart example developers can opt into to see how expanding on the basic configuration and login example works. I’ll iterate on this as time goes on. Hopefully this will help avoid others in the future hitting similar issues!
believe me when i say i am NOT complaining, i am just totally thrilled to have such a fantastic login replacement. maintaining user login has been an ongoing headache for me. so much so that i just started setting user passwords equal to their email addresses!
complaining about the Auth0-PHP interface would be like complaining that Christie Brinkley has a tiny freckle on her toe.
