GameNet
Active member
website URL: https://xen-shop.comNo idea what that is, so no. I’ve tested it with XenForo.
website URL: https://xen-shop.comNo idea what that is, so no. I’ve tested it with XenForo.
I will had to wait until I login on my computerHave you checked your browser console? Looks like there’s no JavaScript happening for whatever reason.
$config['challenge'] = \XF::generateRandomString(32);
lbuchs\WebAuthn
default code (32 bytes binary -> 256 bits entropy)?Relying Parties that wish to support a wide range of authenticators SHOULD include at least the following COSEAlgorithmIdentifier values:
- -8 (Ed25519)
- -7 (ES256)
- -257 (RS256)
The recommendation for RPs to support Ed2559 is new, but the requirement for browsers to support this was already in Level 2, so any semi up to date browser should be able to handle this by now.But ya... we'll see about Ed25519 in the future. Right now we are just talking about a draft proposal for a future version of WebAuthn (draft was published 11 days ago).
User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:
Well best way to get it supported if you need it would be to make a request with the author of the underlying library. I didn’t write it.The recommendation for RPs to support Ed2559 is new, but the requirement for browsers to support this was already in Level 2, so any semi up to date browser should be able to handle this by now.
If you aren't using XenForo 2.3, you don't need to upgrade (might be some unmeasurable speed increase [think nanoseconds] when running its JavaScript since it doesn't dip into...
- Entropy for challenge changed from 192-bits to 768-bits
- All JavaScript has been rewritten to be "native" (does not use jQuery) in preparation for removal of jQuery in XenForo 2.3.
Non-developer muggle type question here - If native Javascript is seemingly supported in addons pre-2.3, as opposed to jQuery - why is this such a big move for a lot of developers? Is it just preference in terms of developers using jQuery over native Javascript?digitalpoint updated [DigitalPoint] Security & Passkeys with a new update entry:
Removed dependency on jQuery
Read the rest of this update entry...
Because when you have written a ton of JavaScript code, it's time consuming to go back and rewrite it all. An (small) example is this was written for jQuery:Non-developer muggle type question here - If native Javascript is seemingly supported in addons pre-2.3, as opposed to jQuery - why is this such a big move for a lot of developers? Is it just preference in terms of developers using jQuery over native Javascript?
$(document).ready(function()
{
$('#cfRange input').on('change', this.analytics.bind(this))
$('#cfRange input:first-of-type').trigger('change');
}.bind(this));
document.addEventListener('DOMContentLoaded', () => {
document.querySelectorAll('#cfRange input').forEach(
(el) => {
el.addEventListener('change', (e) => {
this.analytics(e);
});
}
);
document.querySelector('#cfRange input').dispatchEvent(new Event('change'));
}, false);
So, often - in practice, writing jQuery is a lot faster (roughly 50% faster based on the line count alone above) than JS. Despite the way this is going with XF - As a developer, do you think going this direction is the best direction? Like - Does it make sense?Because when you have written a ton of JavaScript code, it's time consuming to go back and rewrite it all. An (small) example is this was written for jQuery:
JavaScript:$(document).ready(function() { $('#cfRange input').on('change', this.analytics.bind(this)) $('#cfRange input:first-of-type').trigger('change'); }.bind(this));
To not use jQuery, it needs to be rewritten like so:
JavaScript:document.addEventListener('DOMContentLoaded', () => { document.querySelectorAll('#cfRange input').forEach( (el) => { el.addEventListener('change', (e) => { this.analytics(e); }); } ); document.querySelector('#cfRange input').dispatchEvent(new Event('change')); }, false);
The end result is the code is usually a little less simple (jQuery simplifies a lot of things for you), but it works without jQuery.
...so now scale that small rewrite times 1000 when you have a ton of JavaScript written for jQuery...
Ya, it probably makes sense today. It didn't make sense years ago when you were needing to do different things for different browsers... But browsers are now (fairly) consistent across the board when it comes to JavaScript stuff. Back then, jQuery was a tool to so you could write code once and jQuery handled the browser-specific intricacies, but that's just not needed anymore. So now jQuery is more of a crutch for those that don't want to write "real" JavaScript vs. what it original was intended for (handling browser intricacies). So is the overhead of downloading an running a fairly large library (jQuery) worth developers being lazy? IMO, no... anytime you can cut bloat, it's good in my book.So, often - in practice, writing jQuery is a lot faster (roughly 50% faster based on the line count alone above) than JS. Despite the way this is going with XF - As a developer, do you think going this direction is the best direction? Like - Does it make sense?
Just interested is all. The payoff seems to be for the end user as a whole, and I guess that's the most important thing.
Makes sense. It's for the better and a necessary change then.Ya, it probably makes sense today. It didn't make sense years ago when you were needing to do different things for different browsers... But browsers are now (fairly) consistent across the board when it comes to JavaScript stuff. Back then, jQuery was a tool to so you could write code once and jQuery handled the browser-specific intricacies, but that's just not needed anymore. So now jQuery is more of a crutch for those that don't want to write "real" JavaScript vs. what it original was intended for (handling browser intricacies). So is the overhead of downloading an running a fairly large library (jQuery) worth developers being lazy? IMO, no... anytime you can cut bloat, it's good in my book.
It also got me thinking about some non-XenForo projects I have. Like I'm probably going to rewrite some JavaScript I have in WordPress plugins even though WordPress isn't deprecating jQuery. Better to not have to rely on 3rd party libraries for things if there's no real reason to any longer.
document.addEventListener("DOMContentLoaded", function() {
var inputs = document.querySelectorAll('#cfRange input');
for (var i = 0; i < inputs.length; i++) {
inputs[i].addEventListener('change', this.analytics.bind(this));
}
inputs[0].dispatchEvent(new Event('change'));
}.bind(this));
Ya, there are different ways it could be done. Since I'm rewriting code anyway, I'm also migrating to the newer arrow functions in JavaScript vs. anonymous functions because the scoping and needing to doMakes sense. It's for the better and a necessary change then.
Out of interest, I just sent your original jQuery code through Bing AI and asked it to convert to JS. This is the output -
JavaScript:document.addEventListener("DOMContentLoaded", function() { var inputs = document.querySelectorAll('#cfRange input'); for (var i = 0; i < inputs.length; i++) { inputs[i].addEventListener('change', this.analytics.bind(this)); } inputs[0].dispatchEvent(new Event('change')); }.bind(this));
Mostly different. Not sure if this would be valid or work? It provides an explanation, too -
'This code does the same thing as your jQuery code. It waits for the document to load, then it adds an ‘change’ event listener to each input element within the element with the id ‘cfRange’. It also triggers the ‘change’ event on the first input element within ‘cfRange’.'
.bind(this)
gets really convoluted and annoying when dealing with large classes. I'm also not a big fan of writing to variables for no reason other than to make the overall code smaller. The closure compiler that turns human readable JavaScript into minified versions handles all that for you if needed (that's why I'm not dumping everything into input variable and looping through that) and in the end (what users are downloading) ends up being the same either way.MS Edge for Android. Current build (dunno its numbers)As long as 1password supports WebAuthn/FIDO2, it should work (it’s just a standard protocol). Although I would think it needs to be supported by the browser itself rather than an app since the browser is doing the underlying “stuff”.
What browser/version are you using?
We use essential cookies to make this site work, and optional cookies to enhance your experience.