View Issue Details

IDProjectCategoryView StatusLast Update
0004568New issuesGeneralpublic2015-08-01 04:06
ReporterrobholAssigned Toqaisjp 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionwon't fix 
Summary0004568: [Request] Remove hardcoded login and logout commands
Description

This is something that should be left up to server owners to control.
Log in and out commands, as well as the registration command should be moved from the source and the admin resource respectively, into a separate resource, for neatness' sake.

TagsNo tags attached.

Relationships

has duplicate 0004304 closed New issues Remove standard login messages 
has duplicate 0005773 closed New issues Deactivate Server Commands by script from running ingame 
related to 0004651 closed Source patches Patch for #4568 (disable hardcoded login-/logout) 
related to 0008971 resolvedqaisjp Multi Theft Auto : San Andreas Let setAccountPassword take hashed forms 
child of 0003344 closed New Feature Requests Requested features tracker 

Activities

Talidan

2009-06-29 22:05

administrator   ~~0009823

Last edited: 2009-06-29 22:06

login and logout commands are not part of admin. They are hardcoded. Admin only has registration. Do bear in mind you can cancel the onPlayerLogin/out events if you want to control this yourself.

robhol

2009-06-29 22:11

reporter   ~~0009824

Last edited: 2009-06-29 22:12

Jesus... I do wish people wouldn't call me a "nab" and THEN give me wrongful information.

ryden

2009-06-29 23:37

manager   ~~0009828

Those commands should be a required and auto-started resource. I strongly vote to get rid of them.

Dragon

2009-07-01 12:23

reporter   ~~0009839

but then it should be added to the server.conf as an auto-start resource, many people appreciate this function

Talidan

2009-07-01 14:15

administrator   ~~0009841

Of course, that goes without saying, Dragon

Paul_Cortez

2009-12-15 17:32

reporter   ~~0010882

Last edited: 2009-12-15 17:36

I have removed the hardcoded login/logout in my fork. (Gamesnert/multitheftauto)

http://github.com/Gamesnert/multitheftauto/commit/e1bb009bfa88c057051c642afaf78d8a69d3290b

AND

http://github.com/Gamesnert/multitheftauto/commit/8ae394ece376f3f79c06f84a4c674f9eeedb2106

Note that the resource from the first link is outdated. The new resource has a README.txt with the ACL lines necessary, and also I forgot to add the auto-login message. The up-to-date version can be found here:

http://dump.no/files/90988dd0eb58/accountmanager.zip

Talidan

2010-02-02 00:33

administrator   ~~0011011

I'm going to take a bold move and close this. This is possible by restricting it's use in ACL, which in my opinion is relatively clean:

    <right name="command.login" access="false" />
    <right name="command.logout" access="false" />

I'll look into adding default ACL parameters setting these to true so that they're less obscure.

If anyone disagrees, reopen and state your point.

robhol

2010-03-24 08:23

reporter   ~~0011252

I do disagree, and my point is as follows: in the event that server owners want to replace or augment the account systems with their own scripts or systems, the login and -out commands hard-coded into MTA will potentially cause problems either by being left out of the ACL, or by making effectively sure nobody can use these commands for their own scripts because they already blocked them, something the ACL offers no way out of.

I realize this might not look all that important, but then again it looks like a simple five minute job of removing/disabling something from the source - the resource that could easily replace the commands' behavior could be written in three and even more people could do it, including me.

And.. uh, I'm noticing Gamesnert has already posted a patch for the issue.

drifterCZ

2012-02-23 09:46

viewer   ~~0016146

I absolutely agree with robhol. When you don't want to use default login, you can only block the commands.

We run 5 servers with one shared MySQL DB containing accounts, so we must use stupid /log command, because we can't get anything from /login.

Ca11um

2012-05-06 02:55

reporter   ~~0016605

C++ patch to disable hardcored account system ('login' and 'logout'): http://dl.dropbox.com/u/47984043/MTA/Patches/HardcoreAccounts.patch

Lua resource to replicate the 'login' and 'logout' commands: http://dl.dropbox.com/u/47984043/MTA/Patches/Accounts.patch

If the resource is to be used, it will need adding to mtaserver.conf so it starts with the MTA Server.

x86

2012-05-08 19:23

administrator   ~~0016608

I don't know, his lua script is also wrong.. Now you have to login by using: /login [name] [pass] instead of the shortcut /login [pass]

Ca11um

2012-05-08 19:55

reporter   ~~0016609

x86: Added the optional syntax of 'login [password]'. Same link as before.

Dutchman101

2014-04-27 18:57

updater   ~~0020784

bump

qaisjp

2014-04-27 19:00

administrator   ~~0020785

If the issue against this is because of security: there are protections against server owners from seeing what's typed in the chat because it may be a /login - what's stopping the server from looking at the password through a GUI based login panel?

MIKI785

2014-04-28 02:04

viewer   ~~0020802

In my opinion, these commands should be removed all together. If they are there because of "security", you can still get the passwords by using various events like onClientConsole or onClientCharacter if you want... it should be then maybe part of admin resource where the login command would be using the logIn function like a regular command. Same with logout.
There are also other commands like chgmypass that are not really necessary as they can also be scripted.

qaisjp

2014-11-16 16:07

administrator   ~~0022448

I think the hardcoded command be removed and reimplemented in admin/admin2.
Or login/register can be moved directly into a new resource called "accounts" or "authentication"/"auth" or something

qaisjp

2015-06-02 13:41

administrator   ~~0023346

I'll start work on this "soon", please say something if you don't think this should be merged.

XeoN-

2015-06-07 03:58

viewer   ~~0023356

I agree , this is a great idea.

qaisjp

2015-08-01 03:57

administrator   ~~0023774

This feature is likely to not be implemented. Here is a summary of what was discussed in IRC: (for = implement this, against = don't implement)

  • Using /login is the safest way to log into an account (for)
  • /register can be compromised to do something malicious anyway (neutral)
  • Modified servers can edit /login to do something malicious anyway (for)
  • If server was compromised, only way to get password is via register and not every time someone logs in (against, but rendered moot if GUI login panel)
  • To facilitate forum account stuff, hashed passwords will/can be directly set using setAccountPassword combined with the necessary web features (callRemote/web sdk).

Based on this: the barrier to entry is higher without the feature, and features can be implemented using the inbuilt accounts system.

Issue History

Date Modified Username Field Change