You've mentioned as available options only "connect a SUL" or "use LDAP" (which i don't think i have). Since trying to "connect" asks for permission "to have basic access on [my] behalf on all projects of this site" (umm, which site is that?!) -- for unspecified actions, i won't use that. Guess there's no way to create an unconnected account?
Later Edit: Apparently this is by design... And they talk about "a barrier to filing new bugs" in that one, really?!
I'd be interested to know the exact steps that you perform and the exact error message that you receive if the displayed message is too vague. :) We don't support unconnected accounts as "I have to create a seperate account" was one of the major complaints about Bugzilla (the predecessor of Phabricator). Similarly, we don't support unconnected (non-unified) accounts between different sites like e.g. fr.wiktionary and cs.wikisource either.
There's no error. But removing the need to create a separate account *DOESN'T* mean you have to ban their existence...
Later Edit: Hopefully, you *do* realize that every single one of the Bugzilla users have somehow managed to create their separate account... How many of them complained, percentage-wise?
It's asking for access to some of your information across all Wikimedia sister projects connected to mediawiki.org (basically all WMF websites). The site in question is the site presenting the dialog (which is mediawiki.org if I remember correctly). This shows what access it is getting specifically. Basically your account information and read only access to the WMF projects. I've filed a ticket to improve the UI request to make it more understandable what the permission is asking for.
LDAP is used mostly by the developers.
If it were merely "asking for access to some [...] information" why would it need to be "on [my] behalf"? I don't plan on accessing that info myself more often than once in a blue moon when i need to update something... Maybe it's on behalf of my browser?
The site presenting the dialog does seem to be www.mediawiki.org, but if i grant any of the rights you linked to, it apparently could then "Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)", or "Edit pages (edit)", etc... Why would i allow any of that? There should be a "read profile data" level of access that DOESN'T allow any action. In fact, there should be a "Read only a profile token that doesn't contain anything other than a unique identifier for my mediawiki id", and i would set up my profile on phab to anything i want, regardless of what my MW profile says.
PS Apparently, an OAuth-rights-request dialog could show what actions it's asking for (even though an "interact with pages" doesn't seem to be in the current list of available rights)... Phab isn't, so it makes me wonder what's it trying to hide.
I think the "on your behalf" part is because phab requests to mediawiki will be made impersonating your user, not using a phab role account nor anonymously.
Anyway, sure the wording/UX could be improved. Patches welcome but maybe you're not interested in getting that involved.
The bug you linked (phab:T16) is already closed. Maybe this is covered by phab:T542 or a related bug or maybe a new one needs filing. cc Qgil-WMF
Jeremy, i might consider getting involved enough to make and submit patches, but i'd need to actually understand the process first.
What requests does phab intend to make to mediawiki at all?! It should (IMO) just LINK accounts, not *do* anything that involves impersonation. I'm not worried about anonymous actions, but about actions i would not be aware of. As an extreme example: does creating a task at phab update my MW user-page by adding a notice about that task? Can you (or anyone) guarantee that it never will? Because the way i see it, i am essentially giving it permission to do so, if it so deems appropriate.
And lastly, i had linked to a closed task since that explained the original decision which lead to the current status-quo that doesn't allow the existence of "local" (phab) accounts. I don't particularly need an improvement into the SUL login dialog UI, since i don't intend to use it anytime soon. I'd rather open a new bug that overrides T16 and *allows* local accounts, but i obviously can't report it there before i somehow manage to login. :-)
Yes, you are potentially giving it permission to do that. No, no one will gives guarantees that it won't (because people have better stuff to do). If that's not good enough for you, then unfortunately you cannot make use of the WMF's Phabricator. But you should really ask if you want anything to do with any of the services in that regard. I mean a WMF sysadmin can intercept your password if he would want to. Can you trust that he won't ? That's your choice to make.
[edit] also, you can always revoke the permission of any connected 'app' at any moment, from your preferences.
> If that's not good enough for you, then unfortunately you cannot make use of the WMF's Phabricator.
or use LDAP. (same creds as wikitech and gerrit)
I don't think i have yet found any need for using wikimedia's LDAP extension (unlike for bugzilla), and i don't intend to ever use gerrit (for personal reasons). As for wikitech, i either don't understand what you mean, or you're wrong...
That linked posted does not mention wikitech and I'm not sure how pasting a link here to a mailing list posting that links back to this very discussion adds anything to the discussion. To summarize: To log into Phabricator, either use your Wikimedia SUL account (which is already a cross-Wikimedia site login for lots of Wikimedia sites) to connect to lots of Wikimedia sites plus one more (namely Phabricator), or use your wikitech/Gerrit login. Those are the available options.
Umm, the very first thing on that page is " wikitech-l @ lists.wikimedia.org ", how can you say it does not mention wikitech? The fact that it's linking back to this discussion is irrelevant, i was merely pointing out that i was able to use wikitech-l ( as " jokes_free4me " ) without using LDAP. But it's becoming clearer that i really have no idea what you mean by wikitech... Could find only red links wherever i looked: Wikitech, Wikipedia:Wikitech (deleted as not significant!), Wikipedia:WP:Wikitech...
"Wikitech-l" is the mailing list. Wikitech: is a subdomain, that stores documentation on Wikimedia's particular instances of MediaWiki including Wikimedia Labs (vs this site, which is a general resource for anyone who uses MediaWiki). It's also (iirc) all hosted on a geographically separate hardware cluster, for access if the main sites are inaccessible.
The missing explanation at Wikitech is well-noticed! I'll add a stub description there, now. (And yes, much like wikitech:Labs labs labs, and wikimedia mediawiki wikipedia, and [...], it highlights our grand old tradition of naming things confusingly! (as shared by much of the software world... ;-)
Hope that helps.
( i think it's because they *can't*, not because they also have better stuff to do )
Actually, i accept the risk from a sysadmin (an actual human being) because they actually NEED that kind of access to perform their tasks. Phab (a *tool*) doesn't need the permissions it asks for. Or if it did need them, it wouldn't be for performing its main tasks, so i wouldn't want to keep using it. Thanks for the clarifications.
[and yes, i already revoked detailed permissions from the single app that i had accepted so far.]
I think this stuff boils down to the same "login with" facebook/github/google/... feature you find on other sites, only that it's "login with WikiMedia SUL" for phabricator, and, as you said, there is no ordinary login without SUL or LDAP. On the abandoned labs tools RFC an editor apparently misunderstood the subtle difference between "SUL" and "login with Wikimedia SUL", of course it is a different account, and I still test how no phabricator account works—so far good enough for me.
I think they just ignored the difference between "sharing SUL details with phab-prod" and having SUL "just work" on phab...
The Wikimedia MediaWiki API Team is working on phab:T88757 which would add an "authenticate only" grant to our OAuth extension. Once this is implemented we can change the Phabricator OAuth configuration so that Phabricator is not granted any rights to interact with the wikis as your user and instead only receives a "yes this user is valid and authenticated" response. The current "basic access" grant is not much wider than this in practice when not combined with additional grants, but omitting this feature was a shortcoming of the initial OAuth project planning that we hope to correct soon.
Sounds interesting enough to deserve a {{tracked}} for a future RESOLVED or WONTFIX-insecure status update magic. Unrelated bugs: Preview of a reply in a new tab does not work. I tried "new tab" because my last "preview" test ended up in "visual editor".—it's still doing this, note to self, if pages appear to be completely out of line look for and click </>.
That "unrelated" bit is not a full-blown bug though: many "actionables" (links and buttons) have been changed (all over the web, not just here) to link to "#" and perform their code via JavaScript events... Breaking existing usage, but the developers prefer style over minor conveniences. (And that's how "previewing" on Flow works: it changes from Wikitext editor to Visual editor and thus reuses the textarea to show an editable preview.)
If the SUL way bothers you for some reason, you can just create an account in https://wikitech.wikimedia.org/ and choose the LDAP way using that new account.
