Change Details

MW: 1.41.1 PluggableAuth: 7.1.0 (4111a57) OpenIDConnect: 8.0.2 (3a3fca9) jumbojett/openid-connect-php; 1.0.0 **Steps to replicate the issue**: 1. Visit a wiki that requires OpenIDConnect to view it. 2. Log in and verify your access to the wiki. 3. Close the browser with Alt-f x. 4. Open the browser. 5. Press Ctrl-Shift-T to open the previously closed browser. 6. See error: **Fatal error authenticating user.** Set `$wgRememberMe = "always";` Verify that the above steps do not result in the same error. Repeat the same steps with this additional one after step 2: 2. ... b) Clear your cookies for the site. Verify that you now see error again. Before closing Chrome, I verified the URL was **not** on the Special:PluggableAuthLogin page (where the error occurs). Most recently, it was on Special:Version and I verified that Ctrl-Shift-T brought up Special:Version initially. The PluggableAuthLogin url contained `?code=XXXX...&iss=XXXX...&state=XXXX...&client_id=XXXX...`. Clicking the logo on the sidebar (to visit `Main_Page` or the equivalent) was successful Starting chrome with devtools shows that the initial request (may) be missing the session cookie. In fact, visiting the site "normally" after clearing cookies and starting the browser--that is, typing the url into the browser--seems to bring up the site properly, but also populates the session cookie. Examination of the requests (only possible with chrome's `--auto-open-devtools-for-tabs` cli option) shows that it goes to Special:PluggableAuthLogin without visiting Special:UserLogin where the session cookie is set. I'm a bit confused about why the first request is to Special:PluggableAuthLogin when restoring the tab. I would think it would be to the url on the page when the browser closed. But, in any case, it looks like a visit to Special:PluggableAuthLogin without a session cookie should result in a visit to Special:UserLogin to get the session cookie (or some other method to generate the session cookie).

MW: 1.41.1 PluggableAuth: 7.1.0 (4111a57) OpenIDConnect: 8.0.2 (3a3fca9) jumbojett/openid-connect-php; 1.0.0 **Steps to replicate the issue**: 1. Visit a wiki that requires OpenIDConnect to view it. 2. Log in and verify your access to the wiki. 3. Close the browser with Alt-f x. 4. Open the browser. 5. Press Ctrl-Shift-T to open the previously closed browser. 6. See error: **Fatal error authenticating user.** Set `$wgRememberMe = "always";` Verify that the above steps do not result in the same error. Repeat the same steps with this additional one after step 2: 2. ... b) Clear your cookies for the site. Verify that you now see error again. Before closing Chrome, I verified the URL was **not** on the Special:PluggableAuthLogin page (where the error occurs). Most recently, it was on Special:Version and I verified that Ctrl-Shift-T brought up Special:Version initially. The PluggableAuthLogin url contained `?code=XXXX...&iss=XXXX...&state=XXXX...&client_id=XXXX...`. Clicking the logo on the sidebar (to visit `Main_Page` or the equivalent) was successful Starting chrome with devtools (possible with chrome's `--auto-open-devtools-for-tabs` cli option) shows that the initial request (may) be missing the session cookie. In fact, visiting the site "normally" after clearing cookies and starting the browser--that is, typing the url into the browser--seems to bring up the site properly, but also populates the session cookie. Examination of the requests shows that it goes to Special:PluggableAuthLogin without visiting Special:UserLogin where the session cookie is set. I'm a bit confused about why the first request is to Special:PluggableAuthLogin when restoring the tab. I would think it would be to the url on the page when the browser closed. But, in any case, it looks like a visit to Special:PluggableAuthLogin without a session cookie should result in a visit to Special:UserLogin to get the session cookie (or some other method to generate the session cookie).

MW: 1.41.1 PluggableAuth: 7.1.0 (4111a57) OpenIDConnect: 8.0.2 (3a3fca9) jumbojett/openid-connect-php; 1.0.0 **Steps to replicate the issue**: 1. Visit a wiki that requires OpenIDConnect to view it. 2. Log in and verify your access to the wiki. 3. Close the browser with Alt-f x. 4. Open the browser. 5. Press Ctrl-Shift-T to open the previously closed browser. 6. See error: **Fatal error authenticating user.** Set `$wgRememberMe = "always";` Verify that the above steps do not result in the same error. Repeat the same steps with this additional one after step 2: 2. ... b) Clear your cookies for the site. Verify that you now see error again. Before closing Chrome, I verified the URL was **not** on the Special:PluggableAuthLogin page (where the error occurs). Most recently, it was on Special:Version and I verified that Ctrl-Shift-T brought up Special:Version initially. The PluggableAuthLogin url contained `?code=XXXX...&iss=XXXX...&state=XXXX...&client_id=XXXX...`. Clicking the logo on the sidebar (to visit `Main_Page` or the equivalent) was successful Starting chrome with devtools (possible with chrome's `--auto-open-devtools-for-tabs` cli option) shows that the initial request (may) be missing the session cookie. In fact, visiting the site "normally" after clearing cookies and starting the browser--that is, typing the url into the browser--seems to bring up the site properly, but also populates the session cookie. Examination of the requests (only possible with chrome's `--auto-open-devtools-for-tabs` cli option) shows that it goes to Special:PluggableAuthLogin without visiting Special:UserLogin where the session cookie is set. I'm a bit confused about why the first request is to Special:PluggableAuthLogin when restoring the tab. I would think it would be to the url on the page when the browser closed. But, in any case, it looks like a visit to Special:PluggableAuthLogin without a session cookie should result in a visit to Special:UserLogin to get the session cookie (or some other method to generate the session cookie).