iOS Safari - autofill alters or destroys session cookie when share bookmark is used (video)
https://www.youtube.com/watch?v=ZZTt4BsnsLE&feature=youtu.be
This video shows a problem with using 1Password to enter a credit card for a donation web app. I do not know if the problem is within 1Password or Safari though
- Login to Giving
- Select "New Card" on gift form
- Use 1Password from bookmark menu to autofill card
- Without submitting gift. Tap refresh icon in Safari
- It will redirect to authentication (This appears to happen simply by autofilling using 1Password (no form submit or ajax required)
This appears to be a bug in either Safari or 1Password where the cookies are being altered by using the share bookmark feature.
Comments
-
Hi @dmitche,
Thank you for taking the time to write in with the detailed report. Could you please tell me:
1) Does this happen in Safari if not using 1Password (or any other extensions)?
2) Does this happen in 1Browser, within 1Password?
3) Does this happen in Safari when using any other extensions (I noticed you also have LastPass installed, for example)?Thanks!
Ben
0 -
@bwoodruff
Thanks for the questions.
1. It does not occur in Safari if 1Password is not used. Meaning, I am able to enter a credit card number manually and submit the gift without having to re-authenticate. The issue is not present if the native Safari autofill is used.
2. The issue does not in 1browser inside of 1password app on iOS - I added a credit card and it didn't boot me out - the bug seems to be 1password / safari on iOS
3. We tried to use LastPass to autofill a CC#, however it doesn't appear as though LastPass has this functionality.0 -
Hi @dmitche,
Thanks for getting back to us again :+1:
When we fill a 1Password item, we do so by executing some Javascript code. We execute the same code in both the App Extension and in 1Browser. However, the way we execute it is different. This is due to the different APIs which are available to us:
In the 1Password App Extension in Safari only not 3rd party browsers, we use
NSExtensionJavaScriptPreprocessingFile
. See the "Accessing a Webpage" section in the App Extension Programming Guide.In 1Browser and third party apps and browsers which use our Web View filling capability, we use the standard APIs for
UIWebViews
andWKWebViews
.
So here are another set of questions which may shed some light on the issue that you're experiencing:
- Can you reproduce the issue in a third party browser which uses the 1Password App Extension API? Browsy is a third party browser which uses it.
- Do you see any filling issues when filling Credit Cards on other websites?
The answer to these questions may help us determine if the issue is caused by our Javascript code or by the way filling is performed when using
NSExtensionJavaScriptPreprocessingFile
or even the website itself.I look forward to your reply :-)
Cheers!
0 -
- A tester on our team was able to use Browsy, navigate to our website, and complete a gift using 1Password to autofill the credit card
- The same person has not had issues using 1Password within Safari on other sites which request credit cards.
I'm not sure where this leaves us since it sounds like it is not entirely a browser issue nor is it a website issue.
0 -
Thanks for getting back to me so quickly, @dmitche! :+1:
The same person has not had issues using 1Password within Safari on other sites which request credit cards.
I assume that the same person did encounter the same filling issue as you first reported, right?
Anyway, we should not exclude the possibility of it being a website issue either. I usually test Credit Card filling on the following sites:
- https://agilebits.com/store (Click on Single license, the on Checkout)
- https://creditcardjs.com
- The amazon.com
Add credit/debit card
page.
I just tested Credit Card filling in the aforementioned websites and did not notice any inconsistencies in Safari, 1Browser, ACME Browser (our demo app from our App Extension API repo) or in Browsy.
Thanks for helping us debug this issue!
Best,
0 -
Good news, our developer was able to locate the issue using a proxy to examine the cookies. Turns out Safari attempts to load 4 touch icons (png) files after completing the 1password auto fill. Since our site doesn't have these icons it was hitting a 404. The cookie returned from the 404 on the apple icon load in the browser was changing the session cookie before the donation request. Thus the session was terminated even without the page reloading.
0