You should be presented with a very long Google authentication URL (this was what was just open in the text browser.) Go ahead and copy this into your browser on your desktop in a separate tab (make sure to leave the calibre-web page up) and you should be able to perform oauth authentication the same as usual.Now if you could login here, life would be peachy, but unfortunately captchas and text browsers don't mix, so go ahead and quit out of the browser. At this point it will appear to hang as always, but if you check your terminal, you should find a Google login page open in whatever browser is your default. On your normal machine, navigate to the mail settings and click the button.Open a terminal to your server and launch calibre-web in the foreground with "python /path/to/cps.py".My jail had w3m available and working by default, so that's what I used. Note that you WILL need some sort of browser, text-based is fine. So, assuming you're running from an environment where you don't have (or want) a GUI and therefore don't have a graphical browser, here's how I got it to work. That's when I realized the server itself was trying to complete the authentication. My first clue came from noticing the text of a Google login page had been recorded in the nohup.out file.
In my case, I'm running from a TrueNAS FreeBSD jail, but the symptoms of the problem were identical.
So I was in a similar boat as and I think I figured out a (very convoluted) workaround. However, it also looks like this potential limitation was resolved last year. That would be a way to possibly run the output to stdout/stderr, which would show in the Docker containers logs. Which describes what you are referring to. Googleapis/google-auth-library-python-oauthlib#87 It seems like the port isn't random, you can specify a specific port to run the auth on. In which case, you could easily make this a static port - or if running in a container environment, specify a static port: Unless I am looking at the wrong file, is this the location where you are specifying the random port?
You specify the webserver, so I am not sure why you are stating it is random. This doesn't seem like a blocker or technical limitation due to using containers. It seems like other developers are able to work around this from within the a docker container. There are also alternatives for oAuth flows: So want to claim that I am not an expert here, just trying to explore other ideas to get this to work. Open up Google oAuth flow to validate the Service AccountĮnvironment (please complete the following information):
0 kommentar(er)
