"logging in to sync server"

Login und password should be okay. Status "loggin into sync server" now for several hours.
«1
  • Have you tried restarting Zotero/Firefox?
  • Having the same issue - but only with Zotero Standalone. (Zotero Firefox syncs just fine). When I click sync (or have it set to Automatic) it spins without resolving with "logging into sync server" as the only info.

    I have tried re-installing standalone, re-entering password, etc.

    Ubuntu 10.04
    Zotero Standalone 3.0.14
  • Driftless: Can you restart Standalone and provide a Debug ID for a few minutes of the spinning?
  • Hmmm... uploading the debug report also hangs. (Possibly related?) But here it is:


    version => 3.0.14, platform => Linux i686, oscpu => Linux i686, locale => en-US, appName => Zotero, appVersion => 3.0.14

    =========================================================

    (5)(+0000000): SELECT subject FROM relations WHERE predicate != ? UNION SELECT object FROM relations WHERE predicate != ?

    (5)(+0000000): Binding parameter 1 of type string: "dc:isReplacedBy"

    (5)(+0000000): Binding parameter 2 of type string: "dc:isReplacedBy"

    (5)(+0000014): Beginning DB transaction

    (3)(+0000000): Beginning Notifier event queue

    (5)(+0000004): Committing transaction

    (3)(+0000000): Resetting Notifier event queue

    (3)(+0000002): Session ID not available -- logging in

    (3)(+0000001): HTTP POST version=9&username=Driftless&password=******** to https://sync.zotero.org/login

    (5)(+0000087): SELECT version FROM version WHERE schema='lastlocalsync'

    (5)(+0047527): SELECT version FROM version WHERE schema='lastlocalsync'

    (5)(+0340333): SELECT version FROM version WHERE schema='lastlocalsync'
  • Is this on a residential network or an institutional one? Are you going through any kind of proxy server? Are you using any security software that might be blocking the connection?
  • Hi Dan - it is a residential network with no proxy (save an autoproxy connection through the University). It worked fine in the past.

    I probably should have mentioned this earlier, but I recently deleted all entries in a group, and during the subsequent sync is when it hanged. I went into firefox, did a reset (from local to server) and all was well there... however standalone is caught in perpetual login.
  • edited February 27, 2013
    The reset (discouraged as it is) shouldn't be related—there's no sign that Standalone is able to connect with zotero.org at all. You didn't say if you were using any security software, but that's the most likely thing I can thing of.
  • If you try to save something with a PDF attachment from the Chrome connector, does the PDF save? Standalone needs to be able to make network requests on its own for that to work, so that'd be a test to see whether Standalone can actually connect to anything.
  • Hi Dan,
    the loggin problem is definitively caused by the proxy. Turning off the proxy fixes the problem. The standalone version does not provide an option for turning of the proxy specifically for Zotero. So it must be done systemwide every time I want to logg into Zotero sync. That's rather tedious. Is there a workaround. (I'm using both MacOS and Ubuntu).

    R.F.
  • What kind of proxy is this?
  • An automatic proxy configuration for our academic network.
  • edited February 27, 2013
    So you're disabling the system proxy in Firefox, and that's why it's working there?

    What happens in Firefox when the proxy is enabled and you try to connect to an HTTPS site like https://sync.zotero.org?
  • Firefox proxy is enabled, https://sync.zotero.org produces "Nothing to see there"
  • Sorry, I don't understand. I don't know your network configuration, so you'll have to be a bit more explicit here. We can't fix this in Standalone unless we know what the problem is.

    What can you change on your system and in Firefox to make Firefox and Standalone work or not work, and what effect do those changes have on your ability to access https://sync.zotero.org in Firefox?
  • With firefox all settings work. https://sync.zotero.org can be accessed from chrome and firefox, regardless of proxy settings. Standalone only works if system-wide proxy is off.
  • It sounds like we may have the same problem.

    I use an automatic proxy configuration through the university (to get around journal paywalls). In Firfox, all works fine. In Chrome (actually chromium Version 24.0.1312.56 Ubuntu 10.04 (24.0.1312.56-0ubuntu0.10.04.1))

    DEFAULT: Chrome (and system) set to "direct internet connection". I can download citations to standalone but not PDFs behind paywalls (as expected). I can sync.

    CHROME PROXY: I set "autoproxy" for Chrome only (not applied system wide). IF standalone is already open, I can still sync, but still can not download pdfs. HOWEVER, if I close Standalone and re-open, then I can NOT sync (nor download pdfs). Almost as if standalone gets its proxy state from Chrome on boot up.

    SYSTEMWIDE PROXY: If I set autoproxy system-wide through chrome, I can still not download pdfs, nor sync.

    Does that make sense?
  • IF standalone is already open, I can still sync, but still can not download pdfs. HOWEVER, if I close Standalone and re-open, then I can NOT sync (nor download pdfs).
    Settings in Chrome should have zero effect on Standalone's ability to sync with the Zotero servers, so I assume this was related to the system proxy setting at the time you started Standalone, not any settings in Chrome.

    For testing of PDFs, I should have been clearer—I really meant that you should test, with the system proxy enabled and Standalone restarted, saving citations with open-access PDFs that were available even without going through the proxy, to test whether Standalone can connect to servers other than zotero.org. (The Chrome plugin downloads citations itself, but Standalone downloads PDFs itself.) But this probably isn't necessary.

    My guess is that the issue here is that 1) the proxy only allows connections to domains where it's necessary, 2) Standalone is always obeying the system proxy settings, and 3) Standalone (or XULRunner, the Mozilla platform we use) is not obeying the whitelist of hosts it's supposed to use the proxy for and instead trying to use the proxy for everything.

    If you could either post the URL for the PAC file or email it to support@zotero.org with a link to this thread, that might be helpful. I suspect that if you look at the contents of the file, you'll see that only some hosts are set to use the proxy and everything else is set to use "DIRECT", and that if you manually set Chrome to use the proxy server for everything, https://sync.zotero.org wouldn't work. With a copy of the PAC file we might be able to figure out why this is happening and file a bug with Mozilla to get this fixed if necessary.

    In the meantime, you could try going to about:config from the Advanced pane of the Zotero preferences, searching for network.proxy.no_proxies_on, and adding sync.zotero.org and api.zotero.org to the list, separated by commas. Then restart Standalone and see if syncing works.
  • Settings in Chrome should have zero effect on Standalone's ability to sync with the Zotero servers, so I assume this was related to the system proxy setting at the time you started Standalone, not any settings in Chrome.
    I can only report what I experience... which is that even if Chrome proxy is set (without changing systemwide settings) then the zotero sync is affected. Now, admittedly, this could be bad behavior on the part of Chrome (meddling with system proxies non-transparently).

    The autoproxy I am using is set by UC Davis. Since the instructions are publicaly available ( http://www.lib.ucdavis.edu/ul/services/connect/proxy/step1/chrome.php ) I see no harm in sharing it here: http://www.lib.ucdavis.edu/proxy/pacserve

    I will try some of the workarounds / tests you suggest when I am not on deadline.

    Thanks for the help.
  • edited February 28, 2013
    I can only report what I experience... which is that even if Chrome proxy is set (without changing systemwide settings) then the zotero sync is affected. Now, admittedly, this could be bad behavior on the part of Chrome (meddling with system proxies non-transparently).
    I suspect you're misunderstanding what you're seeing—as far as I know Chrome just opens the system proxy settings in all cases, but on Ubuntu there's a confusing "Apply system wide" button that changes the proxy settings in some other places (e.g., for command-line tools). But that's still the system proxy setting, so if you change that it's going to affect Standalone.

    Anyhow, thanks for the PAC link. We'll look into whether there are any known issues with PAC processing in XULRunner. It shouldn't be necessary, but there's a decent chance you can fix syncing by adding .zotero.org to the excluded hosts in either the system proxy settings or in Standalone's about:config (though I'm not sure the latter's blacklist applies if it's using the system settings). PDF downloads via Standalone from domains that aren't handled by your proxy would still fail, though.
  • When you get a chance, a Report ID for a failed sync attempt from a freshly restarted Standalone would be helpful.
  • Ahh, I see what you mean re: Chrome proxies in Ubuntu. Interesting you can't set a Chrome-only proxy...

    Test results:

    -- I set Standalone about:config->network.proxy.no_proxies_on to include sync.zotero.org and api.zotero.org. Still can't sync. (Sticks at "logging into sync server.")

    -- With autoproxy set, Standalone fails to get attached PDFs from open-access sources I can successfully retrieve when no proxy enabled.

    -- Ran a debug output on fresh load (with proxy enabled) and an attempted sync (which hang), but can't send it to Zotero servers. Will email to the support address above.
  • OK, thanks. Just to be sure, you didn't leave anything out at that top of that debug output, did you? Because when Firefox or Standalone uses a PAC file, a line should be logged to the Error Console, which would make it show up at the top of debug output and in the Report Errors window accessible via the gear icon in the Zotero toolbar. (You should be able to see the line in Firefox after the first page load if the system proxy is enabled.)
  • edited February 28, 2013
    Yup... this was cut off:

    [JavaScript Error: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init]" {file: "file:///home/user/programs/Zotero_linux-i686/extensions/zoteroOpenOfficeIntegration@zotero.org/components/zoteroOpenOfficeIntegration.js" line: 83}]

    Sorry for the omission
  • Nothing else? When you open and load a webpage in Firefox with the system proxy enabled, do you see the line in Report Errors about using a PAC file?
  • Just for grins, I fired up Firefox and got the same error (plus one). Code #: 748061558

    Though syncing and pdf download (of non-paywalled pdfs) work fine in Firefox with the autoproxy set both in system (via chrome) and firefox (via firefox).
  • These are the only things showing up Firefox Zotero "Report Errors" aside from the openoffice integration error above:

    [JavaScript Error: "this.docShell is null" {file: "chrome://global/content/bindings/browser.xml" line: 323}]

    [JavaScript Error: "Invalid URL 't' in Zotero.Attachments.importFromURL()"]

    (I did download one citation/pdf from Plos for testing...)
  • edited February 28, 2013
    Also in Firefox, I did a fresh load, turned on debug output, and did a sync. This error was added to the ones above:

    [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]" {file: "chrome://zotero/content/zoteroPane.js" line: 348}]

    Nothing specifically related to PAC file...

    (Not sure if my hunting and pecking is at all useful...)
  • Ok, through chrome, I set the autoproxy then hit: apply proxy systemwide. Then when I loaded up Firefox, I got something:

    Report ID: 1879026392
  • OK, right, so that's what's supposed to be there. Under normal circumstances Standalone should show the same thing, but it seems it isn't for some reason. If it wasn't using the PAC file I would expect it to fall back to using a direct connection, but it looks like it's breaking in some other way.

    I was able to reproduce some problems loading a PAC file in earlier versions of Standalone, but 3.0.14 appears to be working fine for me. If this just started happening and was working before, there's a good chance it's related to the latest version of XULRunner bundled with 3.0.14, so you could try rolling back to 3.0.11 to see if that fixes things. (You can just replace "3.0.14" in the download URLs.) If that does fix it, we'll try to figure out what broke this for you in XULRunner.
  • Downgrading works.

    Was able to grab a cite/pdf through Chrome, and after the Mozilla proxy authentication window popped up, and the pdf arrived.

    I also can sync.
Sign In or Register to comment.