1PW captures Speedway.com username and password, but will not autofill in the same

xz4gb8

Speedway.com uses a popup login entry window. 1Password gathers and labels Email, PIN, and checkmark data - most recently tested by creating a new 1Password login object. The login entry window fails to automatically enter the same data using the 1PW browser button. This is a long-standing problem since Speedway updated their web site to use a separate login sub-page and regardless of version of 1Password or OS X.

I had a moment to re-examine this problem today. --

• Upon attempted fill, the error "You must provide a PIN Number." appears. (So I entered a PIN.)
• Manual entry of a PIN first allows automatic entry of Email and submission of the login.

I do wonder why the Speedway login script requires the PIN first -- Editing the 1PW login object shows repeatably that the Email is listed first, presumably making it the first parameter entered. Is this correct? Can the order be changed?

Anyway, all this can be checked without actually logging in, since 1PW success is indicated by appearance of form data from 1PW.

Thanks for the great product. With a little help from Dropbox, it is the best secure-data sharing product I have found.

---

1Password Version: 6.3.BETA-10 (630010)
Extension Version: 4.5.5
OS Version: 10.11.4 (15E65)
Sync Type: Dropbox

littlebobbytables

Hello @xz4gb8,

I'd like to ask what you mean when you say autofill. The reason I ask is I know it's a term that trips up some based on how we fill compared to some alternatives.

I visited the site in question from Safari and created a Login item. After reloading to reset the page I then used ⌘\ to fill. There was a brief flash of a message which said something about a PIN but it was visible for so little time I don't know what it said. It correctly filled both the email and PIN though and so I then tested using autosubmit as I always turn it off when testing. Now I don't have an account but the error message I received was the same as when I manually attempted to log in and it was the site saying the details were wrong.

Now due to the nature of the window open and fill, where you click on the URL stored in the Login item, that won't work here as there isn't a URL we can load that shows you the login form. So I expect only filling after manually clicking on the Login / Sign Up link in the top right hand corner will work.

Given our experiences differ I'll be interested to see what you think of what I've written. Maybe I'm testing a different browser, maybe I'm not fully understanding the issue. I'm sure we'll get to the bottom of it though :smile:

xz4gb8

I wondered about the word "autofill". I was referring to form fill-in by 1Password. I'm running the absolute latest 1PW you give me.

The difference in our test environment may be that I have a working Speedway account but created a test 1PW login object for the Speedway login UI testing. Screen shots are in https://www.dropbox.com/sh/md85gxmezl1a93m/AAABk8Pk5EfLyEgr6ighHHI1a?dl=0

1. Created login object (created from web by 1Password)
2. Result of open and fill
3. After clicking on home screen login button
4. After 1PW attempted to fill the login form (doesn't matter if by menu or Command-)
5. PIN entered
6. After 1PW now can fill login form
7. After login attempt failed because of bogus ID used for testing

After this test, I switched to my 10.11.5 test system. Safari behavior was identical. When I tried Firefox on that machine, 1Password told me it was insecure and asked if I really wanted to fill it in. I clicked OK and the subsequent results were identical to those from using Safari.

My Key Conclusions:
1. Not an EBCAK or an ID10T error --- I do understand how to cope with sites with "Login" buttons that don't login.
2. Not a function of OS version, at least since mid 2015
3. Not a function of browser type or version, that I have been able to find
4. Not a function of 1Password for Mac version since before the 5->6 transition, the problem has been constant
5. It is a hard and repeatable fault unique to Speedway.com (in my experience) since the modification to remove the login form from their home page sometime last year
6. Seems to be related to site code looking first for PIN before allowing 1PW to enter Email

What else can I tell you?

littlebobbytables

Hi @xz4gb8,

So the difference between our approaches is that I tend to use the keyboard shortcut for filling ⌘\ whilst at least in the case of Speedway you prefer open and fill, which is where you click on the URL stored in the Login item.

The way that open and fill works is it passes the URL to OS X and OS X passes it to your default web browser. Once the page has loaded the extension knows that this was an open and fill instruction so it attempts to fill the loaded page. Now as we both know the login form isn't on the screen on their home page and it seems the only way to make it visible is to click the link. At least one of the fields though must be present in the underlying source of their home page given as soon as the window is brought up there is the error message. I can replicate this as well if I use open and fill. In contrast if I simply visit their home page manually by loading http://www.speedway.com/ in a new tab and then open the login window there is no error message and if I then use the keyboard shortcut ⌘\ to fill it works.

On sites where the login window may be really exist until the link is clicked open and fill can have unpredictable results from simply doing nothing to odd behaviour like this. 1Password doesn't understand the concept that it has to wait for the page to load and then click a link on the page so it will fail. So the precise reason why you're seeing this error message hasn't been determined but it is unlikely that we will be able to get open and fill to work with this site. Thankfully sites like this aren't the majority but they do happen. It makes sense that open and fill started to fail when they removed the login form from the main page as previously the entire form was available and 1Password is perfectly suited to handle this type of page. Does that help explain what you're seeing at all?

xz4gb8

littlebobbytables,

We are still talking past each other.
1. It does not matter how the speedway.com web page is reached (from a shortcut or from 1PW).
2. In any case the Login button must be pushed to invoke the login form.
3. Use of Command-\ to fill or clicking on the browser tool bar 1PW icon to fill produces identical results (failure to load Email and PIN in the login form).

The only real oddity is that manual entry of the PIN then enables 1PW use of Command-\ to fill or clicking on the browser tool bar 1PW icon to fill will then fill in the Email.

I do not expect open and fill ever to work on such a site, except to open the page.
I do expect use of Command-\ to fill or clicking on the browser tool bar 1PW icon to fill to work. (It does not work properly, as previously documented.)
I still wonder if changing the fill order so that the PIN is supplied first by 1PW would work with this site, but I can only approximate this by entering the PIN by hand before invoking 1PW.

littlebobbytables

Hi @xz4gb8,

I've discovered the reason why we're seeing very different behaviour which is why I was struggling to understand. See if you find a difference in observable behaviour after the following steps.

1. Uninstall the 1Password Safari Extension.
2. Restart Safari (for caching reasons).
3. Install the beta version of the 1Password Safari Extension available from our 1Password Browser Extensions page.

It seems something we've done in one of the betas makes a heck of a difference here. I don't know if you will have to create a new Login item after installing the beta extension, it is possible.

Do you find a single fill properly logs you in now?

xz4gb8

@lbt

Bingo! Thank you.

Version (beta) 4.5.6.b5 works as expected. No messing with login items was required except to set "Always Submit" on the speedway login object -- and I only did that 'cause I'm lazy and did not want to have to click the big button.

Apparently downloading the latest 1Password beta release is not related to browser extension updates.

New Question: How can I know that a new browser extension is available?

littlebobbytables

Hi @xz4gb8,

I'm glad we managed to figure that one out, it always drives me daft if I can't reproduce an issue and I'm sure it was no better for you that you simply weren't experiencing what I said I was.

You're spot on that the extension is very separate from the actual application. Part of the reason is the extension works on both the Mac and Windows platforms but it does pose a good question, should the application be notifying you of available betas of the extension if you're running the beta of the application. I'll have to check and see what information the extension reports to 1Password, maybe it can be used here.

As for your last question. Currently it's a bit different depending on your preferred browser. With Firefox and Chrome they both treat betas like they treat the stable version and each has it's own branch for lack of a better word. Both browsers will make regular queries to ensure they're running the latest version of the extensions and that's as applicable for the betas as it is the stables. They will update automatically and I don't think they give any indication that they're doing so, it just happens in the background. What neither will do though is highlight that there is a newer beta than the stable version, the user has to consciously decide which route they want to follow.

It's a little messier with Safari. Safari used to work a little like this but it changed in Safari 9. Now Safari will only automatically update an extension if the extension came from their Safari Extension Gallery and our extension is present in their gallery. They don't seem to have a gallery for beta versions though which means our beta falls into the same category as non-Safari Extension Gallery extensions. Safari will tell you there are updates available but only if you look in the Extensions tab of Safari's preferences. When updates are available a new entry in the list on the left hand side pops up and it looks like this.

So basically Firefox and Chrome automate extension updating for either the stable or the beta and all you need to do is download one to stay on that track. Safari is automated only if the extension comes from the Safari Extension Gallery so betas have to be checked manually which is a pity. I hope that helps :smile:

xz4gb8

This is just a mild update regarding the beta Safari extension.
I test developer previews on various systems. When I install on bare metal (or bare VM), 1Password is always the second application installed -- Dropbox is first so I have the vault. The problem is that there is sometimes a long time gap between new installations and I have to re-learn the multiple paths to get beta versions of both the application itself and the browser extensions. It would be nice if my forum preferences could include enabling beta downloads upon login. Not that the enable beta button is hidden, but it is not mainstream.

sjk

Hi @xz4gb8,

… and I have to re-learn the multiple paths to get beta versions of both the application itself and the browser extensions.

Both can be found under different spots starting from this single location:

AgileBits Update Server
https://app-updates.agilebits.com/

It would be nice if my forum preferences could include enabling beta downloads upon login.

I'm struggling to imagine how that would be possible, or misunderstanding what you'd like, since there's no connection between this forum's preferences and our download pages. Hopefully using the AgileBits Update Server can make your 1Password downloads on bare metal and VMs more convenient. :)

xz4gb8

sjk,

Thanks for the revealing the hidden knowledge of the AgileBits Update Server. Am I to expect information on Browser extensions there? I did not see any.

Also, the relationship between this forum's preferences and our download pages was also in the category of hidden knowledge (at least from my viewpoint) so thanks for that information. Anyway, that only affects the achievement of my dream, not the dream itself.

AGAlumB

@xz4gb8: Yep! If you scroll down a bit, you'll see "1Password Browser Extension" listed. Just click on "Full Changelog" and you'll find everything (and more) that you could ever want to know about its releases.

It could definitely be cool to have some sort of site preferences...but the concerns would be privacy/tracking, and the fact that most people just aren't doing as many installations as you and I where there would be a benefit.

Anyway, I'm glad to hear that worked for you, and thanks again for the feedback. We're here if you need anything else! :)

xz4gb8

Well, here I am again. I'm glad you promised to be here if I need anything else, because speedway.com login has been a problem again.

The dropdown login entry form is again not filling in.

As a test, using Safari and speedway.com:
1 - I entered a dummy username and pin.
2 - Asked 1Password to record the new login.
3 - On submission of the dummy login I got authentication error as expected.
4 - The contents of the 1Password login object are in the Dropbox folder https://www.dropbox.com/sh/b1nr7x45sbqjc2d/AABW4IP2J8X2FNEmIUCAxu1Sa?dl=0
5 - Closed Safari
6 - Opened Safari
7 - Went to speedway.com
8 - Clicked the Login button
9 - No data entered in login dropdown form - dropdown form disappeared.
10 - repeated 5-9 with login object set to never submit and got same failure - data never appears in login form.

Repeatable hard error.
1Password 6
Version 6.6.BETA-2 (660002)
AgileBits Beta
Extension is 1Password (beta) 4.6.3.b1

Since any bogus email and 4-digit pin works to create a 1Password login object
and
Since the failure is 'no data entered into dropdown form', before any submission

perhaps in your copious free time you might look at this.

Thank you for this product, its ongoing improvements, and your continuing support.

--- Jim

littlebobbytables

Greetings @xz4gb8,

Can you check something for me please, see if you see the same results as I do.

Can you set the Login item to Never submit and then after step 9 where the login form has disappeared can you try clicking on the Login button again. We'll need to investigate but I suspect it's partly to do with the gas search field. Clicking anywhere other than the login form causes the login form to disappear and I think it's when we analyse the page that we inadvertently cause the login form to disappear. This represents a challenge because we need to know a certain amount about every field to understand if we should interact with it or not and we often need to interact with fields that aren't obvious due to how many sites work.

What I found was after filling the login form did disappear but when I brought the form back the fields were both filled. When I then clicked on the Login button the error message seemed to indicate a successful login attempt that failed due to bad credentials. I would be curious to learn if your findings match mine at all here.

xz4gb8

• Data from older and previously working speedway.com Login items just disappears, not to be seen again.
• Data from any Login item newly created by Save new Login disappears, but is visible on again clicking the** Login** button, regardless of the Submit setting being any of Submit when enabled, Always submit, or Never Submit.
• Login succeeds if visible data is correct.
• (extra) The saved state of the checkbox is always ignored.

I am impressed that the programmer worked so hard to make a clever and less usable form, but not favorably impressed.

jxpx777

@xz4gb8 Thanks for your testing. I just tried this myself and I was really floored by how poorly we handle this page. I've asked one of the team to create an issue and test case so we can figure out what we're missing here because from everything I see, the extension is properly understanding the page but the filling logic is just getting its interpretation wrong. I'm not quite sure yet why this is happening, so we'll need to investigate a little further to find the fix. It seems like the fix will be in our form filling logic, which means it will have to be released in our platform apps, so it could take a bit for the fix to be widely available.

That being said, the other description of the form being properly filled after you bring the popup back in to view is an indication that we might be able to make a minor tweak to prevent the popup from being dismissed as we attempt to ascertain if the fields that aren't currently visible fall into the category of tricky fields that aren't visible until we click or type into them. @littlebobbytables thinks this is the situation with saving a fresh Login from the browser extension, so hopefully we can have some progress on that front soon.

--
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas

ref: BRAIN-339

jxpx777

@xz4gb8 Just following up since @littlebobbytables brought something to my attention. This site is using a technique I hadn't seen before. The PIN field is really a <input type="number"> with a special styling with -webkit-text-security: disc !important; to bullet out the value of the field. I checked in Firefox and it does indeed use a proper password field and in that case, the filling works exactly like I expect it to.

To test things further, I tried a new technique that we introduced recently (and quietly since it's a bit cumbersome right now to be frank). I created a new Login in the main 1Password application, outside of the browser extension. After I set the username and password and saved, I edited again and went to the web form details section. I changed the PIN field to a number type and removed the password designation and set the field's name to "PIN". Then I set the username field to type of email and its name to "Email". (These field names just match the placeholders you see in the popup.) After these adjustments, the Login filled in Safari and Chrome for me, albeit with the same popup dismissal behavior Lil' Bobby previously noted.

So, the situation is not as silly as it seemed at first to me in terms of 1Password's capabilities but it's a little more silly to me in terms of the site's programming.

xz4gb8

@jxpx777, @litlebobbytables

lbt's test request helped me provide the good data. jpxpx' response convinced me I wasn't hallucinating.

Let me know when you need more testing.

Thanks again.

littlebobbytables

Hello @xz4gb8,

It's definitely a really odd site and it's confused us too. Jamie was making assertions that I couldn't confirm and we found this changing behaviour between browsers that I hadn't realised. I don't know, what's wrong with a nice, clean, login page?

You're definitely not hallucinating though, it's a problematic site with no easy answers at the moment.