Undefined array key "cookie_samesite" warning after upgrade to 2.02

See attached patch.

I am not sure this is the correct fix.

There should have been an update hook to make sure the config was added.

See the fix for the other new config variables such as:
https://git.drupalcode.org/project/autologout/-/blob/8.x-1.x/autologout....

As a workaround, this can be fixed by visiting the config page and saving the form.

This issue happens if you don't have this set in docroot/sites/default/services.yml.

parameters:
  session.storage.options:
    # Set the SameSite cookie attribute: 'None', 'Lax', or 'Strict'. If set,
    # this value will override the server value. See
    # https://www.php.net/manual/en/session.security.ini.php for more
    # information.
    # @default no value
    cookie_samesite: Lax

Not sure if the suggestion I made here:
https://git.drupalcode.org/project/autologout/-/merge_requests/83#note_6...
Would fix it. Perhaps I should have been tougher on getting that added.

These kinds of warnings happen way too often and it's usually because there is not enough effort put into making sure the data (or lack of) is handled correctly in code.

Thanks for the reports and investigation, everyone. I've done some digging and can clarify what's happening here.

This is not related to js_cookie or requiring update hooks. The cookie_samesite key does indeed come from Drupal core's session.storage.options container parameter, not from module configuration.

cookie_samesite was added to core/core.services.yml in Drupal 10.1 (https://www.drupal.org/project/drupal/issues/3150614).

Sites set up before 10.1 may have a sites/default/services.yml file copied from default.services.yml, when cookie_samesite wasn't included.

Sites with no services.yml, or set up after 10.1, should not be affected as core's defaults apply correctly.

This confirms @train's finding, adding cookie_samesite: Lax to your services.yml under session.storage.options is the correct site-level fix.

A module fix (!empty() instead of ?:) as per the patch supplied by @uberhacker, can also be applied to two occurrences in autologout.module (in autologout_user_login() and autologout_page_attachments_alter()), so the warning will no longer occur regardless of Drupal version or services.yml state.

I'll get an MR prepared asap

+1 for #6 solution
my services.local.yml didn't have cookie_samesite: Lax

thanks for investigating the issue!

seeing this also

MR 93 completely resolves the issue, recommend merging this fix. Our build started on Drupal 8.9, we're now on Drupal 11.3.5. Should work with and without cookie_samesite

@dalin: I fixed the issue which is a bug. You're welcome.

This isn't a bug; not keeping the services.yml file up to date is not the issue with this module.
Adding an if empty is a defensive programming practice that guards against problems elsewhere.

I am also going to add something to the README to make sure users are aware that session.storage.options: needs to be kept up to date in the services.yml file

I have to admit, I was a bit insulted that you think this was due to a lack of effort.
I have been working on dozens of tickets over the last few months to get this module up to a better standard. This ticket #3308456: Autologout cookie is not secure has been open since 7 Sep 2022, and I don't see your code review suggesting that things should be done differently @uberhacker. So perhaps if you wish to comment about a lack of effort, it shouldn't have been framed as a criticism but rather as an apology.

That being said, I will put my hands up and admit it was an oversight on my part to assume cookie_samesite: Lax would be set correctly in the session.storage.options; this module supports ^9.2 || ^10 || ^11, so I should have accounted for it not being set. Sorry.

Removed the cookie_samesite from core.services.yml cleared cache and then logged in. There is no error present and the cookie is set as Lax, so marking this as RTBC.

We're using hundreds of modules and no others threw an undefined array key error on every single authenticated page load of the website. I recommend merging.

Hi everyone,
I just wanted to share another possible approach for this solution that I developed before coming across this Drupal issue.

Hi @natnatalia , yes can please you roll in your changes into the MR 93 please? It is an improvement IMHO. Press the big get access button up top and follow the instructions at "Show commands"

Updated

Thank you @natnatalia! Yes, your patch is more elegant. However, I wasn't able to apply it. Attached is an updated patch that should work for both 2.0.2 and 2.x-dev presently.

#27 patch works with 2.0.2 version. Thank you!

diff from the PR should work fine with either 2.0.2 or 2.0.x-dev

Patch files are no longer recommended, use merge requests instead.

The MR!93 at #26 applies and is working for me.

I'd give a +1 for RTBC.

Updating the title too. There's 2 other issues that were closed as duplicates of this one. This should make it easier to find.

Merged

I saw, that there are some fixes after the latest update (2.0.2). Is there a release planed?

Yes, getting the ducks in a row.

I want to create one last 2.x and 8.x-1.x release and also a new 3.x release that can remove the D9 and >10.2 support.

I am needing to get gitlab permissions increased before then, though.

@juburin: I suggested granting @the_g_bomb the Maintainer role in #3497097: Offering to co-maintain Automated Logout, without luck ... maybe because the issue is closed, the Maintainers don't follow it?

@the_g_bomb: Maybe you need to create a formal application issue? If useful as inspiration, here's a "request Maintainer role" issue from another project: #3556750: Applying for 'Maintainer' role for the project Block Class on Gitlab.

Any new status on a release?

Since using MR as patches is a security issue, the patch file was provided. (Waiting for the new release)