Provide test coverage to prove that a third party authentication provider does not automatically start a session

This actually depends on that

#2228393: Decouple session from cookie based user authentication is in; should this issue be repurposed for test coverage, or marked fixed?

Proper parenting

This should be pretty easy, we already have all the necessary ingredients in SessionAuthenticationTest.

Something like this should do the trick. I'm testing both that cookie sets a cookie, and basic auth doesn't.

I am removing the Novice Tag from this Issue because there are no Novice tasks left.

Fixed a little typo in my patch.

Good points, will address these today during my lunch break.

Updated the documentation with @znerol's suggestions.

Also replaced "yield a cookie" with "set a cookie" in the assert messages.

Patch didn't apply any more since #2283637: Provide test coverage to prove that an AuthenticationProvider can initiate a session went in. Rerolled against latest HEAD.

Interesting, seems we have a cookie :)

I'll have a look. If this is the case then this is a separate issue. I'll reorder the tests and open a followup to ensure that the cookies are properly initialized on every request.

This is a bit more robust. I'm now inspecting the request headers to see if the string "Set-Cookie" is present.

I looked into the cookie bleeding issue and this is indeed what is happening. In WebTestBase::curlHeaderCallback() the $this->cookies property is filled whenever a cookie is set on the request but these are never cleared to simulate the browser persisting the cookies inbetween requests. We should clear this whenever a new test starts.

Created followup for the cookie bleeding issue: #2491353: Cookies from previous tests are still present when a new test starts.

I already pointed about cookie leak in #2484991-3: Add the session to the request in KernelTestBase, BrowserTestBase, and drush
Great to have separate issue for that

Used $this->drupalGetHeader() as suggested in #25.

Also changing this to a task, the bug is already fixed in HEAD.

The second one has a redirect. The first one doesn't but I kept the TRUE parameter for consistency. I'll get rid of it.

Got rid of the needless TRUE.

+++ b/core/modules/system/src/Tests/Session/SessionAuthenticationTest.php
@@ -110,4 +110,28 @@ protected function assertSessionData($response, $expected) {
+    $this->assertFalse($this->drupalGetHeader('set-cookie'), 'No cookie is set on a route protected with basic authentication.');
...
+    $this->assertTrue($this->drupalGetHeader('set-cookie', TRUE), 'A cookie is set on a route protected with cookie authentication.');

Hmmm... I think we should be consistent here. Not sure I agree with the change in #30 since the tests are supposed to be opposite.

I'm siding with Alex on this, because it doesn't look as if we are doing a regular positive-negative test here. Even though this is totally correct it just looks a bit suspicious to me.

As a middle ground, would it perhaps be a good idea to set $this->maximumRedirects to 0 to stop the redirection taking place?

I dunno - in my opinion it makes sense to set the $all_requests to TRUE in both instances because what you are looking to test is that no request has set a cookie or that at least one has.

OK! Re-uploading the one from #27.

Committed 72fb794 and pushed to 8.0.x. Thanks!

Thanks @pfrenssen and @znerol for sticking with this and adding the beta evaluation to the issue summary.