How to writing a plugin to change login detail

geoflashed · July 25, 2017, 7:55am

Hello,

I would like to write a plugin to change login from “username/password” to “email/password” as the following image explained,

I am wondering how to start, like which category do I need to go with?

[OJS version is 3.0.2]

Thanks,
Jason

ctgraham · July 25, 2017, 12:38pm

If you just want to replace instances of the word “username” with “email” sitewide, this may be (almost) as simple as changing the locale translations rather than writing a plugin. See the file:

github.com

pkp/pkp-lib/blob/ojs-stable-3_0_2/locale/en_US/user.xml#L148


	<message key="user.role.layoutEditors">Layout Editors</message>
	<message key="user.roles">Roles</message>
	<message key="user.salutation">Salutation</message>
	<message key="user.sendPassword">Confirmation</message>
	<message key="user.sendPassword.description">Send me a confirmation email including my username and password</message>
	<message key="user.signature">Signature</message>
	<message key="user.suffix">Suffix</message>
	<message key="user.title">Title</message>
	<message key="user.url">URL</message>
	<message key="user.userHome">User Home</message>
	<message key="user.username">Username</message>
	<message key="user.workingLanguages">Working Languages</message>
	<message key="user.orcid">ORCID iD</message>
	<message key="user.orcid.orcidInvalid">The ORCID iD you specified is invalid. Please include the full URI (e.g. "http://orcid.org/0000-0002-1825-0097").</message>
	<message key="user.profile.identity">Identity</message>
	<message key="user.profile.contact">Contact</message>
	<message key="user.profile.public">Public</message>
</locale>

Note that the term “username” is included in multiple other locale keys, such as:

github.com

pkp/pkp-lib/blob/ojs-stable-3_0_2/locale/en_US/user.xml#L114


	<message key="user.profile">Profile</message>
	<message key="user.profile.publicProfile">User Profile</message>
	<message key="user.profile.repeatNewPassword">Repeat new password</message>
	<!-- Login -->
	<message key="user.login.registerNewAccount">Register</message>
	<message key="user.login.resetPasswordInstructions">Enter your account email address below and an email will be sent with instructions on how to reset your password.</message>

	<message key="user.register.form.emailExists">The selected email address is already in use by another user.</message>
	<message key="user.register.form.passwordsDoNotMatch">The passwords do not match.</message>
	<message key="user.register.form.emailsDoNotMatch">The email address fields do not match.</message>
	<message key="user.register.form.usernameAlphaNumeric">The username can contain only lower-case alphanumeric characters, underscores, and hyphens, and must begin and end with an alphanumeric character.</message>
	<message key="user.register.form.userGroupRequired">At least one role must be selected.</message>
	<message key="user.register.form.usernameExists">The selected username is already in use by another user.</message>
	<message key="user.register.form.passwordLengthRestriction">The password must be at least {$length} characters.</message>
	<message key="user.register.registerAs">Register in {$contextName} as...</message>
	<message key="user.register">Register</message>
	<message key="user.register.usernameRestriction">The username must contain only lowercase letters, numbers, and hyphens/underscores.</message>
	<message key="user.register.registrationCompleted"><![CDATA[You have successfully registered. <a href="{$profileUrl}">Click here</a> to complete your user profile.]]></message>
	<message key="user.role.author">Author</message>
	<message key="user.role.author_s">Author(s)</message>
	<message key="user.role.authors">Authors</message>

This also points to the other “gotcha”. There is an unnecessary restriction of the username to alphanumeric characters. This can be removed, if you have some basic knowledge of PHP.
https://github.com/pkp/pkp-lib/issues/906

I wonder if @crism may have already relaxed this unneeded constraint as part of recent work here:
https://github.com/pkp/pkp-lib/issues/1963

crism · July 25, 2017, 5:22pm

Oh, good catch, @ctgraham! I hadn’t relaxed that… the Shibboleth plugin sets the username as the e-mail directly in the DAO, so the front-end restrictions are circumvented. But if one disables the plugin, one may not be able to log in or recover the password, due to that restriction… I’ll check.

crism · July 25, 2017, 7:04pm

There doesn’t seem to be syntactic validation of the username at login, and password recovery is asking for e-mail anyway, not username. So from a Shibboleth perspective, I think this is good—e-mail–like usernames are only ever created by Shibboleth, and can’t be created via direct registration. Otherwise, a sort of weak DoS attack could be done by registering accounts that look like others’ e-mail addresses; Shibboleth-based registration would then fail, as it would try to create new accounts with usernames identical to previously-existing accounts.

geoflashed · July 31, 2017, 8:15am

report back:

I just changed line 31 on \lib\pkp\classes\security\Validation.inc.php
from
$user = $userDao->getByUsername($username, true);
to
$user = $userDao->getUserByEmail($username, true);
and now it can be logged in by email & password, but don’t know if there would be any side effects.

Anyway, I would still like to get it done by writing a plugin.

lenare · January 27, 2023, 7:44am

Sorry for reviving this old topic…
I still have issues upon registration with Shibboleth, because some e-mail addresses exceed the character limit of the username column in the ojs database. The obvious fix for me would be to change that limit. Where can I set this in the code, so that the database is created with the correct limits already upon installation?
Willing to help out here if my time allows as I’m currently working a lot with the Shibboleth plugin

Related to my post here: Fatal Error on Shibboleth Registration
And Github issue: Registration fails when email is assigned as username · Issue #21 · pkp/shibboleth · GitHub

asmecher · January 27, 2023, 5:19pm

Hi @lenare,

You can extend the size of the email address field here:

github.com

pkp/pkp-lib/blob/stable-3_3_0/classes/migration/CommonMigration.inc.php#L73


      
          			$table->string('plugin', 32);
          			$table->smallInteger('auth_default')->default(0);
          			$table->text('settings')->nullable();
          		});
          
          
		// User authentication credentials and profile data.
          		Capsule::schema()->create('users', function (Blueprint $table) {
          			$table->bigInteger('user_id')->autoIncrement();
          			$table->string('username', 32);
          			$table->string('password', 255);
          			$table->string('email', 255);
          			$table->string('url', 2047)->nullable();
          			$table->string('phone', 32)->nullable();
          			$table->string('mailing_address', 255)->nullable();
          			$table->string('billing_address', 255)->nullable();
          			$table->string('country', 90)->nullable();
          			$table->string('locales', 255)->nullable();
          			$table->text('gossip')->nullable();
          			$table->datetime('date_last_email')->nullable();
          			$table->datetime('date_registered');
          			$table->datetime('date_validated')->nullable();

You’ll probably want to make a similar change to the authors table here:

github.com

pkp/pkp-lib/blob/stable-3_3_0/classes/migration/SubmissionsMigration.inc.php#L74


      
          		});
          		// Add partial index (DBMS-specific)
          		switch (Capsule::connection()->getDriverName()) {
          			case 'mysql': Capsule::connection()->unprepared('CREATE INDEX publication_settings_name_value ON publication_settings (setting_name(50), setting_value(150))'); break;
          			case 'pgsql': Capsule::connection()->unprepared("CREATE INDEX publication_settings_name_value ON publication_settings (setting_name, setting_value) WHERE setting_name IN ('indexingState', 'medra::registeredDoi', 'datacite::registeredDoi', 'pub-id::publisher-id')"); break;
          		}
          
          
		// Authors for submissions.
          		Capsule::schema()->create('authors', function (Blueprint $table) {
          			$table->bigInteger('author_id')->autoIncrement();
          			$table->string('email', 90);
          			$table->smallInteger('include_in_browse')->default(1);
          			$table->bigInteger('publication_id');
          			$table->float('seq', 8, 2)->default(0);
          			$table->bigInteger('user_group_id')->nullable();
          			$table->index(['publication_id'], 'authors_publication_id');
          		});
          
          
		// Language dependent author metadata.
          		Capsule::schema()->create('author_settings', function (Blueprint $table) {
          			$table->bigInteger('author_id');

However, are you really working with email addresses longer than 255 characters? Or do you potentially have a character set misconfiguration that’s causing UTF-8 characters to take up more of those than intended?

Regards,
Alec Smecher
Public Knowledge Project Team

lenare · January 30, 2023, 7:28am

Thanks, @asmecher ! That’s what I was looking for!
I’m not working with email addresses longer than 255 characters, maybe that was a bit unclear.
My problem is that the Shibboleth plugin sets the email address as a username, and the username is currently limited to 32 chars only.
Do you see any severe problems with allowing longer usernames?

github.com

pkp/shibboleth/blob/5306b9eaf76d5f46795e25151305690419c9049b/pages/ShibbolethHandler.inc.php#L555


      
          		}
          
          
		// optional values
          		$userInitials = isset($_SERVER[$initialsHeader]) ? $_SERVER[$initialsHeader] : null;
          		$userPhone = isset($_SERVER[$phoneHeader]) ? $_SERVER[$phoneHeader] : null;
          		$userMailing = isset($_SERVER[$mailingHeader]) ? $_SERVER[$mailingHeader] : null;
          
          
		$userDao = DAORegistry::getDAO('UserDAO');
          		$user = $userDao->newDataObject();
          		$user->setAuthStr($uin);
          		$user->setUsername($userEmail);
          		$user->setEmail($userEmail);
          
          
		// Get the site primary locale, needed for setting the given name
          		// and family name of the user.
          		$request = Application::getRequest();
          		$site = $request->getSite();
          		$sitePrimaryLocale = $site->getPrimaryLocale();
          
          
		$user->setGivenName($userFirstName, $sitePrimaryLocale);
          		$user->setFamilyName($userLastName, $sitePrimaryLocale);

asmecher · January 30, 2023, 4:12pm

Hi @lenare,

No, I don’t think extending the length of the username field would cause problems with OJS 3.3.0-x and newer. With 3.2.1-x and older versions you would need to also update the XML database schema descriptors; with 3.3.0-x and newer that is no longer necessary (and the XML descriptors are only distributed with the OJS package for the sake of older upgrades).

Regards,
Alec Smecher
Public Knowledge Project Team

asmecher · February 6, 2023, 4:00pm

This topic was automatically closed after 5 days. New replies are no longer allowed.