shiftkey/desktop

Can't log into my account

Closed this issue · 19 comments

The problem

When i click to log in with my github account, I'm redirected to github website confirm the login. But when i come back to Github Desktop, its not logged in my account. Why? Im using Ubuntu 24.2

Release version

Version 3.4.2-linux1 (x64)

Operating system

Linux Ubuntu 24.2

Steps to reproduce the behavior

No response

Log files

No response

Screenshots

No response

Additional context

No response

Same issue, no response, Debian 12 bookworm.
FastFetch

Same issue on kubuntu 24.04

Screenshot_20240923_121446

I guess it's not GitHub desktop's fault, I met the same problem with Unity Hub today, the Unity Hub didn't response to the login protocol. The Unity Hub protocol is: unityhub:// and GitHub desktop's protocol is neither supported.
Edit 1: got this thread: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/ZERZXDKGTJXBAEVMBTOAEI32EQ4VOK4L/
This thread is about the magnet URI things and almost the same issue, small difference is that magnet URI have a default application, but neither GitHub login URI nor Unity Hub URI have default application.
The thread is sooo long that it has made me headache. Suggest concluding the solution of the thread.

I got a solution, but it's just a temporary one as it doesn't solve the basic issue.
You can login to GitHub like this:

Step 1: find the binary executable file of GitHub Desktop

For me it's in /usr/bin, so:

cd /usr/bin 

If the file isn't here, you can try:

whereis github-desktop

Step 2: login to GitHub

Execute a GitHub Desktop, be aware that a new window should be launched, or login process will fail, choose File - options - Accounts, choose sign in to GitHub.com, continue with browser.
Then a browser window should pop up, asking to login. After logging in, there should be You are being redirected to the authorized application., below this there's a please visit this setup page to continue. Copy the "the setup page" link, should be like this: x-github-desktop-dev-auth://oauth?code=somecodehereandsomethingelse.

Step 3: copy this and launch GitHub Desktop

Run this command in that terminal:

./github-desktop "x-github-desktop-dev-auth://oauth?code=somecodehereandsomethingelse"

Then you should find yourself logged in to the GitHub Desktop.

This method also works for Unity.

@konotorii @AryFarah This method should be useful for you.

Having the same issue on a fresh new linux account it's an endless loop of login with browser and then the app does nothing. and the solution posted doesn't seem to work for me

Having the same issue on a fresh new linux account it's an endless loop of login with browser and then the app does nothing. and the solution posted doesn't seem to work for me

Not sure, suggest waiting for other solutions. I can't recurrent this issue.

Worked after updating Linux Mint here, from a clean .iso no luck, tried also the method of rong-xiaoli with no luck, I am on Version 3.4.4-linuxbeta2 (x64)

xiaoli

Can't verify I did sudo apt update sudo apt upgrade no fix. I also tried creating a new linux mint account and re-installing github desktop

Can confirm on Linux Mint 22 and Kubuntu 24.4, on both firefox and chromium. The suggested solution doesn't work

2024-10-07.desktop..log
Here's the log, after clearing the program's config file and retrying. It seems to try to advance to step ConfigureGit and then fails

I have tried the process today, and it worked. Both on a Mint 21 live-CD and installed Mint 22.

What has changed:

Instead of working on a school network with PEAP authentication(WPA2 Enterprise), I did this on my home network that has WPA2 Personal.
I have also first launched my system's Keyring application, then locked and unlocked the logins
@jredfox @chaoscalm @konotorii @AryFarah

It could be a bug with the keyring handling instead? After all, the app does log Adding the login information to the AppStore

I have tried the process today, and it worked. Both on a Mint 21 live-CD and installed Mint 22.

What has changed:

Instead of working on a school network with PEAP authentication(WPA2 Enterprise), I did this on my home network that has WPA2 Personal. I have also first launched my system's Keyring application, then locked and unlocked the logins @jredfox @chaoscalm @konotorii @AryFarah

It could be a bug with the keyring handling instead? After all, the app does log Adding the login information to the AppStore

I major java not linux C++ so I can't fix it I am as stuck as you are right now. With my minecraft DPI-Fix mod there wasn't enough documentation found on how to prevent app scaling on common window types that's how limited my knowledge of linux C++ is

I major java not linux C++ so I can't fix it I am as stuck as you are right now. With my minecraft DPI-Fix mod there wasn't enough documentation found on how to prevent app scaling on common window types that's how limited my knowledge of linux C++ is

Oh I just wanted to notify the people to see if messing with the keyring would help

I got a solution, but it's just a temporary one as it doesn't solve the basic issue. You can login to GitHub like this:

Step 1: find the binary executable file of GitHub Desktop

For me it's in /usr/bin, so:

cd /usr/bin 

If the file isn't here, you can try:

whereis github-desktop

Step 2: login to GitHub

Execute a GitHub Desktop, be aware that a new window should be launched, or login process will fail, choose File - options - Accounts, choose sign in to GitHub.com, continue with browser. Then a browser window should pop up, asking to login. After logging in, there should be You are being redirected to the authorized application., below this there's a please visit this setup page to continue. Copy the "the setup page" link, should be like this: x-github-desktop-dev-auth://oauth?code=somecodehereandsomethingelse.

Step 3: copy this and launch GitHub Desktop

Run this command in that terminal:

./github-desktop "x-github-desktop-dev-auth://oauth?code=somecodehereandsomethingelse"

Then you should find yourself logged in to the GitHub Desktop.

This method also works for Unity.

@konotorii @AryFarah This method should be useful for you.

Works! Thx (Version 3.4.3-linux1 (x64))

Which browser is involved here? I keep seeing these sorts of reports but understanding why the app's protocol handlers aren't working here seems to vary based on each setup, and the instructions to run this command are literally what xdg-open should handle 🤔

Run this command in that terminal:

./github-desktop "x-github-desktop-dev-auth://oauth?code=somecodehereandsomethingelse"
Then you should find yourself logged in to the GitHub Desktop.

I have encountered this issue on both Firefox bundled with the installation of my Linux(Mint 22 and Kubuntu 24.4), as well as Chromium browser installed via Apt(Mint 22). Both on otherwise fresh installs.

It didn't happen on a LiveCD Mint 21, I haven't tested the others since. I can only notice a pattern of this happening on Latest released distributions

the handlePossibleProtocolLauncherArgs@main.ts argument has been changed to an array since 3.4.2.

For example, in Garuda Linux + Chomium, the following values are included:

args[0]: ./desktop
args[1]: --allow-file-access-from-files
args[2]: ./resources/app/cli.js
args[3]: x-github-desktop-dev-auth://oauth?code=XXXXX&state=XXXXX-XXXX-XXXX-XXXX-XXXXXXX

in Windows + MS-Edge, the following values are included:

args[0]: D:\Documents\github\desktop\dist\GitHubDesktop-win32-x64\GitHubDesktop.exe
args[1]: --protocol-launcher
args[2]: --allow-file-access-from-files
args[3]: x-github-desktop-dev-auth://oauth?code=XXXXX&state=XXXXX-XXXX-XXXX-XXXX-XXXXXXX

So it may be sufficient to simply check for the existence of x-github-desktop-dev-auth (or x-github-desktop-auth) and pass it to handleAppURL.

https://github.com/shiftkey/desktop/blob/linux/app/src/main-process/main.ts#L255-L297

function handlePossibleProtocolLauncherArgs(args: ReadonlyArray<string>) {
  log.info(`Received possible protocol arguments: ${args.length}`)

  if (__WIN32__) {
    // Desktop registers it's protocol handler callback on Windows as
    // `[executable path] --protocol-launcher "%1"`. Note that extra command
    // line arguments might be added by Chromium
    // (https://electronjs.org/docs/api/app#event-second-instance).
    // At launch Desktop checks for that exact scenario here before doing any
    // processing. If there's more than one matching url argument because of a
    // malformed or untrusted url then we bail out.

    const matchingUrls = args.filter(arg => {
      // sometimes `URL.parse` throws an error
      try {
        const url = URL.parse(arg)
        // i think this `slice` is just removing a trailing `:`
        return url.protocol && possibleProtocols.has(url.protocol.slice(0, -1))
      } catch (e) {
        log.error(`Unable to parse argument as URL: ${arg}`)
        return false
      }
    })

    if (args.includes(protocolLauncherArg) && matchingUrls.length === 1) {
      handleAppURL(matchingUrls[0])
    } else {
      log.error(`Malformed launch arguments received: ${args}`)
    }
  } else if (__LINUX__) {
    // we expect this call to have several parameters before the URL we want,
    // so we should filter out the program name as well as any parameters that
    // look like arguments to Electron
    const argsWithoutParameters = args.filter(
      a => !a.endsWith('github-desktop') && !a.startsWith('--')
    )
    if (argsWithoutParameters.length > 0) {
      handleAppURL(argsWithoutParameters[0])
    }
  } else if (args.length > 1) {
    handleAppURL(args[1])
  }
}

function handlePossibleProtocolLauncherArgs(args: ReadonlyArray<string>) {
  log.info(`Received possible protocol arguments: ${args.length}`)

  for (const arg of args) {
    if (
      arg.includes('auth://oauth') &&
      arg.includes('code=') &&
      arg.includes('state=')
    ) {
      handleAppURL(arg)
      return true
    }
  }
  log.error(`Malformed launch arguments received: ${args}`)
  return false
}

Thank you for your issue!
We haven’t gotten a response to our questions above. With only the information that is currently in the issue, we don’t have enough information to take action. We’re going to close this but don’t hesitate to reach out if you have or find the answers we need. If you answer our questions above, this issue will automatically reopen.