Access-granting dead end

[brad]

Hi all,

I've written a script that uploads files to Youtube via googlecl. It
works perfectly. The first time I ran it, I got the "Please log in and/
or grant access via
your browser at https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=..."
notice. Of course, I visited this link in lynx and granted access to
my machine and all is well.

The whole idea behind this script is to run as a cron job at night.
When it runs as a cron job, it wants me to grant access again, even
though it is running on the same machine, under the same user, with
the same conditions. I tried copy-pasting the URL into a browser, and
google seems happy with my access-granting, but when the script runs
again it asks me to grant access again with a different token.

I'm about at wit's end... Is there any way to store authorization
tokens or bypass this process? I obviously can't log into Google every
time cron runs this script... Any ideas?

Here is how I am calling googlecl in my script:

/share/HDA_DATA/.qpkg/Python/bin/google youtube post $f --user
"us...@gmail.com" --devkey "$devkey" --category "$category" --owner
"ytuser" --summary "$desc" >> $p"log.txt"

I'm running this on a QNAP NAS, though I doubt that's relevant...

Thanks for your help!

Brad

[Bernie]

Hey Brad,

I found GoogleCL today and run a Qnap too.

Any problems during the installation?

I NEED the Youtube Upload feature. :-)

Bernie.

[Richard]

I'd also really like to see an answer to this problem!

[Richard]

It looks like answers are fairly hard to come by. I was digging into ENV variables for cron, interactive cron sessions, any ways to deal with this from within googlecl, but I couldn't find anything.

My workaround was to just symlink the user folders, containing authentication token and settings, to the crontab's home folder, which is the root of the file system in my case. 

# cat /etc/crontab

$ cat /etc/crontab 

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

MAILTO=root

HOME=/

# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

5 * * * * root /usr/local/bin/google-contacts.sh

/root/.config/googlecl/config  <-- Contains Google username and preferences

/root/.local/share/googlecl/access_tok_myusername  <-- Contains authentication token

ln -s /root/.config/ /
ln -s /root/.local/ /

 

This worked for me. I didn't want to try changing crontab home folder since that could affect many other jobs. The 'right' workaround would probably be to assign ENV variables to that particular cron job. I took a shot at that quickly but didn't have much success. I didn't try very hard though!

This fix isn't being used on a production system though. It's a single purpose box with nobody else accessing it, so the solution above will suite my needs for now.