Lock: React 16.9+ deprecated javascript urls warning

[wozzo]

Describe the problem

Using a Auth0Lock's show method leads to a javascript warning with React@^16.9.0 about deprecated javascript urls.
Caused by React: Deprecating javascript urls

What was the expected behavior?

No warning message

Reproduction

const lock = new Auth0Lock(auth0Options.clientID, auth0Options.domain, {
    autoclose: true,
    closable: false,
    allowSignUp: false,
    auth: {
        redirectUrl: auth0Options.redirectUri,
        responseType: auth0Options.responseType,
        params: {
            scope: auth0Options.scope
        }
    }
})

let redirect = redirectOveride ? redirectOveride : window.location.pathname + window.location.search
let options: any = {
    auth: {
        params: {
            state: redirect
        }
    }
}

lock.show(options)

Warning: A future version of React will block javascript: URLs as a security precaution. Use event handlers instead if you can. If you need to generate unsafe HTML try using dangerouslySetInnerHTML instead. React was passed "javascript:void(0)".
in a (created by QuickAuthPane)
in p (created by QuickAuthPane)
in div (created by QuickAuthPane)
in QuickAuthPane (created by Component)
in Component (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Child)
in div (created by Child)
in Child (created by Slider)
in span (created by Slider)
in Slider (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in div (created by Chrome)
in Chrome (created by Container)
in div (created by Container)
in form (created by Container)
in div (created by Container)
in div (created by Container)
in Container

Environment

Versions tested
"auth0-js": "^9.13.4",
"auth0-lock": "^11.26.3",
"react": "^16.13.1",

Tested in Firefox

Note

I had a quick look at the code and the warning I received appeared to be caused by the a element in the QuickAuthPane, but there are multiple places where javascript:void(0) is used.

[stevehobbsdev]

Thanks for raising @wozzo. We'll take it as a point to investigate but we have no plans to update the version of React being used. However, I appreciate that the warning is alarming. Let me look into what we can do to fix that.

[wozzo]

It looked to me look the anchor tags could be replaced with buttons, which would likely also be more semantically correct. But I'm not particularly familiar with your code base.

[stevehobbsdev]

Thanks @wozzo. To close the loop here, unfortunately at the moment we don't officially support React 16 and as mentioned have no plans to upgrade at this time. Appreciate you bringing this to our attention though. I've kept a note internally about this issue should we revisit those plans.

[brainwipe]

For those landing on this topic in the future:

This is not good enough. React 16 is 3 years old. You've been informed of an attack surface and choose to do nothing about it. We cannot have our identity provider opening an attack surface as facile as "javascript:" URLs.

I've raised a support ticket through the Auth0 system, this is enough of a problem to change identity provider.

[stevehobbsdev]

Thanks for raising concerns @brainwipe, I have raised this internally again for awareness.

[stevehobbsdev]

To circle back here, we have been reviewing this internally with the security team.

Besides the update to React 16 (which is a separate issue), we don't believe we are exposing an attack surface here. Yes, React has deprecated use of javascript: URLs in a future major version to prevent developers inadvertently opening a hole where unsanitized content could be written to the DOM and executed by a user. However, in this library, we're explicitly using javascript:void(0) in a small number of places and there is no chance that content could be dynamically injected in an unsafe way.

There are other users concerned about the practise of flagging such URLs as being a problem.

Having said that, I will raise some work internally to refactor out these URLs where possible to ease concerns.

[wozzo]

Is there a github issue for updating (or not) the version of react? What's the reasoning for deciding not to do so?
We will be continuing to keep the version of React and other packages we use up to date, which may necessitate moving to a different provider if it is not supported.

I would also consider the use of <a> tags to run javascript as an accessibility issue. They should be <button>s if they're not linking to a different page.

[stevehobbsdev]

I would also consider the use of tags to run javascript as an accessibility issue. They should be s if they're not linking to a different page.

We did used to have them as buttons but it caused issues with password managers such as LastPass not being able to function correctly. See: https://github.com/auth0/lock/pull/1760

Is there a github issue for updating (or not) the version of react? What's the reasoning for deciding not to do so?

Currently it's just not a priority compared to our roadmap for the rest of our surface area, which is large. The change we'd like to make is to make React a peer dependency so that you can roll with your own version of React, which would be a breaking change and require a new major version. Support then becomes trickier with trying to determine how we support version 11 for those customers, and a new version 12.

Not only that, it starts to get weird for those people not using React but some other framework - now a Vue developer has to also install React to get Lock to work?

Having said all that, we do recognise it as a pain point and I am discussing options. If there's any change, I'll let you know.

[frederikprijck]

We did used to have them as buttons but it caused issues with password managers such as LastPass not being able to function correctly. See: #1760

I think it would have helped to take the social buttons out of the form.
In terms of accessibility, I think a form should have one submit button, being the one to submit the user credentials.
Social buttons should live outside of the form, could be in a different form but I would argue they don't need to be a form at all.

This might be more complex, but that way lock would be more A11y compliant, both in terms of form usage as well as using buttons instead of a tags. This should also solve the integration issue with Lastpass I assume.