DirectAdmin v1.670

A full release change log is here:

DirectAdmin 1.670

The update should be automatically available for all installations subscribed to the current release channel.


Hello,

Thank you for your hard work. Not going to complain, but still don't want to keep a silence. Users will for sure find the things broken. So I'm curious how do you comment the idea of removing a user password from a session file /usr/local/directadmin/data/sessions/da_sess_*? What made you to do it? We have developed a number of plugins for DirectAdmin (and I believe so did the other developers) where we rely on a password stored in the user session file. We use the password to do API calls to Directadmin. So what is behind the scene? What is the logic?
 
Storing a plain-text password in the session file was a big legacy security hole. We are really happy that we finally managed to restructure DirectAdmin to the point where we can eliminate it. It completely defeats the purpose of storing encrypted passwords and allows system admins, rogue plugins, or any other high-privilege process to just collect user passwords in plain text. Since some of the end users re-use the same password for different services, this makes them extremely vulnerable. There is absolutely no justification for bringing this anti-feature back.

Unfortunately, some integrations might have abused this anti-feature for easy access. But this is also an opportunity to upgrade them and make them more secure. Any plugin that already has access to the session hash does not need to know the user password to make API calls. The plugins can use the session hash to make requests with session-based authentication. In the same way as a user browser makes requests without a user password after the user has successfully logged in.

Historically, plugins using session-based authentication had to fight against the referrer checks. So DA has multiple mechanisms to bypass it (passing the key from the session file as a cookie or adding the X-DirectAdmin-Session-ID header). However, we are working on improving the referrer checks to the point where all these extra hoops will no longer be necessary.
 
If someone has an EOL OS, why doesn't DA alert them of the fact - it used to when CB was its own entity IIRC..... #justanidea
(y) We already expose the EOL flag in the DA version API endpoint. In next DA version it will be visible on the GUI as well.
 
Any plugin that already has access to the session hash does not need to know the user password to make API calls. The plugins can use the session hash to make requests with session-based authentication. In the same way as a user browser makes requests without a user password after the user has successfully logged in.

Thank you.

It is true for widgets only, correct? Server side's plugins can not authenticate without a password, can they?
 
The same mechanism can be used in server-side plugin widgets and in server-side plugin pages. The session ID is exposed via the environment variables. Without it, it would not be possible to read session files. The plugin scripts that used to lookup the user password in the session file should use the session ID in the request instead of using it to find the file.
 
The session ID is exposed via the environment variables.

Ah, OK. I confused it with a KEY from a da_sess_* file. And API calls with the KEY did not successfully complete. I will test the "session-based authentication". Thank you.
 
A new hot-fix release is pushed out. It fixes two issues reported in the ticketing system:
  • A bug in File Manager compress and download dialog not showing up.
  • On older systems loading plugins fails when tickets.conf file does not have a html=... line, newer systems had this line present in the config file.
 
I noticed a new skin bug. In Android, when using desktop mode (like Dex) the sign out button is usually out of sight. In previous versions I was able to simply scroll down and click logout, but on this new update, the left menu does not scroll and the logout button stays out of view. Same behavior is seen using Android phone and the left side menu does not scroll so logout is unavailable.
 
@jca, would you be able to add a screenshot to illustrate the issue? I was unable to reproduce it or was looking for it in the wrong place.
 
@jca, would you be able to add a screenshot to illustrate the issue? I was unable to reproduce it or was looking for it in the wrong place.

I'm able to scroll on the white side, but the blue side won't scroll. So I can't scroll down to find the logout button. I also made a video if there's still doubts let me know and I can share.

1000061315.jpg
 
Last edited:
I just discovered something, is maybe longer in there.

When restoring an account from another server, the old ipv4 addresses are changed to the new ones.
But with the ipv6 in DNS, the old ipv6 addresses are not changed, but the ipv6 of the new server is just added.

This way there are 2 ipv6 addresses for every AAA record, while there should be only 1.

Edit: This is on restore of reseller using admin backup/transfer. Does not seem to occur with user restore using the reseller "manage user backups" option.
 
Last edited:
I know we're probably one of the few still using the standard theme, but the new ‘Search for pages’ search bar really doesn't look good on it. I hope this will be improved. Otherwise it will probably be time to switch to the new theme at some point, which I really don't like :/
 
for example search userinterface before i searched data the all what was left was databases

now nothing is left and you have to click search - for example i search for database ( data was enough before and there was just this symbol left WITHOUT clicking search ! - now you have to click search and nothing in return
 

Attachments

  • nothing.jpg
    nothing.jpg
    377.2 KB · Views: 11
Last edited:
In my opinion grid layout has bad font because font isn't clear. I prefer another font, like this font-family: "Lato",Arial,sans-serif;

Screenshot 2024-11-20 at 19-28-24 s1.aldstudio.pl Dashboard.png
 
Back
Top