I need a login widget I can show the user to login without leaving the current page. This kind of widget can be used in many places, for example in Special:Translate to recover from expired session or log in on other pages to be able to make changes.
Because there might be captchas, rate limiting etc. I think that such widget should exist in MediaWiki core.
A login widget could be easily spoofed by a malicious user script (while Special:Login is difficult to spoof). Bug 48931 was closed as WONTFIX for the possibility that an evil script could replace the links in Special:Preferences to change the password, which seems a more difficult attack to me than simulating a login widget and sending the entered password to a server under the attacker's control.
(In reply to Michael M. from comment #1)
naak naak naak, again such a security nonsense; the same as in Bug 48931 -- either we trust user scripts and this is what we currently do (see below) or we don't and they must be completely removed.
(In reply to Rainer Rillke @commons.wikimedia from comment #2)
(In reply to Michael M. from comment #1)
- Do you store passwords in your browser for Commons? Firefox? Please log
out and go to
https://commons.wikimedia.org/w/index.php?title=Help:Gadget-Cat-a-
lot&withJS=MediaWiki:ActivateGadget.js&gadgetname=Cat-a-lot -- see your
password will be pre-filled and my evil script could read it. Scary, isn't
it :~)
Even if I allow Firefox to store my password for Commons (which normally I don't do) only my user name is prefilled, not the password.
(In reply to Michael M. from comment #1)
A login widget could be easily spoofed by a malicious user script (while
Special:Login is difficult to spoof).
There's actually nothing that makes Special:UserLogin particularly difficult to spoof. Using malicious JavaScript, you can even spoof the actual URL using history.replaceState (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history), so that when someone clicks a pre-determined link (or visits a particular wiki page), their browser URL bar will show the exact URL of the normal login page, and the web page can look like the login page.
The solution is to keep a careful eye on all scripts in the MediaWiki namespace, and be cautious when installing user scripts.
If we do add such a "login and stay on the page" feature (which is under discussion, e.g. as part of a potential "login and save your edit" combination workflow), we will also have to communicate it to avoid confusion.
However, security concerns should not simply block all discussion and development of features in this area.
+1!
With the additional service that without having to leave the page, you can check if you're still logged in and if not, log in again. I'm not sure if this would also put an end to the problem of expired session data, but it's a step in the right direction.
Evidently this would need to be an option available to site owners, to be enabled in Localsettings.php (for all editors) and perhaps Special:Preferences. If you don't trust this feature to be available on your site, then don't opt in for it.
OTOH, action=clientlogin is the modern method for login since 1.28. action=login is deprecated except for bot passwords.
T208823: Support asynchronous reauthentication is vaguely similar in that it also proposes a JS-based login popup (which post-AuthManager basically means a form builder) although for different reasons.
+1! This would be especially useful for users with a slow connection, as going through the login process currently takes two new URL page loads.
At MediaWiki-Platform-Team we've been working on adding the ability to shown the login form in a popup window. We started on it for different reasons (SUL3), but it would also fit this use case. I hope you don't mind me closing this in favor of our task with more details about it, if I also promise that it will be implemented soon :)
I don't mind, but the question is whether it will be ready before the 10-year anniversary :)