Query string causes problems

clarino

I'm running 1Password 7.8.6 and Chrome 92.0.4515.107. When I click on a website from a 1password entry, I see the browser try to reach the website with a query string appended. For example, when I click on:

https://1password.community

what I actually see in the browser's address bar is:

https://1password.community/?262svla5ardcjdmubp3ghvhbsi=g662rzdwj7sru2fpwqq...

I'm speculating this is some type of security measure that allows the browser to trust the request from the app. Alas, it breaks the following website:

https://support.runbox.com/index.php?

I can live with it but I'm wondering if it's a bug or misconfiguration on my part.

---

1Password Version: 7.8.6
Extension Version: 2.0.5
OS Version: macOS 10.13.6

ag_ana

Hi @clarino!

Let's take the Forum Login entry for example: if you open it in 1Password, what is the value of the website field in the item?

clarino

In 1Password, the value of website is: https://support.runbox.com/index.php?
and, yes, the question mark is part of the URL.

ag_ana

@clarino:

Thank you! I see the same behavior here, the website adds that part to the URL if you open it directly from 1Password for some reason. In this case, your best choice is to visit the website, and call the browser extension from there, instead of directly from the desktop app.

By the way, you can make the website field shorter if you wish: https://support.runbox.com will be enough, everything else is ignored for filling credentials anyway, since 1Password only looks at the domain name :+1:

clarino

I'm pretty sure you are incorrect that the website is adding the query string. My evidence:

1) I clicked on a bunch of other websites from 1P and all of the URLs have similar query strings added.

2) I instantiated a simple http server and then logged the traffic between the server and the browser. Upon clicking the website from 1P, the first thing the browser sends is:
GET /?pzrzvkahxbcmonppmt5oufpd4u=4iawrmbzojgcjgqkipskdlfj HTTP/1.1

Seems compelling that 1P (or 1P's browser extension) is adding the query string, not the websites.

ag_ana

@clarino:

Thank you for the additional tests! I will ask the rest of the team if they have ever seen this behavior before, and if they have any suggestions :+1:

ag_ana

@clarino:

I have heard back from the team: this is a known behavior, and it's used to let the app know what item to use to fill credentials on a page. The developers are however tracking cases where this might interfere with the website, so I have let them know that you have also encountered this, and added this URL to the list of websites to check :+1:

ref: dev/core/core#8723

clarino

Thanks for acknowledging the issue. I am tempted to say that the particular service (Kayako help desk software) where this problem appears should fix their "problem" that is, their sensitivity to a query string parameter that they don't care about. It looks like Kayako has a bug - more evident in the pic below - because 1P's parameter is a named parameter but in the diagnostic, Kayako has squeezed out the equal sign, so now the query string looks like a giant unnamed parameter and I can understand sensitivity to unnamed parameters (as compared to named parameters).

In other words, your team is doing a reasonable thing by using a named parameter. Kayako is doing the wrong thing by misinterpreting it as an unnamed parameter. That said, I would still suggest 1P use a parameter name that starts with "1Password" to avoid inadvertent clashes. You can't blindly share namespaces.

I can imagine you're reluctant to contact services that cause problems for 1P but in this case, Kayako appears to be a popular provider and might well be interested in hearing a bug report from you. (I'd report it myself but a report from 1P will have more oomph.)

ag_ana

Thank you @clarino :+1: The website is now in the list of URLs to check, so I will let the developers look at them and see if there is anything we can do. They will reach out to the service if necessary :)

clarino

Please don't overlook my comment/suggestion about shared namespaces (paragraph 2, sentence 2 in my previous reply). Developers cannot blindly choose names in a shared namespaces. (An additional benefit: Params cleared identified as belonging to 1P would make it easier for you to identify that 1P is responsible for the problem as I originally reported it.)

ag_ana

@clarino:

Certainly, I have sent them the link to this entire discussion :+1: