--new-token hits webserver on localhost?

[bmartin427]

I had this app working a couple years ago, but now found that it no longer does. After thrashing around recreating OAUTH tokens in Google, I finally figured out --new-token is what I actually needed to resolve the expired authentication issue. However, I can't figure out how to get that to work. When I open the URL that gives me, I walk through all of the screenshots shown here successfully. However, it doesn't say what happens after I click the checkboxes and click Continue. For me, the browser then loads an unrelated webpage off of localhost. It's not clear what I'm supposed to do then or paste into the requested 'response token' field. I tried sudo systemctl stop apache2 in case the presence of a local webserver was breaking things, but then I just get a browser error that it can't connect to localhost. In fact, I confirm that the string http://localhost/ appears in the URL I was told to go to in the first place, so not sure how this is supposed to work.

[bmartin427]

FWIW I attempted using Chrome instead of Firefox with the same results.

[bmartin427]

It appears this string exists in the client_secret.json file I downloaded, not sure if this is the problem but I also don't see any settings in Google that might change it. "redirect_uris":["http://localhost"]

[bmartin427]

It appears I've finally had success by copying only the &code= argument from the localhost URL Google redirected me to and pasting it into the terminal prompt. But, if that's really what I was supposed to do here, this is seriously under-documented.

[gilesknap]

Are you running gphotos-sync on a server? The new oauth flow does use localhost only so requires an initial run on a machine with browser.

It is documented here https://gilesknap.github.io/gphotos-sync/main/tutorials/installation.html#headless-gphotos-sync-servers but I just realized that this is the containers documentation and it's not mentioned for running natively on a server.

The trick of copying the argument also sounds like an OK workaround and may be helpful to others. Would you be interested in adding a step by step description of what you did to the docs via PR?

Thanks

[bmartin427]

It's not a server in the sense of being headless, no. It's a desktop that happens to be running a webserver though (mythweb on apache, in this case).

I could try to update the docs, but I'm afraid I still don't really understand what was supposed to happen, so it's unclear what needs updating. Was gphotos-sync actually trying to serve a page on port 80 to catch the browser redirect? I didn't run it as root so I'm not sure how it could have bound to that port. I thought maybe the redirect URL was supposed to have a different port appended to it, but lsof didn't indicate that gphotos-sync had any ports open at that point.

[gilesknap]

Hmm. You are correct that the google library spins up a server to catch the redirect. However it should be using port 8080 by default so something else is wrong. Is your server also listening on 8080?

[bmartin427]

I have nothing running on 8080, no, but the Google redirect was trying to hit 80, not 8080.

[gilesknap]

So I've just tried this on my setup with --new-token and it works. I'm going to post some info for you to compare against so we can see where the discrepancy is.

The redirect URL is:

http://localhost:8080/?state=xx_REDACTED_xx&scope=https://www.googleapis.com/auth/photoslibrary.readonly%20https://www.googleapis.com/auth/photoslibrary.sharing

My client_secret.json looks like this:

{
    "installed": {
        "client_id": "00_REDACTED_00.apps.googleusercontent.com",
        "project_id": "gk-gphotos",
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_secret": "xx_REDACTED_xx",
        "redirect_uris": [
            "http://localhost"
        ]
    }
}

Interesting to note that the redirect URI does not specify the 8080 port but that it does use 8080.

[gilesknap]

One thing that may be worth checking is did you create a new virtual env for the new install of gphotos-sync?

There have been reports that I need to supply some min versions for some dependencies. So a workaround is to create a new venv.

[bmartin427]

I did not, I just did pip3 install --user gphotos-sync on Ubuntu 20.04.

Sure enough: with the install I've been using, the URL that gphotos-sync asks me to open in a browser contains &redirect_uri=http%3A%2F%2Flocalhost&scope=.... But, I reinstalled in a venv and now the URL is &redirect_uri=http%3A%2F%2Flocalhost%3A8080%2F&scope=.... So only the new install put the :8080 port on the initial URL. I also confirmed that visiting that URL completes successfully after authorization, and it no longer prompts me to paste something back into the terminal.

After that, I then tried an uninstall and a reinstall outside of the venv, and now that is working too. So apparently I just ended up with a broken install somehow? :confused:

Anyway, thanks for the help! I guess there's no actual problem here and this can just be closed.

[gilesknap]

Thanks for letting me know. The problem is just that you had old versions of the dependencies, probably the google auth module itself was out of date.

I need to fix my dependencies in setup to have a min version.