213595 2020-06-25 05:30:47 -0700 [WebAuthn] Use MediaOnly user gesture 2021-02-04 11:13:37 -0800 1 1 1 Unclassified WebKit WebKit Misc. Safari Technology Preview All All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=214444 InRadar P2 Normal --- 181943 1 ynojima jiewen_tan aric bart.dewater bfulgham billylo1 bojan david ionescuac jiewen_tan levonkarapetyan matthew me Michael.peng ofirschwartz paul.mcnamara peterlohse teodor.atroshenko thefatbloke vganesh webkit-bug-importer oldest_to_newest 1666017 0 ynojima 2020-06-25 05:30:47 -0700 Congratulations for Touch ID/Face ID support! I really appreciate your efforts. I found Safari restricts Touch ID/Face ID usage only within user activated events (Security keys are not restricted). It seems reasonable regulation at first glance, but it also restricts calling WebAuthn within a callback of promise based asynchronous API. Here is a pseudo code that Touch ID/Face ID is not available for registration: ``` someElement.onclick = function(){ var optionsRequest = { // set some parameters }; fetch('http://example.com/webauthn/attestation/options', { method: "POST", body: JSON.stringify(optionsRequest) }) .then(function(response) { var options = generateOptionsFromServerResponse(response); return navigator.credentials.create(options); // WebAuthn is not directly called by user activated event }); } ``` Calling REST API before navigator.credentials.create.get invocation to fetch options parameters like challenge and credentialId(s) are common pattern in many sites (ex. google.com, webauthn.io), and defined practices in FIDO document [1]. What is the objective of this restriction? I assumed it is a guard for unintended Touch ID/Face ID sensor activation, but there is a dialog asking for user consent before activating the sensors. It seems it's a sufficient guard. As far as I know, restricting local authenticators to user activated events are not defined in WebAuthn specification. I suppose the restriction should be removed, or extend the allowed scope to promise callback chain to improve user experience. [1] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-server-v2.0-rd-20180702.html 1666272 1 ynojima 2020-06-25 16:31:53 -0700 I heard mandating user gesture is not scandalized in W3C WebAuthn spec. https://github.com/w3c/webauthn/issues/1293 1666274 2 jiewen_tan 2020-06-25 16:35:04 -0700 User activated event is required to use Face ID and Touch ID. This is part of the design of the platform authenticator itself. It has nothing to do with WebAuthn API part. 1666284 3 ynojima 2020-06-25 16:54:16 -0700 I see, but callback of promise chain originally activated by user event should be allowed at least. ( Not sure how hard it is) As stated before, it restricts fetching option data like challenge and credentialId(s) before neavigator.credentials.create/.get call, which is a common pattern in relying party implementations. 1666536 4 bojan 2020-06-26 12:14:44 -0700 @Jiewan Tan, if this doesn't get fixed, it will essentially make WebAuthn unusable by any relying parties. The user activated event will still be the providing of Touch ID or Face ID. There are zero WebAuthn implementations that currently work using the current implementation because there is a server request required to retrieve the challenge for the options request. 1666601 5 paul.mcnamara 2020-06-26 14:10:48 -0700 Likewise it's great to see some real progress with WebAuthn on iOS. I agree with the other posters though - this will break our implementation and likely many others. Would it not make more sense to simply have a native consent UI when "platform" is requested? Confirmation of this would meet the user activated requirement would it not? If the goal is to prevent nuisance popup UIs then it's currently inconsistent as you still get one if create/get are not called from within a user-activated event handler. No other browser implementations (including OSX Safari using the touchbar) work this way to my knowledge. 1667212 6 bart.dewater 2020-06-29 11:57:00 -0700 This really confused me as well. I tried Shopify, GitHub and https://github.com/cedarcode/webauthn-rails-demo-app and none of them prompted me to use TouchID as I expected after upgrading to iPadOS 14. Only https://webauthn.me/debugger works as expected because it's a demo using client-side generated challenges. 1667626 7 webkit-bug-importer 2020-06-30 11:02:31 -0700 <rdar://problem/64946612> 1668103 8 jiewen_tan 2020-07-01 17:01:13 -0700 Hi Developers, Removing the user gesture requirement unfortunately is not an option. The benefit of it is probably not obvious at the current stage. However as you could have imagined, the UI could evolve into a more streamlined version in the future that will certainly be beneficial by this hard requirement. At the same time, we are considering improvement over the user gesture mechanism, like things in User Activation API that could let the user gesture bit being carried through the promise chain. However, such thing doesn't exist in WebKit yet. Implementing such improvement will take quite some time, and the improvement will probably not be shipped soon. Therefore, I suggest you could prefetch the nonce before the user action as a solution for now. 1669008 9 thefatbloke 2020-07-06 02:44:22 -0700 Just adding my disappointment to this thread. This approach breaks our implementation too. This will be perceived as Apple going their own way and perverting open standards as they did with the recent OpenId Connect/Sign in with Apple debacle. https://openid.net/2019/06/27/open-letter-from-the-openid-foundation-to-apple-regarding-sign-in-with-apple/ Please Apple, review this restriction. 1669556 10 ionescuac 2020-07-07 15:17:42 -0700 I also would like to express my disappointment in this decision. By requiring websites to update their ordering of REST calls leaves a poor user experience when they wonder why they can login into one website with WebAuthn, but not in another, when in reality it should work with both websites. Why is it not possible to show a consistent dialog, such as Apple Pay which requires user consent to trigger authentication by a new fingerprint touch or double tap to activate Face ID scan and preserve existing behavior? 1672398 11 404536 jiewen_tan 2020-07-16 21:59:56 -0700 Created attachment 404536 Patch 1672549 12 404536 bfulgham 2020-07-17 10:58:45 -0700 Comment on attachment 404536 Patch r=me 1672551 13 bfulgham 2020-07-17 11:00:08 -0700 For those following along on this radar, we have revised the handling of user gesture to follow the model of our media gesture requirements. This should resolve many of the concerns raised in this thread. It is helpful to have specific examples of cases where you find the user gesture to be a problem so we can review and see if we can find a path forward that complies with the requirements of our Local Authentication features on our devices. 1672553 14 ionescuac 2020-07-17 11:13:41 -0700 https://webauthn.io/ is a good website to test with where this bug is triggered. You can also create a free Okta tenant at https://developer.okta.com and test there as well. 1672578 15 jiewen_tan 2020-07-17 12:15:44 -0700 This patch should have resolved issues with XHR, but not Fetch API. Bug 214444 is tracking the progress of Fetch API. 1672580 16 404536 jiewen_tan 2020-07-17 12:16:34 -0700 Comment on attachment 404536 Patch Thanks Brent for r+ this patch. 1672582 17 ews-feeder 2020-07-17 12:30:28 -0700 Committed r264528: <https://trac.webkit.org/changeset/264528> All reviewed patches have been landed. Closing bug and clearing flags on attachment 404536. 1672725 18 jiewen_tan 2020-07-17 16:41:30 -0700 (In reply to Alex from comment #14) > https://webauthn.io/ is a good website to test with where this bug is > triggered. > You can also create a free Okta tenant at https://developer.okta.com and > test there as well. Confirmed this fix works for the first website. For the second one, it's not obvious for me where I could register the platform authenticator. 1672749 19 ionescuac 2020-07-17 17:27:20 -0700 Honestly if it works with that website you should be good to go, but here is how you would enable it on Okta. Login to your developer okta tenant with username & password. If you see Developer Console in the top left of the page, click it and select Classic UI to switch. Then under Security --> MultiFactor you can enable WebAuthn as available for your tenant. Afterwards, leave the Okta admin portal and go back to the user profile page. You'll be able to enroll the factor there. 1672808 20 vganesh 2020-07-18 11:01:56 -0700 Which iOS release would this be available in? Will it be in beta3? 1694722 21 billylo1 2020-10-05 09:17:40 -0700 (In reply to Jiewen Tan from comment #18) > (In reply to Alex from comment #14) > > https://webauthn.io/ is a good website to test with where this bug is > > triggered. > > You can also create a free Okta tenant at https://developer.okta.com and > > test there as well. > > Confirmed this fix works for the first website. For the second one, it's not > obvious for me where I could register the platform authenticator. Hi, Jiewen: which iOS/Safari version did you use for verification? Would like to replicate it for our site too. thx. 1694756 22 jiewen_tan 2020-10-05 10:56:38 -0700 (In reply to Billy Lo from comment #21) > (In reply to Jiewen Tan from comment #18) > > (In reply to Alex from comment #14) > > > https://webauthn.io/ is a good website to test with where this bug is > > > triggered. > > > You can also create a free Okta tenant at https://developer.okta.com and > > > test there as well. > > > > Confirmed this fix works for the first website. For the second one, it's not > > obvious for me where I could register the platform authenticator. > > Hi, Jiewen: which iOS/Safari version did you use for verification? Would > like to replicate it for our site too. thx. iOS 14 and macOS Big Sur beta. 1701297 23 aric 2020-10-25 09:03:35 -0700 Version 14.0 (14610.1.28.1.10) 10.14.6 (18G6032) MacBook Pro (15-inch, 2019) As far as I can tell this issue remains. Safari always prompts for security key, never Touch ID. Sites tested: webauthn.me webauthn.io 1701595 24 jiewen_tan 2020-10-26 13:35:45 -0700 (In reply to Aric from comment #23) > Version 14.0 (14610.1.28.1.10) > 10.14.6 (18G6032) > MacBook Pro (15-inch, 2019) > > As far as I can tell this issue remains. > Safari always prompts for security key, never Touch ID. > > Sites tested: > webauthn.me > webauthn.io Do you check isUVPAA? Touch ID won't work on any macOS before Big Sur. 1704210 25 Michael.peng 2020-11-03 14:13:47 -0800 Hi Jiewen Tan, we've noticed a couple of things: 1) TouchID prompt is not seen when WebAuthn API is invoked as a result of event trigger. e.g. Button is clicked + API call is made to backend to get challenge and on success we trigger an event. Then, event listener calls credentials.create. Can we fix this? 2) Today, to avoid many clicks we programatically trigger credentials.get as soon as user lands on the WebAuthn screen in login flow. Chrome allows it on MacOS and doesn't filter TouchID. Is Safari going to fix this to have the same behavior, or do we need to have an explicit click from the user triggering the WebAuthn prompt? Just trying to understand what the direction is, and the degree of user interaction required. Thank you very much for your time and help! 1704225 26 jiewen_tan 2020-11-03 14:49:23 -0800 (In reply to Michael from comment #25) > Hi Jiewen Tan, we've noticed a couple of things: > > 1) TouchID prompt is not seen when WebAuthn API is invoked as a result of > event trigger. > e.g. Button is clicked + API call is made to backend to get challenge and on > success we trigger an event. > Then, event listener calls credentials.create. > Can we fix this? Can you be more specific? Can you file another bug and upload your test case? > 2) Today, to avoid many clicks we programatically trigger credentials.get as > soon as user lands on the WebAuthn screen in login flow. Chrome allows it on > MacOS and doesn't filter TouchID. Is Safari going to fix this to have the > same behavior, or do we need to have an explicit click from the user > triggering the WebAuthn prompt? Just trying to understand what the direction > is, and the degree of user interaction required. For us, it's going to require user interactions. > > Thank you very much for your time and help! 1704622 27 Michael.peng 2020-11-04 15:03:14 -0800 Hi Jiewan, thanks for your quick reply. Understood on the user interaction requirement. We can create a separate issue later with a js fiddle or similar example implementation to illustrate the callback issue. 1705685 28 levonkarapetyan 2020-11-09 03:35:07 -0800 Hi, I have noticed that when the geolocation API is used between user click and WebAuthn call, then Safari on iOS 14 restricts Touch ID/Face ID usage. I'd like to know whether this is also a bug or the expected behavior. Here is a code example: document.getElementById("mybutton").onclick = function() { navigator.geolocation.getCurrentPosition(register, register); } function register() { var options = {...}; navigator.credentials.create({ publicKey: options }) .then(console.log) .catch(console.error); } 1705799 29 jiewen_tan 2020-11-09 11:54:14 -0800 (In reply to Levon Karapetyan from comment #28) > Hi, > > I have noticed that when the geolocation API is used between user click and > WebAuthn call, then Safari on iOS 14 restricts Touch ID/Face ID usage. I'd > like to know whether this is also a bug or the expected behavior. > > Here is a code example: > document.getElementById("mybutton").onclick = function() { > navigator.geolocation.getCurrentPosition(register, register); > } > > function register() { > var options = {...}; > navigator.credentials.create({ > publicKey: options > }) > .then(console.log) > .catch(console.error); > } That's expected behavior. However, I will encourage you to file a bug and cc me. 1707327 30 aric 2020-11-13 11:32:09 -0800 (In reply to Jiewen Tan from comment #24) > (In reply to Aric from comment #23) > > Version 14.0 (14610.1.28.1.10) > > 10.14.6 (18G6032) > > MacBook Pro (15-inch, 2019) > > > > As far as I can tell this issue remains. > > Safari always prompts for security key, never Touch ID. > > > > Sites tested: > > webauthn.me > > webauthn.io > > Do you check isUVPAA? Touch ID won't work on any macOS before Big Sur. Touch ID works fine on these same sites with Mojave+ and Chrome. The published updates indicated this would work in Safari 14, and Safari 14 is now available on Mojave. Can you point me to the documentation that says you must have Big Sur to make this work? 1707361 31 jiewen_tan 2020-11-13 12:49:42 -0800 (In reply to Aric from comment #30) > (In reply to Jiewen Tan from comment #24) > > (In reply to Aric from comment #23) > > > Version 14.0 (14610.1.28.1.10) > > > 10.14.6 (18G6032) > > > MacBook Pro (15-inch, 2019) > > > > > > As far as I can tell this issue remains. > > > Safari always prompts for security key, never Touch ID. > > > > > > Sites tested: > > > webauthn.me > > > webauthn.io > > > > Do you check isUVPAA? Touch ID won't work on any macOS before Big Sur. > > Touch ID works fine on these same sites with Mojave+ and Chrome. The > published updates indicated this would work in Safari 14, and Safari 14 is > now available on Mojave. Can you point me to the documentation that says you > must have Big Sur to make this work? https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/ 1714358 32 teodor.atroshenko 2020-12-13 16:49:14 -0800 I think there is another common use-case that was missed. When using WebAuthn as a second factor during authentication, combined with Safari's credential autofill, we get into a situation where the user is automatically trapped by Safari into a failed authentication with application code having very little control. User opens the login page in Safari, they see the auto-login/autofill card appear on the bottom of the screen. They click on their email address there, which causes the <form> to be automatically submitted. The code that handles form submit then sends a fetch() request that resolves with options for credentials.get call. At this point, it is indistinguishable between form having been submitted via Enter key press, or auto-submitted by auto-fill. So calling credentials.get at this point results in a confusing prompt about inserting the security key, while the user is expecting FaceID to activate. Yes, hacks can be applied to detect keypresses in form fields, among others. But I think that the correct solution is to treat the user-activated autofill of credentials as a user gesture. 1714773 33 teodor.atroshenko 2020-12-15 09:26:47 -0800 Furthermore, ASWebAuthenticationSession should be exempt from the user gesture requirement. Any native app that relies on web-based authentication (either first- or third-party) that in turn may use WebAuthn, should be trusted in the same manner that calling LAContext with enrolled Face ID results in an immediate scan. I do think that this issue is not resolved, as expected authentication flows are still not working. But if you think that I should file a separate bug report, let me know. 1714833 34 jiewen_tan 2020-12-15 11:21:59 -0800 (In reply to Teodor from comment #32) > I think there is another common use-case that was missed. > > When using WebAuthn as a second factor during authentication, combined with > Safari's credential autofill, we get into a situation where the user is > automatically trapped by Safari into a failed authentication with > application code having very little control. > > User opens the login page in Safari, they see the auto-login/autofill card > appear on the bottom of the screen. They click on their email address there, > which causes the <form> to be automatically submitted. The code that handles > form submit then sends a fetch() request that resolves with options for > credentials.get call. At this point, it is indistinguishable between form > having been submitted via Enter key press, or auto-submitted by auto-fill. > So calling credentials.get at this point results in a confusing prompt about > inserting the security key, while the user is expecting FaceID to activate. > > Yes, hacks can be applied to detect keypresses in form fields, among others. > But I think that the correct solution is to treat the user-activated > autofill of credentials as a user gesture. Thanks for your feedback. Can you file a separate bug on this? 1725702 35 david 2021-02-04 11:13:37 -0800 I have been trying this on my test example (at https://webauthn.savesnine.info ) on iPad OS 14.4 and on iOS 14.4, in response to a user bug report re the code that implements that example, that webauthn with iPhone fingerprint had stopped working. It works for me - in the example. But it fails in the same way as the bug they submitted in a real world app. The difference is they are in Japan and I am in the UK, only a few km from my server. Their server round trip (and also the server response in a real app) is significantly longer than me using the example. I tried adding a setTimeout so the workflow becomes click - fetch credentials/challenge - receive them in callabck - wait for setTimeout callback - ask for authentication in setTimeout callback This still works for me in the example case for timeouts below 700ms. At 800ms it fails. It looks to me like there is a timer after the last user interaction during which the authentication request is allowed (probably 1s - my 800ms artificial delay + server roundtrip, seems plausible). My Japanese correspondent has a much longer round trip time (and you may or may not also if you try the example). I am not clear from the discussion here what release version of iOS this is fixed in, and whether that time delay IS the fix or is what it was before the fix this bug refers to and the real fix hasn't got into a public release yet. If 14.4 should work, then it doesn't, at least not when there is a sufficient delay between pressing the button and asking for authentication. When it works for me (short roundtrip) I get one iOS box pop up which asks which method I'd like to use, I reply fingerprint, and then I get the fingerprint prompt. When it fails, I just get an invitation to plug in my security key. The only difference is the length of time it takes to ask the server for the challenge/credentials. 404536 2020-07-16 21:59:56 -0700 2020-07-17 12:30:28 -0700 Patch bug-213595-20200716215956.patch text/plain 2791 jiewen_tan U3VidmVyc2lvbiBSZXZpc2lvbjogMjY0NDk4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDI2ZmVhZTU3MjVlN2UxMGZj MGFjZTA3OWQ0N2ZkYTc2OTNiZTIwMTkuLjc2NTJkNjVmMzVjNWM2NTg5YWQyNDVkYjU3NzQyMzQ5 MTBlNmI3YmUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTkgQEAKKzIwMjAtMDctMTYgIEppZXdlbiBU YW4gIDxqaWV3ZW5fdGFuQGFwcGxlLmNvbT4KKworICAgICAgICBbV2ViQXV0aG5dIFVzZSBNZWRp YU9ubHkgdXNlciBnZXN0dXJlCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD0yMTM1OTUKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzY0OTQ2NjEyPgorCisg ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIE1lZGlhT25seSB1 c2VyIGdlc3R1cmUgaXMgbW9yZSBmbGV4aWJsZSB0aGFuIHJlZ3VsYXIgdXNlciBnZXN0dXJlLiBG b3IgZXhhbXBsZSwgaXQgY2FuIGJlIHByb3BhZ2F0ZWQgdGhyb3VnaCBYSFIuCisgICAgICAgIEEg Y29tbW9uIHVzZSBjYXNlIGZvciBXZWJBdXRobiBpcyB0byBjYWxsIHRoZSBBUEkgd2l0aGluIFhI UiBldmVudHMsIHdoaWNoIGNvdWxkIGJlIHRyaWdnZXJlZCBieSB1c2VyIGFjdGl2YXRlZCBldmVu dHMgaW5pdGlhbGx5LgorICAgICAgICBCeSB1c2luZyBNZWRpYU9ubHkgdXNlciBnZXN0dXJlLCBp dCBhbGxvd3MgZGV2ZWxvcGVyIHRvIGtlZXAgdXNpbmcgdGhpcyBYSFIgbW9kZWwuCisKKyAgICAg ICAgKiBXZWJQcm9jZXNzL1dlYkF1dGhlbnRpY2F0aW9uL1dlYkF1dGhlbnRpY2F0b3JDb29yZGlu YXRvci5jcHA6CisgICAgICAgIChXZWJLaXQ6OldlYkF1dGhlbnRpY2F0b3JDb29yZGluYXRvcjo6 bWFrZUNyZWRlbnRpYWwpOgorICAgICAgICAoV2ViS2l0OjpXZWJBdXRoZW50aWNhdG9yQ29vcmRp bmF0b3I6OmdldEFzc2VydGlvbik6CisKIDIwMjAtMDctMTYgIEppZXdlbiBUYW4gIDxqaWV3ZW5f dGFuQGFwcGxlLmNvbT4KIAogICAgICAgICBbV2ViQXV0aG5dIEFkZCBhIGNvbnNvbGUgbWVzc2Fn ZTogIlVzZXIgZ2VzdHVyZSBpcyByZXF1aXJlZCB0byB1c2UgdGhlIHBsYXRmb3JtIGF1dGhlbnRp Y2F0b3IuIgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9XZWJQcm9jZXNzL1dlYkF1dGhlbnRp Y2F0aW9uL1dlYkF1dGhlbnRpY2F0b3JDb29yZGluYXRvci5jcHAgYi9Tb3VyY2UvV2ViS2l0L1dl YlByb2Nlc3MvV2ViQXV0aGVudGljYXRpb24vV2ViQXV0aGVudGljYXRvckNvb3JkaW5hdG9yLmNw cAppbmRleCAxYjU1MjA1YjAyMjUyMDAxNmNiN2Q1YmNjMzNjMmVmNDBjZWQ0Y2FlLi5lZmE0MzYz NDYwMjc1YjExMGQxNjkzNWRkNzAxMmUwZWZkOWNhZjVkIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2Vi S2l0L1dlYlByb2Nlc3MvV2ViQXV0aGVudGljYXRpb24vV2ViQXV0aGVudGljYXRvckNvb3JkaW5h dG9yLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L1dlYlByb2Nlc3MvV2ViQXV0aGVudGljYXRpb24v V2ViQXV0aGVudGljYXRvckNvb3JkaW5hdG9yLmNwcApAQCAtNTMsNyArNTMsNyBAQCB2b2lkIFdl YkF1dGhlbnRpY2F0b3JDb29yZGluYXRvcjo6bWFrZUNyZWRlbnRpYWwoY29uc3QgRnJhbWUmIGZy YW1lLCBjb25zdCBTZWN1cgogICAgIGlmICghd2ViRnJhbWUpCiAgICAgICAgIHJldHVybjsKIAot ICAgIGF1dG8gcHJvY2Vzc2luZ1VzZXJHZXN0dXJlID0gVXNlckdlc3R1cmVJbmRpY2F0b3I6OnBy b2Nlc3NpbmdVc2VyR2VzdHVyZSgpOworICAgIGF1dG8gcHJvY2Vzc2luZ1VzZXJHZXN0dXJlID0g VXNlckdlc3R1cmVJbmRpY2F0b3I6OnByb2Nlc3NpbmdVc2VyR2VzdHVyZUZvck1lZGlhKCk7CiAg ICAgaWYgKCFwcm9jZXNzaW5nVXNlckdlc3R1cmUpCiAgICAgICAgIG1fd2ViUGFnZS5hZGRDb25z b2xlTWVzc2FnZSh3ZWJGcmFtZS0+ZnJhbWVJRCgpLCBNZXNzYWdlU291cmNlOjpPdGhlciwgTWVz c2FnZUxldmVsOjpXYXJuaW5nLCAiVXNlciBnZXN0dXJlIGlzIG5vdCBkZXRlY3RlZC4gVG8gdXNl IHRoZSBwbGF0Zm9ybSBhdXRoZW50aWNhdG9yLCBjYWxsICduYXZpZ2F0b3IuY3JlZGVudGlhbHMu Y3JlYXRlJyB3aXRoaW4gdXNlciBhY3RpdmF0ZWQgZXZlbnRzLiJfcyk7CiAKQEAgLTY2LDcgKzY2 LDcgQEAgdm9pZCBXZWJBdXRoZW50aWNhdG9yQ29vcmRpbmF0b3I6OmdldEFzc2VydGlvbihjb25z dCBGcmFtZSYgZnJhbWUsIGNvbnN0IFNlY3VyaXQKICAgICBpZiAoIXdlYkZyYW1lKQogICAgICAg ICByZXR1cm47CiAKLSAgICBhdXRvIHByb2Nlc3NpbmdVc2VyR2VzdHVyZSA9IFVzZXJHZXN0dXJl SW5kaWNhdG9yOjpwcm9jZXNzaW5nVXNlckdlc3R1cmUoKTsKKyAgICBhdXRvIHByb2Nlc3NpbmdV c2VyR2VzdHVyZSA9IFVzZXJHZXN0dXJlSW5kaWNhdG9yOjpwcm9jZXNzaW5nVXNlckdlc3R1cmVG b3JNZWRpYSgpOwogICAgIGlmICghcHJvY2Vzc2luZ1VzZXJHZXN0dXJlKQogICAgICAgICBtX3dl YlBhZ2UuYWRkQ29uc29sZU1lc3NhZ2Uod2ViRnJhbWUtPmZyYW1lSUQoKSwgTWVzc2FnZVNvdXJj ZTo6T3RoZXIsIE1lc3NhZ2VMZXZlbDo6V2FybmluZywgIlVzZXIgZ2VzdHVyZSBpcyBub3QgZGV0 ZWN0ZWQuIFRvIHVzZSB0aGUgcGxhdGZvcm0gYXV0aGVudGljYXRvciwgY2FsbCAnbmF2aWdhdG9y LmNyZWRlbnRpYWxzLmdldCcgd2l0aGluIHVzZXIgYWN0aXZhdGVkIGV2ZW50cy4iX3MpOwogCg==