Auth method gets set to "userkey" when updating a user

[Cerberus-Zer0]

Hi,

I’m trying to authenticate users through our web application. So far I have been successful in authenticating a user the first time however when the user token is created and they are authenticated, Moodle changes the student’s authentication method from Manual to User key authentication.

This in turn disables the password so next time the web app tries to receive a token, it fails as the password is sent but since it’s disabled (no longer Manual) it fails to authenticate and return the token.

From the looks of it, a token is not stored and I receive Missing capabilities: auth/userkey:generatekey

However I have set Authenticated Users with the permission auth/userkey:generatekey

<?php
/**
* @param string $useremail Email address of user to create token for.
* @param string $firstname First name of user (used to update/create user).
* @param string $lastname Last name of user (used to update/create user).
* @param string $username Username of user (used to update/create user).
* @param string $ipaddress IP address of end user that login request will come from (probably $_SERVER['REMOTE_ADDR']).
* @param int $courseid Course id to send logged in users to, defaults to site home.
* @param int $modname Name of course module to send users to, defaults to none.
* @param int $activityid cmid to send logged in users to, defaults to site home.
* @return bool|string
*/
function getloginurl($useremail, $firstname, $lastname, $username, $password, $ipaddress, $courseid = null, $modname = null, $activityid = null) {

require_once('../include/curl.php');

$serverurl = "https://myonline.phoenix.wa.edu.au/login/token.php?username=" . $username . "&password=" . $password . "&service=auth_userkey";

$param = null;
$curl = new dcai\curl;

try {
    $resp = $curl->post($serverurl, $param);
    $resp = json_decode($resp, true);
} catch (Exception $ex) {
    return false;
}

$token = $resp['token'];

// define variables and parameters for authentication service call 
$domainname = 'https://myonline.phoenix.wa.edu.au';
$functionname = 'auth_userkey_request_login_url';

$serverurl = $domainname . '/webservice/rest/server.php' . '?wstoken=' . $token . '&wsfunction=' . $functionname . '&moodlewsrestformat=json' . '&user[username]=' . $username . '&user[email]=' . $useremail;

$curl = new dcai\curl;

try {
    $resp = $curl->post($serverurl, $params);
    $resp = json_decode($resp);
    $loginurl = $resp->loginurl;
} catch (Exception $ex) {
    return false;
}

if (!isset($loginurl)) {
    return false;
}

$path = '';
if (isset($courseid)) {
    $path = '&wantsurl=' . urlencode("$domainname/course/view.php?id=$courseid");
}
if (isset($modname) && isset($activityid)) {
    $path = '&wantsurl=' . urlencode("$domainname/mod/$modname/view.php?id=$activityid");
}

    return $loginurl . $path;
}

$loginUrl = getloginurl($_SESSION["loginEmail"], $_SESSION["loginFirstname"], $_SESSION["loginLastname"], $_SESSION["loginUsername"], 
crypter($_SESSION["loginPassword"], 'd'), '', null, null, null);

if ($loginUrl) {
    // redirect to portal
    echo $loginUrl; 
} else {
    echo 'There was an error connecting to the Portal.';
}
?>

It is probably my lack of knowledge on how the plugin works so if you could please help me understand the process then that would help greatly.

Thanks.

[dmitriim]

HI @leddy86,

If you have Update user option is set to Yes, then this would happen. Try to disable it.
I'll mark this issue as a bug for now.

[dmitriim]

Probably we don't want to update users if they were not created using "userkey" auth method.

[dmitriim]

I think it's actually not a bug, but a incorrect usage of the plugin in this particular case.

So you are trying to log in a user using a user name and a password to get a token, then you try to login the same user using this plugin with enabled update feature.

It seems like you should create a service user instead and get a token or generate webservice token just for generating login keys your users will be using.

So I recon it's not a bug, but we can improve the plugin by have a setting to allow users with another auth types to be logged in as well.