There is currently no way to login to SUL on production. Regular login which asks for password isn't possible because of restrictions set by wmf. This blocks the development of app, until any kind of login is enabled by wmf operation team.
Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30348
(In reply to comment #0)
There is currently no way to login to SUL on production. Regular login which
asks for password isn't possible because of restrictions set by wmf. This
blocks the development of app, until any kind of login is enabled by wmf
operation team.
Eh, what?
Ryan Lane is going to discuss some alternative options which are possible, however until then the development is kind of blocked, so I created this ticket so other devs of huggle wa can see the reason
What he's saying is that the web version of huggle needs to log users in as themselves, which means it needs to ask for their username/password. Obviously this sucks a little, but there's no alternative because we don't support OAuth.
(In reply to comment #2)
Ryan Lane is going to discuss some alternative options which are possible,
however until then the development is kind of blocked, so I created this ticket
so other devs of huggle wa can see the reason
(In reply to comment #3)
What he's saying is that the web version of huggle needs to log users in as
themselves, which means it needs to ask for their username/password. Obviously
this sucks a little, but there's no alternative because we don't support OAuth.
Essentially that's no different to how the Windows app works - You still enter your username and password into the application. Just for the web app, you're giving a remote server your details too...
(In reply to comment #3)
What he's saying is that the web version of huggle needs to log users in as
themselves, which means it needs to ask for their username/password. Obviously
this sucks a little, but there's no alternative because we don't support OAuth.
thread here: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59502
Ryan:
is there going to be a work-around for this or we need to wait until oauth is implemented? I suppose that in that case we would need to stop for, maybe several years with this. I don't believe tha t anyone is going to implement oauth into mediawiki sooner than in several months and even if they did, the review and deployment to production would likely take even longer. (My experienceis that code review of extension which consist of less than 40 lines of code takes half a year, see request to review Interactive Block Message extension, which I requested months ago)
mmovchin wrote:
Ryan: Something new with this? We need your input to continue to work :)
An option would be to make Huggle accept the cookies instead of the user & password (albeit many users would have trouble extracting them...).
I have long have the idea of allowing "restricted logins", where you can only use a few rights, precisely for handing out to bots. It would be nice here, too.
Which cookies?
I don't see much alternative here other than OAuth. A web version of huggle would need to act on a user's behalf. Either huggle needs to do proxy authentication, which is disallowed in labs, or it needs to use OAuth.
I don't really have much say on OAuth priority in MediaWiki. Maybe bring this up on the list again? OAuth is blocking a number of things in labs.
The session cookie. The app could still impersonate the user, but it wouldn't have the "permanent" password.
Yes, getting OAuth (or equivalent protocol) up, would be the right solution.
Is it possible to provide users with an edit token that is visible via preferences (like the watchlist token), and is expired frequently; e.g. daily reset, with an age of 24 hrs after first use of the token.
Apps can use while we wait for OAuth to be implemented, and its simplicity may mean edit tokens continue to be used in simple apps even after OAuth lands.
(In reply to comment #13)
Is it possible to provide users with an edit token that is visible via
preferences (like the watchlist token), and is expired frequently; e.g. daily
reset, with an age of 24 hrs after first use of the token.
Possible? Sure. But it's unlikely to be implemented on Wikimedia wikis. According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071215.html, OAuth is going into testing on Monday, August 19.
ok so oauth is partially available for webapp's so this is no longer a blocker, but for app it doesn't work
"for app it doesn't work" which app doesnt it work for?
Is there a ticket open for why oauth doesnt work?
this is irrelevant, whole huggle-wa project is closed now. bug is closed as it's no longer valid.
BTW the app in my comment from 2013 you responded to was the C++ application for which OAuth is still not useable, only web-based app's are now supported