Skip to content
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

problem with github synchronization #321

Open
monperrus opened this issue Dec 15, 2024 · 5 comments
Open

problem with github synchronization #321

monperrus opened this issue Dec 15, 2024 · 5 comments

Comments

@monperrus
Copy link
Contributor

monperrus commented Dec 15, 2024

I notice that I cannot sync anymore to Github.

The error is "Username exists but Token Failure"

        if ErrorString = UserName then begin     // "A" valid username
            ErrorString := '';
            TokenExpires := HeaderOut;
            if DebugMode then debugln('TGithubSync.TestTransport - Confirmed account exists');
            if TokenExpires = '' then begin
                ErrorString := 'Username exists but Token Failure';
                exit(SyncCredentialError);              // Token failure
            end;

https://github.com/tomboy-notes/tomboy-ng/blob/master/source/transgithub.pas

I triple-checked the token, so it seems that HeaderOut or TokenExpires = '' is wrong.

@davidbannon
Copy link
Member

Hmm, that does look very much like a token failure I am afraid. If github does not return an expire date for a token, its because its failed (for some reason) to authenticate using that token.
Because the token has expired but also, possibly because it does not grant the appropriate permissions.
Have you tried generating a new token ? From memory, they offer a 'new' token model, I choose the 'traditional' offering, don't, yet understand what that new model is or the implications for our usage. I do understand that their increasing severe security is a pain. But, I guess, a necessary pain.

I doubt Github has changed the API, mine is working fine. But maybe I had better check the API doc, just in case. It sure has changed in the past ...

David

@monperrus
Copy link
Contributor Author

monperrus commented Dec 16, 2024 via email

@davidbannon
Copy link
Member

yes. I'm sure the token is not expire

There can be other problems with the token apart from it expiring. Github has introduced a much finer grain control on the token, to limit what it can do to specific tasks. Might be a good idea but I have not investigated. I am wondering if your problem is that your token, while not expired does not grant you the appropriate permissions.

So, when creating a token, choose "Classic" then in the next screen, tick the Repo Scope box.

I just generated a new token, as above, and its working fine. I see this when I run (after stopping any existing tomboy-ng instance)-
$> tomboy-ng --debug-sync

(trigger a sync)

....
TGithubSync.TestTransport - WriteNewServerID is True
TGithubSync.TestTransport - about to get auth-token-expire
URL=https://api.github.com/users/davidbannon
TGithubSync.TestTransport - Downloader got token-exp data, good
TGithubSync.TestTransport - Confirmed account exists
TGithubSync.TestTransport : serverID is 3EE3361D-615F-4ABA-82FF-029D9D6FEE3E
TGitHubSync.TestTransport SelectiveSync=SyncGithub
TGitHubSync.TestTransport SelectiveSync is OK
....

I assume you have tried the debug-sync option, you see the line about "about to get auth-token-expire" and "Confirmed account exists" and then see the message about "Username exists but Token Failure" ?

Are you seeing any other error messages ? Particularly from TGitHubSync.Downloader ?

What I understand here is that github is accepting your token, checks the username is OK (proving the call was successful) but does not return an an authentication header, perhaps because the token permissions does not allow it to ?

Unless we are seeing other (transport) errors, it sure looks like the token is not acceptable to github for what we are trying to do. Please check for the other error messages ?

Davo

@monperrus
Copy link
Contributor Author

Did some more debugging, and looked at headers with curl.

I confirm that the authenticated Github answer, with a working token, does not contain header github-authentication-token-expiration.

$ curl -v -H "authorization: Bearer ghp_XXXXX"  https://api.github.com/users/monperrus
< HTTP/2 200 
< date: Sat, 21 Dec 2024 07:56:43 GMT
< content-type: application/json; charset=utf-8
< content-length: 1401
< cache-control: private, max-age=60, s-maxage=60
< vary: Accept, Authorization, Cookie, X-GitHub-OTP,Accept-Encoding, Accept, X-Requested-With
< etag: "04349afa6cd1dd4c906495ce020c853227ef0e992589e703e10d11513d92275f"
< last-modified: Sat, 14 Dec 2024 12:21:36 GMT
< x-oauth-scopes: repo
< x-accepted-oauth-scopes: 
< x-github-media-type: github.v3; format=json
< x-github-api-version-selected: 2022-11-28
< x-ratelimit-limit: 5000
< x-ratelimit-remaining: 4999
< x-ratelimit-reset: 1734771403
< x-ratelimit-used: 1
< x-ratelimit-resource: core
< access-control-expose-headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
< access-control-allow-origin: *
< strict-transport-security: max-age=31536000; includeSubdomains; preload
< x-frame-options: deny
< x-content-type-options: nosniff
< x-xss-protection: 0
< referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
< content-security-policy: default-src 'none'
< server: github.com
< x-github-request-id: 8876:3B9037:24315F:2F0D48:676674BB

No idea why.

@davidbannon
Copy link
Member

Right, useful info indeed. My header looks (functionally) indntical to yours except I have that expiry date.

Martin, apparently its possible to create a classic token with no expiry date. I imagine the token will work fine but I have assumed all tokens will have an expiry. Perhaps that is not a good idea ?

Is it possible that the token you are using does not, in fact, have an expiry date ?

Obviously, tomboy-ng has no interest in the expiry date apart from keeping the user informed. I can, and should 'adjust' the code to proceed if it does not detect one. Its just that was a suitable test of the first header back to ensure we talking correctly.

I am currently away from home dealing with a family problem and don't have all my test hardware available. But I could, I assume, cut you a test binary that allows the sync to proceed even if no expiry is found. I should be able to pick something else out of the header to use as a comms check.

What platform do you use ? (Windows, Mac, Linux [gtk2, qt5, qt6])

Davo

davidbannon added a commit that referenced this issue Dec 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants