Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Because the module evolved so slowly, this issue has evolved with it over major releases.
My current plan for a 4.x rewrite follows. This is just my personal plan, it has no timeline, and I have no idea if the bigger things will happen. There is no sponsor.
Theme: keeping the same functionality while adding automated tests, becoming more logically structured (and therefore easier to work on), and helping other external authentication modules achieve success faster.
1) things that will happen and define the maximum deadline for 4.x
#3211541: Get rid of deprecated code (breaking D8 compatibility) are relatively small changes that must happen before Drupal 10 - so will trigger a 4.x release before D10 is stable. (Outdated / untrue: the 8.x-3.x now supports Drupal >=9.2 and D10 since 8.x-3.6. This -raising the minimum supported Drupal version in a minor release- is fine, and module major version changes actually should not be tied to Drupal major version changes.)
2) things that will likely happen before 4.x is released
#3211529: Refactor SamlService::getAttributes() to a value object. (issue is a bit windy, may be split up)
#3211531: Remove Forwarded-For-*/proxy config settings (easy)
#3211530: Move login/logout error handling to event subscriber
#3211536: Reimplement response caching on login/logout routes (not super urgent)
3) things that I'm interested in but take more work than I can commit to
Work on externalauth.
- I've made a start at a plan in #3179148: Redo authmap_alter / register events.. Basic summary: basically 'noone' is using externalauth's events. I want to change them so they become more usable. Some aspects of the current patch may change still - but the important part is getting the change to the events in. If that doesn't happen, I'm going to build this module on a forked ExternalAuth class.
- I'd also love to move parts of samlauth into externalauth so they can be made useful for more modules. (This would make the v4 code smaller even though no functionality gets lost.) I have my eye on:
- linking an existing user by name/e-mail
- the logic around locking the current e-mail/password elements on the user edit screen
- our UI for attribute synchronization and role assignment. (Part of it will need to be split into general base classes, and our own module can build on those to implement the SAML-attribute specific parts.)
- bits and pieces, e.g. flood control. (There isn't much general we can do there, but moving it into externalauth as example code means the other modules don't forget about it.)
In 2023 I wrote up a plan for doing the whole second point, in #3361544: Datahandler plugins, (optionally) mappable from login providers. This likely makes #3179148 obsolete. (I don't have buy-in from others yet though, so until I work on it / someone comments on it, both issues are open.) This means one of two things will likely happen, if anything:
- Instead of #3179148: Redo authmap_alter / register events., fork the ExternalAuth service (which implies not caring too much about future compatibility with externalauth module). When that is done, I can apply #2925171-14: Use externalauth::register event vs hook_user_presave, which un-spaghettifies this module's code considerably, and makes it easier to write tests.
- Rewrite externalauth per #3361544: Datahandler plugins, (optionally) mappable from login providers. This decreases this module's code considerably, and moves all the icky parts (fixed and tested) into externalauth.
Doing the first point is not ideal, but might happen if anyone 1) cares enough about un-spaghettifying this module's code / stopping to use hook_user_presave, 2) does not care that much about theoretical future externalauth compatibility; 3) agrees that the second point is just way too much work (even if it's better for other externalauth-using modules).
After this, we can pick up part 2 of #3202137: Write tests - or whatever part of that is still needed.
NOTE: Extensions of functionality can still be done in 3.x branch:
#3208564: Option to only sync fields on account creation/linking vs every login
Part 1 + 3 of #3202137: Write tests
---
Original issue text:
Release roadmap?
Hi,
Are there specific features or bugs that need to be completed before this module can be released (vs. an alpha release)?
Thanks!
Comments
Comment #2
roderikI'll roll a -beta1 once the under-review patches are committed. (Current estimate: next week. But don't count on my promises.)
A stable release will be done once all functionality has tests. This was a promise to the 1.x branch maintainer. I don't have a detailed view of what is needed there; will dive into testing as time allows.
Comment #3
becw commentedThanks for sharing the status!
Comment #4
pcambraAdding a few release candidates as related issues, maybe there are more that I've missed
Comment #5
damienmckennaStandardized the title.
Comment #6
roderikI'll wait for a little while to see what happens with #2900968: Attribute mapping module and then roll a beta.
Comment #7
nathandentzauHey roderik,
I can jump in and help with the unit/functional testing. Just let me know where I can start if you've already. Thanks!
Comment #8
roderikUpdate: I'm not rolling a beta yet since nathandentzau indicated the SamlService will need to be refactored a bit, to make it suitable for testing.
After that interface stabilizes, there may be a beta, or immediately an rc... depending on the test coverage I guess. I'll ping cweagans for opinions when we're there.
Comment #9
andypostThere's a number of patches already RTBC in queue (php 7.2 compatibility one of them)
Tests also needs setup for the new 3.x branch and clean-up of remains of simple test
Also it needs issue to create new alpha and plan beta before RC, personally we using ~6 patches on projects now
Comment #11
roderikThe low hanging fruit didn't hang as low as I expected. It increased my understanding of the SAML Toolkit's options though, so that's a plus.
I'm still doing the first subpoint; there are a few (1-3) issues left in the queue.
In the meantime, a new maintainer has appeared from an organization that wanted a release for the D9 issues now, so there's a new alpha release already.
Comment #12
roderikHere's the next iteration of my plan: (Note this is only my personal plan; so far the work on module 8.2.x and up has been ~95% un-funded, and if it stays that way / there is no considerable help, it will just be prioritized among any other paid and volunteer projects I have.)
Part 2 - path to "tested stable" version
1)
Work on externalauth issue #3179148: Redo authmap_alter / register events.. (Basic summary: basically 'noone' is using externalauth's events. I want to change them so they become more usable.) Write tests for it; get buy-in from other module users.
There may be more work I want to do on externalauth v2 first, if that means moving existing code from this module over to externalauth to make it more broadly usable by others, at the same time as making this module smaller. (I have my eye on the "link existing user by name / mail" part.)
Some aspects of the current patch may change still - but the important part is getting the change to the events in. If that doesn't happen, I'm going to build this module on a forked ExternalAuth class, because it makes the rest of the work that much easier/clearer.
2)
Apply #2925171-14: Use externalauth::register event vs hook_user_presave to make this module work on the new version of externalauth v2. This un-spaghettifies this module's code considerably, and makes it easier to test.
It also retires at least one event in this module (because we'll use externalauth's).
At the same time we're changing events, we can change the values passed into the event. The array of attributes should be replaced with a more fully formed value object (either the \OneLogin\Saml2\Auth object or something resembling it), so that event handlers can access more than just the attributes.
3)
Write automated tests for the rest of the module. After point 2 this becomes easier.
Release stable 4.x.
Part 1
In 2016 (!) when taking over the work toward 8.x-2.x, I promised to not release a stable version before it had proper automated tests.
However... the slow pace of this project combined with the large current user base (without many bug reports) points toward publishing a stable release for the current version, even though that doesn't have tests. I do not think the existence of that version will impede the 4.x release, whenever that will happen.
My plan is to properly handle all in-review issues before doing that. (There's not that many, but still: timeline unknown.)
Comment #13
roderik'Part 1' is done now. A 3.0-rc1 version has been released.
It would be great if you could test this version. a 3.0 release is planned a few weeks from now.
Comment #14
badrange commentedFriendly reminder: A stable release (even with missing features or known bugs) would be great because it would mean that the project is covered by the security advisory policy.
So a stable release with caveats could make many users sleep better at night..
Comment #15
roderikI coudn't tell you but we were actually in communication with the security team throughout the RC phase. It took a while, because of several dependencies.
(8.x-3.x wasn't security supported, but a reported issue was present in 8.x-1.3 which made it need an official security release.)
8.x-3.1 (security release) is out now, so everything is now also officially security supported.
Comment #16
badrange commentedThanks for the update, and thanks to everyone who responsibly worked on resolving this security issue and getting the fixes out!
Comment #17
roderikComment #18
roderikComment #19
roderik