I'm wondering if we need broader SUL/OAuth testing. Sumana reported on IRC:
mmodell wrote on 2014-07-22 16:08:02 (UTC)
I've seen this behaviour before but only a couple of times.
Rush wrote on 2014-07-22 16:09:50 (UTC)
the provider is disabled because there is no _ssl_. I will try to remove it so people stop trying I guess, but there is no way to delete in the UI.
Aside from that, maybe we could throw a better message if it is disabled, I thnk there is a ticket for it already.
Rush wrote on 2014-07-22 16:11:04 (UTC)
anyways, to this point I haven't wanted to enable auth providers without ssl to phab :)
csteipp wrote on 2014-07-22 16:15:27 (UTC)
The issue is that mediawiki.org uses the canonical url in the JWT assertion, which is http://www.mediawiki.org.
I thought we had a patch that checked for 'HTTPS?://#'?
mmodell wrote on 2014-07-22 21:14:39 (UTC)
Why would that cause it to fail when you aren't logged in to mediawiki but yet it will work when you are already logged in?
qgil wrote on 2014-07-23 11:33:57 (UTC)
From the task description:
I'm wondering if we need broader SUL/OAuth testing.
From https://www.mediawiki.org/wiki/Phabricator/Plan#Migration_plan:
- Deploy a separate Phabricator in a production server only with Wikimedia SUL enabled for log-in testing.
No need to wonder. Let's follow the plan. :)
qgil wrote on 2014-08-04 10:06:46 (UTC)
Is this task a Wontfix in fab.wmflabs.org and not an issue in the production site (since SSL will be in place there)?
If I understood the problem right, the solution for users not able to login now here with Wikimedia SUL is to login to the local Phabricator account directly. If they registered with their Wikimedia account, they can simply click on "Forgot your password?" and get a new one, correct? This will not change their Wikimedia SUL password.
Rush wrote on 2014-08-20 15:14:11 (UTC)
More or less yep, only local accounts exist here. Won't be the same in prod.