Add Secrets extension bundle ID to the whitelist
Reported by
pfandr...@gmail.com,
Jan 16 2017
|
|||||||
Issue descriptionSteps to reproduce the problem: Attempt to fill a login in Chrome for iOS using Secrets extension. What is the expected behavior? It should fill just like 1Password and LastPass do. What went wrong? Login filling doesn't work because Secrets' extension isn't launched with the necessary items in the extension context for this to work. Did this work before? No Chrome version: 55.0.2883.79 Channel: stable OS Version: 10.2 Flash Version: Hello, I'm the author of Secrets. One of our users have reported that Chrome for iOS already supports integration with password managers: The following issue tracked this feature request: https://bugs.chromium.org/p/chromium/issues/detail?id=405894 The above issue mentions that extensions should have the "find-login-action" string in its bundle id for the appropriate extension items be sent to the extension (otherwise only a URL and plain text extension items are sent). However, Secrets already has a considerable install base and changing the extension's bundle identifier would force all existing users to re-enable the extension again. So I kindly ask you to add our extension's bundle ID "com.outercorner.ios.Secrets.Search" to your whitelist just like you've done for 1Password.
,
Jan 19 2017
Indeed, the quickest way to add support would be to add the substring "find-login-action" anywhere within your bundle id. This will involve no change in Chrome or wait for at least 1 release cycle. The place where this change in Chrome can be made is https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/activity_services/activity_type_util.mm and will likely involve adding a new enum APPEX_PASSWORD_MANAGEMENT_foo, the actual bundle id for the app, and add it to all the relevant places where other APPEX_PASSWORD_MANAGEMENT_* are used. It should not be a complicated change, but it is hard to tell when one can get to it.
,
Jan 20 2017
Yes, I understand changing my bundle ID would also work. The problem will be that all my user base would have to re-enable the extension. Even if they don't use Chrome. Looking at the code that seems exactly where to make the change. Changing this on Chrome side would have no impact on either Chrome or my users (except that my extension would start working). So even if you can't get to it now, I would prefer the change be made on your side later on. Also, and this is just a suggestion, I'm not sure this white list is needed. In https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/activity_services/activity_service_controller.mm?rcl=0&l=168 instead of testing the activityType string why not just look at the returnedItems to see if it matches what's expected from a password manager (a single PropertyList item with a username and/or password field)? The processItemsReturnedFromActivity:status:items: method already does most of the validation. What are the chances an extension will return that item without the intention of filling that info? It seems like a reasonable convention.
,
Mar 16 2017
,
Apr 15 2017
,
Apr 17 2017
,
Apr 19 2017
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e02d5f6605d5ceabeb3f5cd4a84495a54e1f3fce commit e02d5f6605d5ceabeb3f5cd4a84495a54e1f3fce Author: pkl <pkl@chromium.org> Date: Thu Apr 20 20:53:58 2017 Adds Secrets Password Manager to kAllPasswordManagerApps App: https://itunes.apple.com/us/app/secrets-touch/id1018350473?mt=8 BUG= 681583 TEST=Install Secrets app and test that extensions work. Review-Url: https://codereview.chromium.org/2826463002 Cr-Commit-Position: refs/heads/master@{#466123} [modify] https://crrev.com/e02d5f6605d5ceabeb3f5cd4a84495a54e1f3fce/ios/chrome/browser/ui/activity_services/activity_type_util.mm
,
Apr 21 2017
Verified on Chrome 60.0.3077.0 canary. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by justincohen@chromium.org
, Jan 18 2017Status: Assigned (was: Unconfirmed)