DirectAdmin v1.661

@Stije, CMD_LOGIN is not removed, but this command can no longer be used for user impersonation feature (also known as login-as feature). It is present in the change log. It also includes backwards compatibility layer, if you would try using CMD_LOGIN to perform impersonation request you would get a message explaining it should not be used and the button to actually perform this action using new API. The command CMD_LOGIN can still be used for normal user log-in.

This is part of a larger scope work on replacing CMD_LOGIN with new API endpoints. Motivation for this change is to decouple completely unrelated actions into separate endpoints. Old CMD_LOGIN used to perform three unique operations:
  • Initial log-in from unauthorized user, replaced by POST /api/login.
  • Perform impersonation action (login-as different used without password), replaced by POST /api/session/login-as/switch,
  • Stop impersonating another user and return to original user, replaced by POST /api/session/login-as/return.
Now it performs only the first one. This change would only affect custom skins or 3rd party API integrations because Evolution and Enhanced are already using new API for quite some time.
 
@sysdev it was covered in this hread. All DA supported systems has ss tool which supports this parameter. You might be having such problems if you use CentOS 7 and do not install any system updates. CentOS 7 it initially came out with old ss which was later upgraded. Just make sure your system is up-to date.
 
I got the error "could not connect to database" when access the database menu (I use enhance skin)
website and phpmyadmin can connect database without problem.
then I select stable channel and update back to 1.660, and can manage database without problem.
I check /usr/local/directadmin/conf/my.cnf and mysql.conf both look ok with correct password.
once update back to 1.661 error "could not connect to database" came back.
now using 1.660 for workaround.
 
@kke, please open a support ticket so we could investigate this issue further.
 
fln said:
@Stije, CMD_LOGIN is not removed, but this command can no longer be used for user impersonation feature (also known as login-as feature). It is present in the change log. It also includes backwards compatibility layer, if you would try using CMD_LOGIN to perform impersonation request you would get a message explaining it should not be used and the button to actually perform this action using new API. The command CMD_LOGIN can still be used for normal user log-in.

This is part of a larger scope work on replacing CMD_LOGIN with new API endpoints. Motivation for this change is to decouple completely unrelated actions into separate endpoints. Old CMD_LOGIN used to perform three unique operations:
  • Initial log-in from unauthorized user, replaced by POST /api/login.
  • Perform impersonation action (login-as different used without password), replaced by POST /api/session/login-as/switch,
  • Stop impersonating another user and return to original user, replaced by POST /api/session/login-as/return.
Now it performs only the first one. This change would only affect custom skins or 3rd party API integrations because Evolution and Enhanced are already using new API for quite some time.
Click to expand...

+1 for being notified about destructive API changes in advance in the future, if possible. Otherwise we can't run directadmin auto updates as we can't trust them. This broke our integration and we've had to roll back to 1.660 until we can fix.
 
We did not expect CMD_LOGIN to affect any integrations, since the changes are only affecting cookie based (web-browser) sessions. It should only affect custom skins. Fix for custom skins is quite easy - just pick the new code from Enhanced.

It seem CMD_LOGIN was used in different situations than we expected. Would be great if you could share more details what kind of integration flows were disrupted by this change.
 
kke said:
I got the error "could not connect to database" when access the database menu (I use enhance skin)
website and phpmyadmin can connect database without problem.
then I select stable channel and update back to 1.660, and can manage database without problem.
I check /usr/local/directadmin/conf/my.cnf and mysql.conf both look ok with correct password.
once update back to 1.661 error "could not connect to database" came back.
now using 1.660 for workaround.
Click to expand...

Found the same error on another server, both are running AlmaLinux8 with mariadb 10.6

2024-03-30_110114.jpg2024-03-30_110233.jpg

After update mariadb to the latest minor version 10.6.17 the problem is solved.
 
Any insight into what the new log_email_ftp_password_change configuration option does?
 
@sparek, config option log_email_ftp_password_change was introduced in 2017 to get more debugging info when users change email or ftp password. It was supposed to be for internal use and no longer needed. Since you have brought it up we will most likely remove it in the next release.
 
fln said:
@sparek, config option log_email_ftp_password_change was introduced in 2017 to get more debugging info when users change email or ftp password. It was supposed to be for internal use and no longer needed. Since you have brought it up we will most likely remove it in the next release.
Click to expand...
Hmm...

My servers indicate that this is a new configuration option that wasn't present in 1.660 but is in 1.661

Code: 
# /usr/local/directadmin/directadmin version
DirectAdmin v.1.660 351bc3cb3edd62304d5d7a96b59b79211e607eff
# /usr/local/directadmin/directadmin c | grep log_email_ftp_password_change
#

Code: 
# /usr/local/directadmin/directadmin version
DirectAdmin v.1.661 af58c9ce1ce5cf40248c550ca667baf3dd6d8bf9
# /usr/local/directadmin/directadmin c | grep log_email_ftp_password_change
log_email_ftp_password_change=0

I don't expect it to be very much, but didn't see any references in the changelog.
 
I see, this config option in older versions was deliberately hidden from the da c output. In DA 1.661 config printing was slightly restructured and this exception for hiding the option was removed.
 
Admin SSL Bug remains.

Configuration is not saved, and/or lost after a short period of time, all checkboxes gets unchecked, wich causes issues with SSL renewals.

or maybe i'm still the lucky one with SSL issues.
 

Attachments

  • adminssl.png
    adminssl.png
    70.2 KB · Views: 3
fln said:
@Stije, CMD_LOGIN is not removed, but this command can no longer be used for user impersonation feature (also known as login-as feature). It is present in the change log. It also includes backwards compatibility layer, if you would try using CMD_LOGIN to perform impersonation request you would get a message explaining it should not be used and the button to actually perform this action using new API. The command CMD_LOGIN can still be used for normal user log-in.

This is part of a larger scope work on replacing CMD_LOGIN with new API endpoints. Motivation for this change is to decouple completely unrelated actions into separate endpoints. Old CMD_LOGIN used to perform three unique operations:
  • Initial log-in from unauthorized user, replaced by POST /api/login.
  • Perform impersonation action (login-as different used without password), replaced by POST /api/session/login-as/switch,
  • Stop impersonating another user and return to original user, replaced by POST /api/session/login-as/return.
Now it performs only the first one. This change would only affect custom skins or 3rd party API integrations because Evolution and Enhanced are already using new API for quite some time.
Click to expand...
@fln So just coming back to your post explaining the updated CMD_LOGIN.

We have a custom integration where we used the /CMD_LOGIN route to log our users in to DirectAdmin at user level as described here.
We don't know the passwords to all of our DirectAdmin users as there are hundreds of them. So we used our admin-level DA user to "impersonate" the required user in question.
It's essentially a system we use to maintain all of our WordPress websites run on multiple DirectAdmin servers. You would essentially click on the server icon of a particular website and it would log you into DA on the correct user.

So my question to you is; What would you recommend we do now to recreate this behavior, so we can continue to use the same system workflow?

We have attempted multiple solutions but none of them were fruitful and we can't really find anything in the documentation that looks like it's going to produce the same results as /CMD_LOGIN used to.

Also @Stije claims to have found a solution to their issue. Assuming it was something similar to ours, I would love to hear more about that.
 
@AlexJames, thanks for providing more details. You can find more information how to use the API here. Please open a support ticket and we will help you upgrading your integration.

Using impersonation or login-as and passing session to the client is quite risky. This is because user having such session can always perform return from login-as operation and gain admin access to the DA server. If it is used by users who has admin access anyway this might not be a problem.

A safe way to achieve the desired effect would be to access login-url API using admin credentials (API access can use basic HTTP auth, no need for cookie or session support). Create new login URL and pass the returned URL to the client. Using this URL client would be able to log-in DA directly but this would create new normal user session (without possibility to gain admin access by returning from login-as / impersonation). The impersonation is only used to acquire the login URL.

Practical example, assuming:
  • server.example.com - DA server hostname
  • admin - DA server admin account
  • admin_password - DA server admin account password
  • john - DA user account we want to acquire session for
On the server, we can construct new login-url using impersonation and admin credentials with the following request:

Code: 
curl -s -X POST -d '{}' "https://admin|john:[email protected]:2222/api/login-keys/urls" | jq .
{
  "url": "https://server.example.com:2222/api/login/url?key=wLz7RZuNt7hr4WSi3GLwodtLOTLr5TGS",
  "id": "HASHURLY2L4CBI5AK6WS4NKNN6BRGTO2E",
  "expires": "2024-04-15T14:43:36.034285499Z",
  "allowNetworks": [],
  "created": "2024-04-12T14:43:36.034285499Z",
  "createdBy": "192.168.0.1"
}

From the response we extract url field and pass it to the client. When this URL is opened in the browser it will auto-log-in as john user.
 
You must log in or register to reply here.
Back
Top