Commit graph

9 commits

Author SHA1 Message Date
Kunal Mehta
4ef179e335 Fix/suppress misc phan errors (#5)
Add lots of missing return statements, or remove incorrect doc blocks.

Change-Id: I0881e98fbb9d0d4cf79ecc824064d24538055d3f
2019-04-05 15:53:37 -07:00
Cindy Cicalese
f7cfed2a4a Bypass login page if no user input is required.
Bug: T141474
Bug: T110464
Change-Id: I9588a2b87a423f614fc5d2e771ad1ac7279ebd0b
2016-11-22 14:10:20 +00:00
Gergő Tisza
94e2aa7b55 Expand SessionManager / AuthManager documentation
Bug: T110628
Bug: T142154
Change-Id: Ib0a41f01b3d12267b2a94ea1375e6d13cacd2b69
2016-08-30 18:54:30 +00:00
Brad Jorsch
83c98e7cd8 AuthManager: Allow for flagging fields as "sensitive"
This can allow AuthenticationRequests to flag certain fields as
sensitive, so e.g. the API can insist they be in the POST body rather
than in the query string.

Change-Id: I7b12aa4cd8f5a570f0df7213c0f9084b5a4d4de7
2016-08-18 19:36:29 +00:00
Gergő Tisza
d4de10750f AuthManager: do not rewrite PRIMARY_REQUIRED to REQUIRED
AuthManager::getAuthenticationRequests() changes
AuthenticationRequest::$required from REQUIRED to PRIMARY_REQUIRED
if the request is from a primary; it made an exception when
all primary providers returned a given request. That exception is
not particularly useful (AuthenticationRequest::mergeFieldInfo()
used to rely on it to determine which fields are required, but
since I9d33bd2 that's not really needed), and knowing which request
is from a primary is useful for other means.

This changes required field semantics in a corner case: when a
primary provider returns two required requests, the previous
behavior was to assume that they are both required; the new one
is to treat them as alternatives (as if they were returned by
two different providers). So when all primary providers return
request X, and one of them returns Y in addition, the fields of X
will not be marked required, while previously that would have been
the case.

Instead of overcomplicating the interface for something that is
unlikely to come up in any real use case, add a new requirement
to PrimaryAuthenticationProvider that it should not return
multiple required requests.

Bug: T141471
Change-Id: I1c1f44d4d6b66f77c876e3459fb97f03483db744
2016-08-17 05:51:53 +00:00
jenkins-bot
f4a2198abf Merge "API: Fixes for AuthManager" 2016-05-30 12:37:34 +00:00
Brad Jorsch
e10f96cff1 API: Fixes for AuthManager
* Set API response metadata on the AuthenticationRequest metadata so it
  is output as an assoc generally.
* Remove the 'image' field in AuthenticationRequest::getFieldInfo()'s
  response, since we ended up not using it anywhere.
* Make it so meta=authmanagerinfo can be used on private wikis without
  logging in, so action=clientlogin can be used to log in.
** This generalizes the exception for meta=tokens that was added in
   I83dafb030.
* ApiAuthManagerInfo needs the "messageformat" parameter.
* ApiAuthManagerInfo shouldn't be publically cached, since the responses
  vary depending on session state.

Change-Id: Iea5ddb4ef9febed18f16a7ae8314968026f39148
2016-05-30 08:25:19 -04:00
Gergő Tisza
d0e6051b5c Fix required field calculation in AuthenticationRequest
Instead of only flagging fields which are required by a request
needed by all primairy providers, it should be enough if all
requests needed by some primary provider require that field.

Also make CreationReasonAuthenticationRequest non-required so that
the list of required form fields is more in sync with that of
pre-AuthManager code.

Bug: T85853
Change-Id: I9d33bd22295758cc532a260b1848616b41d94f12
2016-05-30 11:57:58 +00:00
Brad Jorsch
d245bd25ae Add AuthManager
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.

Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
2016-05-16 15:11:02 +00:00