Last modified: 2013-09-21 09:12:22 UTC
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.
(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...
yes but that is allowed by wmf, while doing it on server is not
(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)
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.
The session cookie wouldn't work. It's different domains and separate clusters.
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
