Variable "authURL" does not exist.

[northway]

Hi!

I wanted to test this module, but I'm having some hard time to make it work.

• My SSP is on v1.19.3 and I used the simplesamlphp/simplesamlphp-module-webauthn:dev-ssp_119 branch as it was told in another issue.
• The usenewui is enabled as well.
• MySQL database is configured and accessible.

After authenticating against LDAP, this error message comes up:

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
2 www/_include.php:17 (SimpleSAML_exception_handler)
1 vendor/symfony/error-handler/ErrorHandler.php:607 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
0 [builtin] (N/A)
Caused by: SimpleSAML\Error\Exception: Variable "authURL" does not exist in webauthn:authentication.twig
Backtrace:
2 lib/SimpleSAML/XHTML/Template.php:526 (SimpleSAML\XHTML\Template::getContents)
1 lib/SimpleSAML/XHTML/Template.php:541 (SimpleSAML\XHTML\Template::send)
0 www/module.php:10 (N/A)
Caused by: Twig\Error\RuntimeError: Variable "authURL" does not exist.
Backtrace:
16 modules/webauthn/templates/authentication.twig:11 (__TwigTemplate_d64916ea74048e17647defc399f751abce897cf5ac5feb077dd78fd1c4185e71::{closure})
15 vendor/twig/twig/src/Environment.php(418) : eval()'d code:74 (__TwigTemplate_d64916ea74048e17647defc399f751abce897cf5ac5feb077dd78fd1c4185e71::block_content)
14 vendor/twig/twig/src/Template.php:182 (Twig\Template::displayBlock)
13 vendor/twig/twig/src/Environment.php(418) : eval()'d code:145 (__TwigTemplate_3dfe04f2fd186db7150dd88d40a810ba1369757731f3072d453f87c8e1101d6a::block_contentwrapper)
12 vendor/twig/twig/src/Template.php:182 (Twig\Template::displayBlock)
11 vendor/twig/twig/src/Environment.php(418) : eval()'d code:100 (__TwigTemplate_3dfe04f2fd186db7150dd88d40a810ba1369757731f3072d453f87c8e1101d6a::doDisplay)
10 vendor/twig/twig/src/Template.php:405 (Twig\Template::displayWithErrorHandling)
9 vendor/twig/twig/src/Template.php:378 (Twig\Template::display)
8 vendor/twig/twig/src/Environment.php(418) : eval()'d code:46 (__TwigTemplate_d64916ea74048e17647defc399f751abce897cf5ac5feb077dd78fd1c4185e71::doDisplay)
7 vendor/twig/twig/src/Template.php:405 (Twig\Template::displayWithErrorHandling)
6 vendor/twig/twig/src/Template.php:378 (Twig\Template::display)
5 vendor/twig/twig/src/Template.php:390 (Twig\Template::render)
4 vendor/twig/twig/src/TemplateWrapper.php:45 (Twig\TemplateWrapper::render)
3 vendor/twig/twig/src/Environment.php:318 (Twig\Environment::render)
2 lib/SimpleSAML/XHTML/Template.php:524 (SimpleSAML\XHTML\Template::getContents)
1 lib/SimpleSAML/XHTML/Template.php:541 (SimpleSAML\XHTML\Template::send)
0 www/module.php:10 (N/A)

My module config:

``` $config = [ /* Enable/disable Debug made */ 'debug' => true, /* required configuration parameters */ 'store' => [ 'webauthn:Database', 'database.dsn' => 'mysql:host=REDACTED;dbname=REDACTED', 'database.username' => 'REDACTED', 'database.password' => 'REDACTED', ], // eppn 'attrib_username' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', // displayName 'attrib_displayname' => 'urn:oid:2.16.840.1.113730.3.1.241', /* optional configuration parameters */ /* FIDO2 is phishing-resistent by binding generated credentials to a scope. * Browsers will only invoke the registration/authentication if the scope * matches the principal domain name the user is currently visiting. * If not specified, the scope will be the hostname of the IdP as per * its metadata. It is permissible to widen the scope up to the prinicpal * domain though (e.g. authentication service is "saml.example.com" => scope * can be extended to "example.com"; but not "examp1e.com". A registered * FIDO2 token can then also be used on other servers in the same domain. * If configuring this item, be sure that the authentication server name and * the desired scope are a suffix match. * * If you do not control the entirety of your second-level domain, you must * set the scope here explicitly to your own hostname to prevent some * contrived attack scenarios with other servers in that same second-level * domain. */ 'scope' => 'eduid.hu', /* the following will interactively ask the user if he is willing to share * manufacturer and model information during credential registration. * The user can decline, in which case registration will still succeed but * vendor and model will be logged as "unknown model [unknown vendor]" * * When not requesting this, there is one less user interaction during the * registration process; and no model information will be saved. * * defaults to "false" */ 'request_tokenmodel' => false, /* should FIDO2 be enabled by default for all users? If not, users need to * be white-listed in the database - other users simply pass through the * filter without being subjected to 2FA. * * defaults to "disabled by default" === false */ 'default_enable' => true, /* this parameter is used only if "use_database" is false. If the value of * "force" is true then we trigger WebAuthn only if "attrib_toggle" from the * user is not empty. If the value of "force" is false then we switch the value of * "default_enable" only if "attrib_toggle" from the user is not empty. * Default falue is true. */ 'force' => true, /* this parameter stores the name of the attribute that is sent with user and which * determines whether to trigger WebAuthn. * Default value is 'toggle' */ 'attrib_toggle' => 'toggle', /* this parameter determines if the database will be used to check * whether to trigger second factor authentication or use the "attrib_toggle" instead. * Default value of this attribute is true */ 'use_database' => true, /* optional parameter which determines whether you will be able to register and manage tokens * while authenticating or you want to use the standalone registration page for these * purposes. If set to false => standalone registration page, if true => inflow registration. * Defaults to true. */ 'use_inflow_registration' => true, /* optional parameter that determines what auth source will be used in standalone registration page. * Defaults to 'default-sp'. */ 'registration_auth_source' => 'default-sp', ```

[tvdijen]

Hi @northway ! Thanks for reporting this.. I've proposed a fix for this.. Could you try to manually apply it and see if it works?

[northway]

Of course!

[northway]

Okay, so the error message is gone.

Now it's just stuck here. No error in the logs or in the inspector...

.

[tvdijen]

OK, then clearly this is not the appropriate fix.. Needs further investigation

[tvdijen]

Please give v0.11 a try... I'm not sure why you were told to use a dev-branch...

[northway]

Okay I switched it over to v0.11.0 and a new problem came up. I tried it in all the major browsers.

Should I create another issue for this?

[restena-sw]

This looks unrelated indeed. Please open another issue and look at the Exception that was raised, to find possible reasons for this.

[tvdijen]

We should either fix the first issue or remove the ssp_119 branch

[tvdijen]

I've removed both the ssp_119 and the release-1.0.x branch... The 0.11 branch is working properly and the ssp_119 had problems that were already fixed in the release-branches... The release-1.0.x branch puzzled me, because all of the 1.0.x-tags we have were pointing to master.. Let's keep master the one branch to work against the future SSP 2.0..