Requirement on simplesamlphp:dev-master

[imrejonk]

Hi, and thanks for developing this module.

Since version v1.0, the simplesamlphp-module-webauthn PHP package requires the 'dev-master' version of simplesamlphp. I'm currently on dev-release-0.9, which requires simplesamlphp:^1.18.2. Trying to update to v1.0 or higher results in this fatal Composer error:

Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for simplesamlphp/simplesamlphp-module-webauthn v1.0.2 -> satisfiable by simplesamlphp/simplesamlphp-module-webauthn[v1.0.2].
    - simplesamlphp/simplesamlphp-module-webauthn v1.0.2 requires simplesamlphp/simplesamlphp dev-master -> satisfiable by simplesamlphp/simplesamlphp[dev-master] but these conflict with your requirements or minimum-stability.

Installation failed, reverting ./composer.json to its original content.

I'd rather not change the minimum-stability setting in my composer.json if it's not necessary. Would it be possible to require a stable release of simplesamlphp again, instead of dev-master?

[restena-sw]

Yes, we've recently (hours ago) merged changes for the upcoming simpleSAMLphp 2.0 into master here, which created this bit of a mess.

I'll create a new ssp_119 branch soon which will revert to requiring 1.19 instead of dev-master.

I'm not sure which of the changes we merged are backwards compatible to 1.19 vs. truly requiring master. So when I tag that version, I'd ping you to test it please.

[restena-sw]

Can you try using branch ssp_119? I branched it off before the more aggressive changes we did yesterday. Can't guarantee it is 100% smooth, but am available to debug and tag once things are working.

[tvdijen]

@restena-sw The 1.0.1 and 1.0.2 releases should have never been released... They aim at SSP master and should have been 2.0-x beta releases. v1.0.0 should work fine on 1.18 / 1.19

[restena-sw]

That's true, apologies. FWIW, I'll make 1.0.3 out of this branch so the previous versions become historic. New versions from master will be tagged 1.1-beta.

(v1.0 was already aiming at dev-master)

[imrejonk]

Can you try using branch ssp_119? I branched it off before the more aggressive changes we did yesterday. Can't guarantee it is 100% smooth, but am available to debug and tag once things are working.

I installed SimpleSAMLphp 1.19.0 and then tried to install this branch using Composer:

composer require simplesamlphp/simplesamlphp-module-webauthn:dev-ssp_119

Unfortunately this failed and spewed out a lot of text that wasn't very helpful in trying to find the root cause. Something about an unknown package :confused:. I've pasted the composer output here.

My PHP version: 7.3.19-1~deb10u1 My Composer version: 1.8.4-1

Please let me know if there's something else I can test.

[tvdijen]

I've never seen Composer outputting something like this.. Can you run it with -vvv flag? That should get us more details, but I'm tempted to say this is a local issue..

[imrejonk]

@tvdijen this indeed looks like a local issue, it turns out that any Composer command fails while I'm working on the SimpleSAMLphp 1.19.0 installation (but not on 1.18.8). I guess that my Composer version is just too old and SimpleSAMLphp has dropped support for it. I'll try upgrading to a newer version.

If you're interested, this is the exception trace produced by composer -vvv:

Exception trace:
 () at /usr/share/php/Composer/Package/Loader/ArrayLoader.php:44
 Composer\Package\Loader\ArrayLoader->load() at /usr/share/php/Composer/Repository/FilesystemRepository.php:63
 Composer\Repository\FilesystemRepository->initialize() at /usr/share/php/Composer/Repository/ArrayRepository.php:185
 Composer\Repository\ArrayRepository->getPackages() at /usr/share/php/Composer/Plugin/PluginManager.php:256
 Composer\Plugin\PluginManager->loadRepository() at /usr/share/php/Composer/Plugin/PluginManager.php:76
 Composer\Plugin\PluginManager->loadInstalledPlugins() at /usr/share/php/Composer/Factory.php:384
 Composer\Factory->createComposer() at /usr/share/php/Composer/Factory.php:576
 Composer\Factory::create() at /usr/share/php/Composer/Console/Application.php:345
 Composer\Console\Application->getComposer() at /usr/share/php/Composer/Console/Application.php:458
 Composer\Console\Application->getPluginCommands() at /usr/share/php/Composer/Console/Application.php:156
 Composer\Console\Application->doRun() at /usr/share/php/Symfony/Component/Console/Application.php:148
 Symfony\Component\Console\Application->run() at /usr/share/php/Composer/Console/Application.php:104
 Composer\Console\Application->run() at /usr/bin/composer:57

[tvdijen]

Nah, composer V1 should be just fine for SSP 1.19... It seems like you're ending up with some incompatible combination of PHP version & Symfony.. Which is weird, because the lock-file was created with PHP 7.1

[tvdijen]

Also, this can in no way be the only output of composer... You're leaving the important stuf out (like the source of the exception)

[restena-sw]

I just used the SSP 1.19.0 tarball and did a "composer require simplesamlphp/simplesamlphp-module-webauthn dev-ssp_119" and that checked out the source without any issues. I really think that you have a local issue on your box there.

However: after doing that I deployed the branch. There a couple of things I had to revert from master and now I think I'm close to having a working state. There is one error message that reads rather miraculous to me. I would think @tvdijen knows what this is about...

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION Backtrace: 2 /export/hosting/restena/clueless/htdocs/simplesamlphp/_include.php:17 (SimpleSAML_exception_handler) 1 vendor/symfony/error-handler/ErrorHandler.php:588 (Symfony\Component\ErrorHandler\ErrorHandler::handleException) 0 [builtin] (N/A) Caused by: InvalidArgumentException: The controller for URI "/webauthn/webauthn" is not callable: Controller "SimpleSAML\Module\webauthn\Controller\WebAuthn" has required constructor arguments and does not exist in the container. Did you forget to define the controller as a service? Backtrace: 5 vendor/symfony/http-kernel/Controller/ControllerResolver.php:88 (Symfony\Component\HttpKernel\Controller\ControllerResolver::getController) 4 vendor/symfony/http-kernel/HttpKernel.php:141 (Symfony\Component\HttpKernel\HttpKernel::handleRaw) 3 vendor/symfony/http-kernel/HttpKernel.php:80 (Symfony\Component\HttpKernel\HttpKernel::handle) 2 vendor/symfony/http-kernel/Kernel.php:201 (Symfony\Component\HttpKernel\Kernel::handle) 1 lib/SimpleSAML/Module.php:198 (SimpleSAML\Module::process) 0 /export/hosting/restena/clueless/htdocs/simplesamlphp/module.php:10 (N/A)

Any chance this has a quick fix in the ssp_119 branch?

[tvdijen]

Can't reproduce this issue.. However, I've noticed that you've checked out the ssp_119 branch in the wrong point in time, because there are no www-scripts in there. This means it can only work with the experimental usenewui=true..

[tvdijen]

I did see this error on other modules and in my case it appeared to be some weird kind of caching mechanism... You can try to restart httpd/php-fpm, move to another module (ie the admin module) and then move back to the page your trying to open in the webauthn module.

[restena-sw]

It keeps happening across web server restarts, php-fpm restarts, new browser sessions.

Maybe it's best to make a release out of dev-0.9. It misses out on recent enhancements, but it works.

[tvdijen]

OK, it's a long shot, but what happens if you run another composer install and npm run build? It's so hard to debug when I can't reproduce the issue...

[restena-sw]

Okay... I've never had to deal with npm, and happily so. Still, I ran this, it didn't work, and I hope you can make something out of it. If not, tagging a release out of dev-0.9 becomes more and more attractive...

stefan@pegasus:~/RESTENA/Development/simplesamlphp-1.19.0> npm run build

simplesamlphp@ build /home/stefan/RESTENA/Development/simplesamlphp-1.19.0 webpack -p

/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/node_modules/p-limit/index.js:29 } catch {} ^

SyntaxError: Unexpected token { at NativeCompileCache._moduleCompile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:242:18) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:186:36) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/dist/index.js:18:38) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/dist/cjs.js:3:16) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/webpack.config.js:4:27) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! simplesamlphp@ build: webpack -p npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the simplesamlphp@ build script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in: npm ERR! /home/stefan/.npm/_logs/2021-01-29T11_15_13_405Z-debug.log

[tvdijen]

Ah, my bad.. you have to run npm install prior to running npm run build

[restena-sw]

That didn't change a thing, both commands below.

pegasus:/home/stefan/RESTENA/Development/simplesamlphp-1.19.0 # npm install npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.1 (node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.1: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 696 packages in 2.868s

23 packages are looking for funding run npm fund for details

found 1 low severity vulnerability run npm audit fix to fix them, or npm audit for details pegasus:/home/stefan/RESTENA/Development/simplesamlphp-1.19.0 # npm run build

simplesamlphp@ build /home/stefan/RESTENA/Development/simplesamlphp-1.19.0 webpack -p

/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/node_modules/p-limit/index.js:29 } catch {} ^

SyntaxError: Unexpected token { at NativeCompileCache._moduleCompile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:242:18) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:186:36) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/dist/index.js:18:38) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/copy-webpack-plugin/dist/cjs.js:3:16) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) at Module.require (module.js:597:17) at require (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:161:20) at Object. (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/webpack.config.js:4:27) at Module._compile (/home/stefan/RESTENA/Development/simplesamlphp-1.19.0/node_modules/v8-compile-cache/v8-compile-cache.js:194:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! simplesamlphp@ build: webpack -p npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the simplesamlphp@ build script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2021-01-29T11_20_51_030Z-debug.log pegasus:/home/stefan/RESTENA/Development/simplesamlphp-1.19.0 #

[tvdijen]

Must have something to do with your version of npm or node.. What's the output for npm -v and node -v?

[restena-sw]

pegasus:/home/stefan/RESTENA/Development/simplesamlphp-1.19.0 # npm -v 6.13.4 pegasus:/home/stefan/RESTENA/Development/simplesamlphp-1.19.0 # node -v v8.17.0

[tvdijen]

I bet it's the node.. I think v9 or even v10 was required

[restena-sw]

Okay, now have 14 and it's happily doing its something. Forgive my ignorance: now that this is complete - what should I do?

[tvdijen]

You've just rebuilt the assets and I'm still hoping it somehow solved the controller error..

[tvdijen]

Ok, so I've created a new release-1.0.x branch based on a checkout of v1.0, fixed it so it depends on SSP ^1.18 instead of master and moved the 1.0.0 tag there.. This version should work with SSP 1.18 and 1.19.

Next thing I want to do is remove the 1.0.1 and 1.0.2 tags, create a release-1.1.x branch and start over with the controllers vs www-scripts and tag it v1.1.0 as soon and I have that working.

Next step then would be to upgrade the dependencies in a release-1.2.x branch

If all that is working, it's like to force-push that 1.2-branch over master so we have everything back on track again. Is that okay with you @restena-sw ?

[restena-sw]

Well, sure, very happy if you can take this up. And apologies for starting the mess in the first place. I simply didn't realise that master is depending on dev-master for such a very long time already :-(

[tvdijen]

Actually v1.0.0 isn't working on SSP 1.18/1.19 as well :(

[tvdijen]

I think I'm gonna have to give up, because I can't even get the v1.0.0 to work.. Has this module ever worked? I've tried setting it up with SSP 1.18, only configured a database and a attrib_user.. I access an SP, get redirected to the IDP and end up with a SSP page that only has the text 'Two factor authentication'... Nothing more..

[tvdijen]

@restena-sw I've had some help from our Spanish friends and could restore the release-0.9 branch (going back to Feb 21 2020) that has been known to work with SSP 1.18... I'm trying to set up a working copy right now, but I'm stuck.. Browser console reporting 'insecure operation'.

[restena-sw]

Funny thing is I use the code in production, without issues. From a state preceding all the T&I sprints. Next week I will do a diff to what we have.

[tvdijen]

I expect this to be an issue on my install regarding CSP-headers or something like that.. I tried to exclude this, but it made no difference so far

[restena-sw]

Just a thought about your "insecure operation": WebAuthN is spec'ed to work exclusively on HTTPS. If your test setup is on plain HTTP, this is an expected error.

Similarly, the "scope" in module config has to match the hostname or second-level domain of your deployment.

[tvdijen]

Everything is on HTTPS, so that's not the issue.. I didn't have a scope set, but explicitly setting it to my hostname didn't help... I feel like we're closing in on the issue though..

[tvdijen]

I'm one step further now.. I had the scope set on the authproc instead of in a module_webauth.php file.. That's something we should fix in the docs.. Now I'm being asked for my token, I plug it in, use the pincode and touch the key, and then I end up on the regprocess.php with a lot of raw data

[restena-sw]

I see the debug mode changes etc. so I guess this means things are stabliising. Just let me know when I should test the code in its current state.

[tvdijen]

The 0.9.x and 0.10.x branches are working just fine, but I have found one issue with the inflow_registration=false mode. When you break out to the registration page, register a token and then press the 'Authenticate' button, it is trying to pick up the original authentication-flow (because it still knows about this in the state).. It's trying to proceed with the authproc-chain and fails

[tvdijen]

I see you're not on our Slack channel... I'm also discussing this all with Sergio and Francisco.. Perhaps you can join us there?

[imrejonk]

I did some more testing with Composer and SSP 1.19.0. The issue I had before is not just some local issue, I've had it with a different (Debian) box and also a Debian 10 container as well. I'm certain that it is caused by SSP 1.19.0 dropping support for Symfony 3.x. Debian 10 comes with Symfony 3.4.

I'm looking for a way to get SSP 1.19.0 running on Debian 10. Maybe I'll backport the symfony packages or something. Until then I won't be able to properly test the webauthn module with SSP 1.19.0. I have also opened a feature request for bringing back support for Symfony 3.4.

The current release tags of this module are a bit confusing right now. Have the 1.x releases been revoked? If so, can you remove the releases from Packagist? I think it would be best to not recycle the 1.0.0, 1.0.1 and 1.0.2 releases in the future. Maybe you can prevent those tags from being pushed again by blacklisting them in GitHub somewhere?

I just tested v0.10.0 (the latest release) with SSP 1.18.8. It works perfectly, thanks for all the effort.

[restena-sw]

Happy to join the Slack, of course. Can you send me an invite?