-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access token specified to resync-sync is not exposed to resync.Client instances #45
Labels
Comments
6 tasks
Thanks for finding that @anarchivist! I'd forgotten that some of this code might have been recent enough to use |
|
This was referenced Mar 19, 2021
Seems to make a valid request with token to download actual dump from POD now (haven't waited for completion however):
|
Fantastic, thanks @zimeon - I can confirm it seems to be working to fetch the normalized dumps based on what's in |
Released in 2.0.1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As @zimeon knows I've been trying to put
resync
through its paces to harvest from the POD data lake, and specifically trying to useresync-sync
(to provide a readymade solution). While #37 added support for Bearer tokens (as needed by POD), it appears that the--access-token
parameter doesn't propagate down to the instance ofresync.Client
, namely the update_resource() method.For what it's worth, would it be possible to pass or instantiate the same header configurations from the
CONFIG
global set inresync.url_or_file_open
, to also allow the delay/backoff, and to set theUser-Agent
header? Thanks for considering.Discovered while looking into pod4lib/aggregator#324.
The text was updated successfully, but these errors were encountered: