I raised this a while back - so approve the concept. Right now I just ran another test - logged out and deleted cookies (same as cookie expiring). The Admin Login button is dead and it is not obvious that all you need to do is reload the Login page.

Thank you for your PR!

I would like to see an improvement in the login process, like 2 step login if 2fa is activated (see login form only and then see the 2fa only if the user has it activated).
So probably it makes sense to fix it instead of removing it?

I don't see any code related to this. So nothing to fix on this end.

I would like to see an improvement in the login process, like 2 step login if 2fa is activated (see login form only and then see the 2fa only if the user has it activated).

@nikosdion has spent a long time explaining why this is currently not possible without considerable work ... I tried searching for his post on it, but cannot find it at the moment.

I have actually made the point that it’s not too complicated and published Akeeba LoginGuard proving the point.

I have not tested this PR but I’d like to note that WebAuthn is definitely only possible with JS since it leverages a browser API. Whatever you do don’t go for the wrong assumption that JS = bad, it’s a slippery slope which will push Joomla back more than a decade. We already lost 5 years, we don’t want to render ourselves obsolete before we even ship a new version. Again, commentary WITHOUT testing the PR, take with a grain of salt etc.

Whatever you do don’t go for the wrong assumption that JS = bad

But we are going to agree that authentication by GET request is bad though right, like, um, Joomla 4 allows....

Yeah, GET is not the right way to authenticate anything. POST and token at the very least.

Whatever you do don’t go for the wrong assumption that JS = bad

I dont think the Ajax login is bad per se. I just think, along with literally all other login system Ive seen online, that if authentication fails (using Ajax), then the password field should have its submitted value removed.

I have tested this item 🔴 unsuccessfully on 9b083a3

Sorry Sharky this didn't work for me.

Applied patch.
Logged out.
Could not log back in.

Are there any instructions that I missed?

@uglyeoin This requires running node build.js --compile-js. Added this to instructions. PRs with NPM Resource Changed label can't be tested using Patchtester without CI integration.

@SharkyKZ apologies yes me being thick. Will leave it to someone else until I can get XAMPP

I have tested this item ✅ successfully on 9b083a3

Good: login still works. And if I offer bad credentials I get 'Username and password do not match or you do not have an account yet.' . And with good credentials I can login. Um - it works without the patch too.

I have tested this item ✅ successfully on 9b083a3

RTC

Fixing would be better then removing...

in theory i would agree with you....but practically speaking... as we suffer for not having constant js expert contributors...

@HLeithner My two cents as a long time Joomla extensions developer, oftentimes core contributor and a person who deals with site security for a living.

Using AJAX for logging into Joomla's backend doesn't solve any real world problem. AJAX logins make sense in exactly ONE (1) use case: when the login server is different than the application server. This is not true in Joomla and even if you really want to do it we already implemented the additional login buttons (part of the WebAuthn PR that's been merged for a long time now) making it possible. On that note, I only halfway agree with what @PhilETaylor wrote earlier about other services using AJAX logins (they do because the auth server and the app server are different which is not the case in Joomla).

The backend AJAX login is a solution in search of a problem which, ironically, causes problems of its own. Off the top of my head, there are two very important ones that I've been bitten by, one functional and one security.

1. It hides all error messages. I installed Joomla and I tried to login. I didn't know at the time, but my db server had just croaked. I was getting consistent error messages about my account information being wrong. If I were a normal user experiencing that after installing Joomla I'd have given up on it and call it broken. I am not the average user. I started debugging it, looked at the dev tools' Network tab and realised the problem was the database.

2. Using GET is counter to any sane security practice. It logs the username and password in the access log. @PhilETaylor already explained this.

Fixing these issues would require using POST in the AJAX request and parsing error messages correctly...

Only the latter CAN NOT happen because Joomla's unhandled exception handler returns HTML even in the case of a JSON request. Fixing that requires EITHER writing a special error handler which returns different output (HTML, JSON, raw text, ...) based on the Accepts header of the request OR assuming that any string that fails to parse as JSON is an error page and has to replace the entire DOM.

The former is a massive task without any practical benefit outside the backend AJAX login.

The latter is a functional and security issue. Any plugin misbehaving and spitting out HTML results in weird behaviour. This could possibly be exploited e.g. having a vulnerable plugin spit out arbitrary HTML which the AJAX login handler happily spits out in the context of an administrator login. I can think of different ways to abuse that to steal someone's login with a simple spear phishing or social engineering attack (and a moderately savvy user would be none the wiser, seeing their own site's URL in the address bar!).

As a result the only practical way to return to a secure and functional administrator login page is removing the AJAX login. So I am 100% for merging this PR.

assuming that any string that fails to parse as JSON is an error page

Just to note that "some work" has been done on better handling of errors from invalid json returned when trying to login here #30992 - its not perfect, but it handles when the result fails to parse as JSON.

Other issues and security issues remain.

@PhilETaylor This still doesn't give me any information about what went wrong, even if I turn debugging on in configuration.php. DB errors are far more common than you may think. Most of Joomla's target audience is using a prepackaged Windows or macOS server environment where, unfortunately, MySQL is badly tuned and frequently dies. We really don't want them to think that Joomla is broken just because we are too incompetent to give them the actual error message. Just saying.

Thanks @SharkyKZ

Thanks @nikosdion for the Backend I also don't see a good reason why we have ajax login if we don't use it anymore. I was fooled by the title that this is (also) for frontend login...

Totally agree - I was just pointing out that some work had been done on the login js ONLY and not on any other Ajax handler in joomla

All it takes is a single PHP notice or warning from a custom system plugin and then a joomla admin would not be able to login using Ajax (or more correctly he would be logged in) but not redirected to the dashboard due to the JS error...

Plus if this Pr is merged, the other PR is irrelevant and can be closed

Ajax should be used where it makes sense. Here, it makes no sense.