d70fbfc691 introduced a new helper
function to Rest handlers that prevent caching the response if it sets
any cookies. However, responses to requests where a cookie-based session
(anonymous user with session cookies or logged-in user) are not safe to
cache at all because the session manager may itself attempt to set
cookies on the response outside of the Rest framework, and the response
contents themselves may depend on user-specific invariants, such as the
user's permissions if the current wiki is private (i.e. restricts the
'read' permission to a subset of user groups). We currently rely on
HeaderCallback to fix the first case for us, and don't cover the second
case, so fix it by explicitly sending Cache-Control: private for Rest
responses for requests with an active cookie-based session.
Bug: T264631
Bug: T285210
Change-Id: I9dec6d4accd5de2bd1bde352d45f82c433913d54
The current signature of the various execute methods only takes a
boolean parameter to determine if the session should be safe against
CSRF, but that does not give callers fine-grained control over the
Session object, including setting a specific token.
Also, do not use createNoOpMock in getSession(), since it implies
strong assertions on what methods are called. This way, getSession
can also be used to get a simple mock session that tests may further
manipulate.
Make $csrfSafe parameter of SessionHelperTestTrait::getSession
mandatory. This way, callers are forced to think what makes sense in
each use case. The various methods in HandlerTestTrait now default to
a session that is safe against CSRF. This assumes that most REST
handlers don't care about the session, and that any handler that does
care about the session and where someone needs to test the behaviour
in case of bad/missing token will explicitly provide a Session that
is NOT safe against CSRF.
Typehint the return value of Session(Backend)::getUser so that PHPUnit
will automatically make it return a mock User object even if the method
is not explicitly mocked. Remove a useless PHPUnit assertion -- setting
the return value to be X and then veryfing that is equal to X is a
tautology, and can only fail if the test itself is flawed (as was the
case, since it was using stdClass as the return type for all
methods). Remove the getUser test case altogether, there's no way to
make it work given the DummySessionBackend, and the test isn't that
helpful anyway. More and more methods will have the same issue as soon
as their return value is typehinted.
Follow-up: I2a9215bf909b83564247ded95ecdb4ead0615150
Change-Id: Ic51dc3e7bf47c81f2ac4705308bb9ecd8275bbaf
