Unable to do first set up using docker container #414
Comments
|
Please can you try changing your image as follows: image: ghcr.io/gilesknap/gphotos-sync:3.04 |
|
@gilesknap Thanks for checking and your help! I was expecting I removed the container and recreated with Unfortunately, the error is still the same after opening http://localhost:8080 : If I follow the authorization URL, after recreating the container, it would again throw an expected CSRF error: Loading http://localhost.mydomain.com:8080/ instead leads to the same results. |
|
As a workaround, I will try creating my own OAuth token and passing it to |
|
Yeah sorry about that, this project needs a bit of love but I've not been giving it much attention due to #119. I did a workaround to the redirector by monkey patching the Google library. I made a release in a container only and incorrectly tagged it as 3.04 instead of 3.0.4. I did a proper fix here googleapis/google-auth-library-python-oauthlib#202 but have not re-released gphotos-sync since as this took so long to get accepted I lost momentum. Also have an issue with PRS overwriting the latest docker image which needs fixing. None of this helps your issue. It looks like it's not going to be easy to debug. It seems that the call above to wsgiref.simple_server.make_server should have populated wsgi_app.last_request but failed to do so. This would take some debugging. It may be best to wait until I have re-released the container against the most recent version of google-auth-library-python-oauthlib which has apparently reached v1.0.0 since I last looked. Will try and take the time to look at this on Sat 11th March. |
|
Not at all. Thanks a lot for having a look and replying. Let me know when you redeploy and super happy to test. No rush. From my side, I tried generating the OAuth token using Apps Script and a variant of this code and it seemed to work yesterday. I need to verify the tool can renew the token once it expires, so I will be monitoring it. Update: The workaround does not seem to work. While the token works when it's generated and photos/videos can be downloaded, after some time (I guess once it's expired), I start getting Auth (401) errors: My guess is that once it's time to renew, either the app is not renewing the expired token or, more likely, it's not able to renew the token. One potential issue here is that I generated it using "web" client instead of a "desktop" client (although I adapted Update 2: Generating the token externally as a Desktop one (as per instructions) seems to have worked. |
|
Hi @nitobuendia I've released a new version that uses the latest google auth library. It would be useful to know if this has any bearing on your issue. Thanks. |
|
Seems still broken to me :( docker-compose.yaml Run: docker-compose up Access Docker container exits with code 1. Same http to https rename issue. Access OAuth URL: Then, (re)start docker container. Complete the OAuth URL process. Lands on Docker container exits with code 1. Same CSRF issue. Same happens if I try to access |
|
Thanks for getting back to me. I'm not clear on what you mean by "is this step correct?" Do you only see it going to localhost:8080 without the rest of the OAutth URL? if so then that is wrong. I'm going to step you through what I did to make this work in a container on a server today. Please try my steps and let me know if they work for you. Then we can debug the compose if that is causing the issue. (I'm using podman instead of docker and different folders to you, everything else should be identical, I also use 8090 because there is another gphotos running)
|
|
@gilesknap Thanks for this. Reading your steps, I think I know the problem. I was actually opening http://localhost:8080 in the browser after doing My docker-compose set up seems to work (at least post setup) since I am currently running gPhotos for a few days with 0 issues. When it completes, I will: (1) test with my current set up, without accessing localhost URL first and waiting until the OAuth URL is auto-generated; (2) should that fail, I will follow your exact steps too. Give me a few days since I don't want to risk interrupting the current process which has been running for a few days. If it takes too long, I will generate new credentials (client_secret separate from the one I use now) and test. |
|
OK that makes sense now. I'm going to do some work on the documentation soon. If you have any ideas about how to improve it then let me know. I think I'm going to put the steps I listed above as the recommended approach as it is the simplest way to get things working as long as your browser can route to your container. |
|
@gilesknap I managed to spend some time on this today.
The issue is definitely not on your documentation. This being said, I think there are two options to cover this use case:
Do you have PayPal, or BuyMeABeer? |
|
Thanks @nitobuendia. I just saw this https://stackoverflow.com/questions/33066528/should-i-use-docker-compose-up-or-run It says if you use run you are not exposing the ports. So that will be why you get I can also see a difference between my invocation of docker and what your compose does. I use the flags -it, there is some possibility that this is stopping the oauth library from outputting the auth URL because it sees its not running in a terminal I wonder if this would work? version: '3.3'
services:
gphotos:
image: ghcr.io/gilesknap/gphotos-sync:latest
stdin_open: true # docker run -i
tty: true # docker run -t
restart: "no"
container_name: gphotos
ports:
- '8080:8080'
volumes:
- ./config:/config
- ./photos:/storage
command: "/storage"(Its hard for me to try this as I am a podman user these days) If it does work I;ll add a compose page to the docs as you suggest |
|
That worked. The OAuth was generated fine end to end with For completeness, I've also tried The experience was a bit flaky. The first couple of times it took very long to load the Redirect URL ( However, after a couple of runs, it worked fine somehow, but I couldn't reproduce again. Nonetheless, I think the |
|
Great. Thanks for letting me know. I'll get the docs updated soon |
|
Added document compose to #417 |
Issue
Error:
AttributeError: 'NoneType' object has no attribute 'replace'when trying to access localhost:8080 to kick-off OAuth process.Steps to Reproduce
Following these steps after getting the
client_secret.jsonfrom these steps.Run
docker-compose up(see details below). Output:Access http://localhost:8080 or http://localhost.mydomain.com:8080 (which also points at 0.0.0.0).
Docker container crashes:
The error looks similar to this comment here. One "strange" thing is that the redirect_uri here is always http://localhost:8080 even if I access http://localhost.mydomain.com:8080 where localhost.mydomain.com is pointing at 0.0.0.0.
I can follow the URL, which would redirect back to localhost:8080 with the state and code. However, the container has crashed by then. If I restart the container before completing the process, then I get a different error:
Details
gphotos-sync version: 0.1.dev1+g208a216
(from
docker exec -ti gphotos gphotos-sync --version)docker-compose.yaml
Command to run:
docker-compose upto start container.The text was updated successfully, but these errors were encountered: