Restore bookmarklet to Zotero saving

[dstillman]

https://forums.zotero.org/discussion/comment/215935/#Comment_215935

It's possible we could get this to work by running the connector server over HTTPS on a different port with a Let's Encrypt cert and having the bookmarklet try to connect to https://local.zotero.net, which would serve an A record for 127.0.0.1.

This is only relevant for people who 1) can run the client and 2) don't want to run a connector-enabled browser, so this is far from a priority, but it would probably be easy to do in Electron.

[dstillman]

Some additional work would also be necessary to do Let's Encrypt validation on a domain that resolves to 127.0.0.1:

http://security.stackexchange.com/a/121187
http://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation

[adomasven]

Are we sure this is still necessary?
https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and
https://www.w3.org/TR/secure-contexts/

Seem to special-case 127.0.0.1 as a secure context.

[dstillman]

Oh, interesting — maybe not. We should test this and remove the block anywhere it actually works.

[adomasven]

I'm missing something here. I'm on Chrome, testing the bookmarklet saving to Standalone and am not seeing any issues. How do you reproduce this?

[dstillman]

Are you sure you're not seeing saving to server? As far as I know saving to the client is disabled in the bookmarklet. If I try from an unauthenticated browser I just get an iframe with a Zotero login page.

[adomasven]

So we'll need a connector server over HTTPs for Safari support, since we cannot continue with the connector and Safari does not consider 127.0.0.1 a secure context afterall.

It's possible we could get this to work by running the connector server over HTTPS on a different port with a Let's Encrypt cert and having the bookmarklet try to connect to https://local.zotero.net, which would serve an A record for 127.0.0.1.

This is only relevant for people who 1) can run the client and 2) don't want to run a connector-enabled browser, so this is far from a priority, but it would probably be easy to do in Electron.

This is not an option since we'd have to embed the private key within Zotero, which is grounds for cert revocation.

This leaves us with few and kinda awful options:

1. Install a root CA and issue a cert for localhost. This is perhaps the easiest path, since there exists a TLS socket implementation in XPCOM, so it would be a matter of a few code changes in the client and prompting macOS users for admin password for the root CA install. It would be an additional headache for users without admin access on their machines.
2. Add a way to talk to the zotero client using websockets via zotero.org, but that would add an annoying level of overhead in terms of latency and would add an extra layer of complicated code. This seems to be what spotify has resorted to recently, after being told off for embedding a private cert with their client and currently the only legit way to talk to local services from Safari.
3. Improve saving to zotero.org with a collection selector. This still leaves us with the problem of the bookmarklet not being able to perform cross-domain and cross-origin requests, and as such makes most translators incompatible.

[dstillman]

We can rule out (1). We're not going to mess with the OS certificate store.

I'm not understanding the mechanism on (2).

(3) we should be able to do (though not for an initial release).

For the cross-domain issue, it's not "most" translators, is it? I would think most translators would work fine, but some that depend on, say, DOI lookups would fail, right? But for those, the Zotero API already has (undocumented) support for adding via a URL, and I thought we were already using that in the bookmarklet at some point by passing a url property in the items payload. In any case, we can either restore that or switch to a separate translation-server request (as used in ZoteroBib) that's followed by a regular JSON upload.

[adomasven]

(2) Is just proxying bookmarklet requests to the zotero client via zotero.org.

I would think most translators would work fine, but some that depend on, say, DOI lookups would fail, right? But for those, the Zotero API already has (undocumented) support for adding via a URL, and I thought we were already using that in the bookmarklet at some point by passing a url property in the items payload.

The Amazon translator is the only one that uses this, since translators have to return "server" for the mechanism to trigger.

For the cross-domain issue, it's not "most" translators, is it?

I guess I was a bit preemptive on this one. We currently rely on the browserSupport flags in translators to determine whether the bookmarklet can attempt to translate the page itself. That's 420 out of 530 current translators, so, assuming most of these work, it's not too bad.

In any case, we can [...] switch to a separate translation-server request (as used in ZoteroBib) that's followed by a regular JSON upload.

This would be great.

[dstillman]

(2) Is just proxying bookmarklet requests to the zotero client via zotero.org.

Ah, I see what you mean. That seems complicated, and we'd need some mechanism to link a given connector to a given client, and the main difference from server-based saving would be access to a PDF, which the client could add afterwards anyway.

The Amazon translator is the only one that uses this, since translators have to return "server" for the mechanism to trigger.

Oh, weird. I had no idea that was a thing. Shouldn't that also be used when browserSupport doesn't indicate bookmarklet support and the client is unavailable?

[adomasven]

Oh, weird. I had no idea that was a thing. Shouldn't that also be used when browserSupport doesn't indicate bookmarklet support and the client is unavailable?

The currently published bookmarklet just falls back to the next supported translator. We could change that. Presumably this was done back in the day to save network traffic?

[dstillman]

Hmm, that's an interesting question: when the client isn't available, is it better to use server-side translation or a lower-priority translator? I guess the latter is fine, particularly as we add the ability to enhance metadata afterward in the client.

[adomasven]

Hmm, that's an interesting question: when the client isn't available, is it better to use server-side translation or a lower-priority translator? I guess the latter is fine, particularly as we add the ability to enhance metadata afterward in the client.

Often this will mean saving the page as a website, especially for more obscure journals. If we can afford to run translation on the server I think we should.