Bad credentials after clicking on PR title

[MichalMichalak]

Bad credentials after clicking on PR title

[kpurdon]

Alright, looks like it was some missing permissions on the token that caused that endpoint to fail. After adding permissions (not totally sure which one) that endpoint works. Waiting on another notification to come in to validate.

[setchy]

v5.2.0 is now available.

[kpurdon]

They are api.{hostname}.com/repos/{org}/{repo}/pulls/{number} for me. FWIW the notification for the above comment worked fine.

[MichalMichalak]

Now I've noticed. When you look at the screenshot in previous comment, you can see two requests to the same URL - first fails, second one, 3 lines below - succeeds. First is the result of click, the second gets PRs to populate the list.

When I compared curl of both, turns out that failing one passes null as token in the header:

-H 'authorization: token null'

while the succeeding one passes actual token:

-H 'authorization: token ghp_r...K' \

Could that be the reason?

[setchy]

@MichalMichalak - incredibly helpful, thank you very much. This helps give us an idea of where we need to fix. I'll take a closer look in the morning. Appreciate it.

[MichalMichalak]

It solved my issue 🎉 Thank you

[setchy]

It solved my issue 🎉 Thank you

Excellent! We'll get a new release out shortly

[afonsojramos]

I believe we currently do not support login with token for GitHub Enterprise. If you notice, through that method, you don't even provide the hostname. So you'll probably need to login using the ClientSecret method listed here: https://docs.github.com/en/[email protected]/rest/authentication/authenticating-to-the-rest-api?apiVersion=2022-11-28#using-basic-authentication

[MichalMichalak]

I may be wrong but... 🤔

It worked for me till very recently. Granted, there were auth improvements in my organization recently and there is a chance that the API fails because of this but it doesn't look so according to my current knowledge. I will certainly close this issue if that's the case.

Besides, I can log in and Gitify pulls the list of PRs, so it must be working. At least partially.

[afonsojramos]

Whoops, not a morning person and still waking up here, you're totally right!

Then I am not really sure how you can have bad credentials while being able to fetch the list of PRs.
Might it be the link that is broken? Since it is when you click it that it breaks? Can you debug a bit on your side? Running a local build and adding a few console logs in the NotificationRow component would help

[setchy]

@MichalMichalak does this happen when clicking on all PR titles, or only specific types (if so, which ones)?

[kpurdon]

This is happening for me as well. For me it's all "review requested" types, however i haven't had others yet to try.

[setchy]

Thanks @kpurdon for also confirming.

The heart of the title hyperlink logic is within

gitify/src/utils/helpers.ts

Line 242 in d809809

export async function generateGitHubWebUrl(

For Notification with reason: review_requested (ie: type: PullRequest), Gitify is following this logic:

1. If the notification has a subject.latest_comment_url value, follow it and use the html_url response value
2. If the notification has a subject.url value, follow it and use the html_url response value
3. Fallback to the notification repository.html_url

I have a hunch as to why this may be failing.

@kpurdon or @MichalMichalak - would you be able to confirm the structure of the subject values latest_comment_url or url. Are they in the format https://api.<hostname>.com/repos/<org>/<repo>/pulls/<no>, or https://<hostname>.com/api/v3/repos/<org>/<repo>/pulls/<no>, or something different?

[setchy]

They are api.{hostname}.com/repos/{org}/{repo}/pulls/{number} for me. FWIW the notification for the above comment worked fine.

Thanks @kpurdon. Do you get a valid API response containing the html_url attribute when calling this endpoint with your token?

EDIT: My assumption is this will fail, but if you tried https://<hostname>.com/api/v3/repos/<org>/<repo>/pulls/<no> it would pass

[MichalMichalak]

Sorry for late response. We seem to live on the other side of the globe :D
About the permissions, I am not entirely sure... Turns out that using the same token, I can get PR details by calling API directly with curl.

curl 'https://HOST/api/v3/repos/ORG/REPO/pulls/1764' \
-H 'accept: application/json' \
-H 'content-type: application/json' \
-H "Authorization: Bearer TOKEN"

For some reason, though, Gitify can't. This is how it looks in dev tools:

Console log is not super helpful, stacktrace looks as below:

GET https://HOST/api/v3/repos/ORG/REPO/pulls/1764 401 (Unauthorized)
(anonymous) @ xhr.js:258
xhr @ xhr.js:49
ln @ dispatchRequest.js:51
_request @ Axios.js:170
request @ Axios.js:40
(anonymous) @ bind.js:5
kn @ api-requests.ts:24
Fn @ helpers.ts:73
jn @ helpers.ts:249
In @ helpers.ts:300
(anonymous) @ NotificationRow.tsx:45
(anonymous) @ NotificationRow.tsx:34
onClick @ NotificationRow.tsx:87
...

helpers.ts:303 Uncaught (in promise) pt {message: 'Request failed with status code 401', name: 'AxiosError', code: 'ERR_BAD_REQUEST', config: {…}, request: XMLHttpRequest, …}
In @ helpers.ts:303
await in In (async)
(anonymous) @ NotificationRow.tsx:45
(anonymous) @ NotificationRow.tsx:34
onClick @ NotificationRow.tsx:87
...

[setchy]

@MichalMichalak - I have a build available containing a (hopeful) fix. If you have a moment, could you kindly test it and see if that resolves the token issue - https://github.com/gitify-app/gitify/actions/runs/8521007314