okta-signin-widget
okta-signin-widget copied to clipboard
okta
Uncaught TypeError: Cannot define property iterateEntries, object is not extensible
Describe the bug
Okta Signin Widget v7 using standard CDN bundle fails to render in MS Remote Help client (an embedded Webview2 browser with additional restrictions). Root cause, built-in Object() is not extensible. The Polyfill includes esnext.object.iterate-entries.js, esnext.object.iterate-keys.js, esnext.object.iterate-values.js attemt to extend 'Object' and subsequently "define-built-in.js:20 Uncaught TypeError: Cannot define property iterateEntries, object is not extensible" is thrown.
Reproduction Steps
Sign in to MS Remote Help client using Custom domain with V7 Okta Signin Widget enabled. Customized brand and login code but defaults in code editor.
SDK Versions
Using standard CDN bundle, currently 7.14.0. https://op1static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.14.0/js/okta-sign-in.min.js
Additional Information
By overriding {{{SignInWidgetResources}}} and explicitly including a bundle that does not include polyfill the error is avoided (at the expense of legacy support, and automatic version control). Similarly including the polyfill bundle separately allows the widget to render despite the error in the separately included script while maintaining legacy support (but still requiring manual version control).
I'm not completely sure what you're requesting. We do vend a widget bundle without polyfills: https://op1static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.14.0/js/okta-sign-in.no-polyfill.min.js, if that helps
I'm not completely sure what you're requesting. We do vend a widget bundle without polyfills: https://op1static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.14.0/js/okta-sign-in.no-polyfill.min.js, if that helps
It's a bug report, not a request. I would request the product works out of the box, with the intended legacy support and automatic version controls but in this circumstance it does not. Indeed the no-polyfill bundle may be used as a workaround as I have stated but manually including specific versions of specific bundles is not desirable. I would prefer {{{SignInWidgetResources}}} just worked out of the box.
By "legacy support" are you referring to Internet Explorer (via WV2)? Our IE support is achieved by polyfills
Yes, correct, the legacy support enabled in the standard bundle via polyfills. We're not quite ready to break old clients for the sake of this edge case. WebView2 is a modern Edge based browser (it doesn't need legacy support).
I see you have encountered this before and raised an issue with WebView2. I figured they had some reason to lock it down but it appears it's just sample code that found its way into production (Remote Help). This does not effect all WebView2 applications, as one must explicitly call the javascript function "Object.freeze(Object);" as is the case in the sample.
We have seen a similar error before, however those customers were using WV2 themselves, where your situation is using the SIW in an environment built on WV2 (which you do not control). Hopefully MS will fix things on their end, however we'll look into a solution on ours