Google Drive buttercup:// protocol not working on Linux

[CatmanIX]

When attempting to connect to Google drive, bcup-desktop successfully opens a tab in waterfox in which I can successfully log in and grant permissions to bcup, however, upon completion with Google, the browser is temporarily sent to buttercup.pw before attempting to redirect to some address using a "buttercup://" protocol which fails due to waterfox not knowing what to do with this protocol.

I attempted to set the default browser to the only other browsers on my system (waterfox-current and seamonkey) with similar results on seamonkey (and a complete failure to function on wf-currents part which I'll have to sort out later, not bcups fault). I'll install and attempt to use other more "modern" browsers (brave? opera?? chrome???) later, may take time on my internet though and any other app I've needed to authenticate through wf-classic hasn't had this kind of issue so I really don't want to have to.

Alternatively, if anyone can recommend how to use syncthing to synchronize a vault between desktop and the android app that would be great, I can't find any "local file" option for the mobile vault or any way to configure st running on a desktop as a WebDAV server, otherwise I wouldn't be bothering with gdrive

[CatmanIX]

Update: still trying to dl brave-bin, but i've tried opera. oddly, when faced with the "buttercup://" protocol it requests to allow xdg-open to handle the link, which then sends it to seamonkey??? I'll examine if i can fix through xdg-open next

[perry-mitchell]

Hmm, Buttercup registers the protocol via Electron - it should work for most common operating systems. What distro are you running? Is there some way you can check via XDG or something which protocols are registered? Of course this link should be executed by Buttercup Desktop to allow the result of the authentication to be registered. Google requires auth via the browser of course, unlike Dropbox (that still uses the in-app browser to authenticate).

[perry-mitchell]

On another note, our next app major release (in the works) will have local vault support (on-device), though we still recommend using a cloud service to host, either by a 3rd party or hosted yourself.

[MariusCC]

Hmm, Buttercup registers the protocol via Electron - it should work for most common operating systems. What distro are you running? Is there some way you can check via XDG or something which protocols are registered? Of course this link should be executed by Buttercup Desktop to allow the result of the authentication to be registered. Google requires auth via the browser of course, unlike Dropbox (that still uses the in-app browser to authenticate).

I get the same issue: new vault creation in buttercup send me to the default browser for google auth, but the result even if it's opened by xdg-open (see the mime type bellow) doesn't get parsed by buttercup, thus preventing a vault to be created. On google drive there is no new file created and no app data stored.

I'm using:

• Cinnamon 4.8.6
• Linux 5.11.10-1-MANJARO
• Chromium Version 90.0.4430.72 (Official Build) Arch Linux (64-bit).
• Buttercup-linux-x64-2.2.0.AppImage

I have a ~/.local/share/applications/buttercup.desktop file with following content:

Exec=~/bin/Buttercup-linux-x64-2.2.0.AppImage
Icon=~/bin/Buttercup-linux-x64-2.2.0.AppImage
Type=Application

In the mime file I have the line bellow:

cat  ~/.config/mimeapps.list|grep butter
x-scheme-handler/buttercup=buttercup.desktop

[jandrioli]

I confirm this is also happening on Ubuntu 20.4 x64 I made a .desktop file to launch buttercup, and I my browsers can launch the appimage via the handler buttercup:// but when the app launches it does not see the authentication from google drive...

[lbathory]

I am really, really sad. Until now I used buttercup from my different linux desktops very satisfied, but this is really disappointing. I dont know where do you store your vaults, I used google Drive but now, I can not open it. I authenticate (tried firefox and chromium) buttercup to use gdrive, browser tries to open some buttercup:// (I assume), buttercup window gets back the focus and NOTHING else happens...

[openPablo]

This happens in Fedora 34 with gnome 40 too.

[tdislay]

After 1 hour I've found a temporary solution (Manjaro, Buttercup installed from the Archlinux User Repository): First remove / comment the line x-scheme-handler/buttercup=buttercup.desktop" in the file "~/.config/mimeapps.list Then start chromium (I haven't tested for firefox, dunno sometimes you can't see logs in terminal) from the terminal Then launch buttercup and try to authenticate to your google drive account from chromium (if it doesn't launch in chromium, simply copy / paste the URL). As a result, you will get an error, in the terminal gio: buttercup://auth......./...consent: The specified location is not supported Select and copy the buttercup://auth...consent part; And paste it in a terminal as an argument for the binary of buttercup : buttercup "buttercup://auth...consent" (quotes are importants)

I'm sorry for my poor english and bad explanations, I hope it will help someone (at least the users)

PS : Also, thanks for buttercup, amazing app <3

EDIT: markdown

[machariamuguku]

For anyone not able to authenticate to google drive after installation on ubuntu (google drive not redirecting back to buttercup app after authentication), also make sure you have AppImageLauncher installed. Make the AppImage launcher executable, run, select run with AppImageLauncher. You're welcome

[bouteillerAlan]

Hi, don't know if this information is relevant, but the problem is present for me too :

• firefox developer edition 112.0b8 (64-bit)
• endeavour os (cassini nova & kernel 6.2.8-arch1-1 (64-bit))
• buttercup desktop installed via the AUR (2.18.2-1)

I delete all my extension, the problem is still there (related to https://github.com/buttercup/buttercup-desktop/issues/1185#issuecomment-1412701929)

If you need help or more information, don't hesitate :)

[Nyaaa]

Same here, got this problem on current Arch. Firefox was blocking the request, chromium was sending it to xdg-open, which was doing nothing. Finally managed to solve this using @tdislay 's method above, but only after a bunch of failed attempts.

Version: buttercup-desktop 2.20.2-1 installed via AUR

[tdislay]

Weird.. It seems to be fixed for me (aur/buttercup-desktop 2.20.2-1)

[bryan-pakulski]

Also ran into this issue using latest appimage (v2.21.0) on Arch linux:

OS Details

KDE: 5.27.9 Kernel: 6.5.9-arch2-1 (64bit) Firefox: 119.0

Using the suggestion from @machariamuguku seemed to do it, after installing appImageLauncher and "Integrating" buttercup Firefox would prompt to actually open the XDG link after authenticating google drive access.

And a closer look at the ReadMe has a recommendation to use appImageLauncher specifically for this reason.

But still, not sure if there's any way easy way around using the appImageLauncher and have the buttercup.AppImage look after xdg links without any dependencies.

Looking at the .desktop entry that appImageLauncher creates it looks like it sets the mimetype for xdg:

MimeType=x-scheme-handler/buttercup;

Also the .desktop file it generates is then also registered if you query for the type:

> xdg-mime query default x-scheme-handler/buttercup
appimagekit_a4a68fe0e8f65edbc7aeeff924ce1178-Buttercup_Password_Manager.desktop

I'm not familiar with electron apps but perhaps there's a way to make sure the appimage registers itself with xdg appropriately at runtime?

[Oxalin]

I'm on it. We need to tell electron builder to create a .desktop file where we define the mimeTypes. I'll work on the package.json file a keep in touch.

[Oxalin]

Ok, so here is the thing. The desktop integration seems to have been dropped from electron apps. They suggest to use AppImageLauncher for AppImages. On the other hand, electron apps don't deal with .desktop files in any other target other than AppImage: they don't create them, they don't update them. There is a function used for both Windows and macOS, but it seems to do nothing under Linux.

For any native packages, the .desktop file must be manually created and integrated.

For AppImage packages, the .desktop file will be created for you if used with AppImageLauncher.

There was a missing field in package.json that I added and it will be added to the next release, but I'm not sure it will change a lot. On my side, testing with the AppImage package, it works fine. If some wants to test it, let me know, I'll provide a link to download the latest version.

Also, what I could do is provide a .desktop template file. Native packages could bundle the file and update its content accordingly. Would that help?

[Oxalin]

@perry-mitchell could you assign this issue to me please?

[Oxalin]

Hmm, Buttercup registers the protocol via Electron - it should work for most common operating systems. What distro are you running? Is there some way you can check via XDG or something which protocols are registered? Of course this link should be executed by Buttercup Desktop to allow the result of the authentication to be registered. Google requires auth via the browser of course, unlike Dropbox (that still uses the in-app browser to authenticate).

I get the same issue: new vault creation in buttercup send me to the default browser for google auth, but the result even if it's opened by xdg-open (see the mime type bellow) doesn't get parsed by buttercup, thus preventing a vault to be created. On google drive there is no new file created and no app data stored.

I'm using:

* Cinnamon 4.8.6

* Linux 5.11.10-1-MANJARO

* Chromium Version 90.0.4430.72 (Official Build) Arch Linux (64-bit).

* Buttercup-linux-x64-2.2.0.AppImage

I have a ~/.local/share/applications/buttercup.desktop file with following content:

Exec=~/bin/Buttercup-linux-x64-2.2.0.AppImage
Icon=~/bin/Buttercup-linux-x64-2.2.0.AppImage
Type=Application

In the mime file I have the line bellow:

cat  ~/.config/mimeapps.list|grep butter
x-scheme-handler/buttercup=buttercup.desktop

Are your AppImage packages installed under ~/bin/? AppImageLauncher defaults to ~/Applications/.

Also, you may need to modify the Exec value. According to the Desktop entry specification: "The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment." Your value is a relative path, which is not covered/prohibited by the standard. https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

[perry-mitchell]

Interesting that it's so convoluted. The protocol has worked on all my OSes in the past (Mac, Linux and Windows), I need to retest today. I wouldn't think any further configuration would be necessary.

If we do change this, it has to work out of the box for all installation methods. Not sure how the portable release will handle it though. Maybe we need an option to copy the value and then paste it back in the app?

[Oxalin]

After some more investigations yesterday night, I must correct myself. It seems packaged apps are probably working properly: I enabled deb and rpm packaging and they include a .desktop file as expected and where expected. However, I can't test them since I'm on Arch. If someone is willing to test it on a different distribution, raise your hand.

In details - Under linux, there is no API call or registry that can be used as under macOS and Windows. So setAsDefaultProtocolClient() relies on some tools that should be available for standard desktop managers (xdg-utils must be available). Then, Buttercup must be able to execute xdg-settings (precisely "xdg-settings set default-url-scheme-handler buttercup buttercup.desktop"). And I'm pretty sure this is exactly where it fails with AppImage since AppImageLauncher changes the .desktop file's name. On the other hand, AppImageLauncher seems to use the provided buttercup.desktop file to create its own when we choose to integrate the AppImage. I suspect the problem is/was coming from there if the file was incomplete. While setAsDefaultProtocolClient() fails when we trace the LogInfo, AppImageLauncher seems to do the work for us. I haven't had any problem with the latest version when I integrate it (it doesn't work if I choose to run it once).

Since Buttercup implements its protocol handling pretty much with the same logic as Heroic Games Launcher (check if already the protocol handler; if not try to set it; throw an error if we fail), I'll test Heroic Games Launcher to see if it works. Also since electron doesn't output any debug info if it fails when executing "xdg-settings set...", I'll dig in the debugger. And I will also create my own native ArchLinux package to test it better with native packages.

[Oxalin]

Hi, don't know if this information is relevant, but the problem is present for me too :

* firefox developer edition 112.0b8 (64-bit)

* endeavour os (cassini nova & kernel 6.2.8-arch1-1 (64-bit))

* buttercup desktop installed via the AUR (2.18.2-1)

I delete all my extension, the problem is still there (related to #1185 (comment))

If you need help or more information, don't hesitate :)

Digging in the AUR package reveals it is broken: the .desktop file is wrong, mostly because it doesn't add the "%u"/"%U" argument, This argument is needed to tell the desktop manager it should forward the URI to the application.

[Oxalin]

Same here, got this problem on current Arch. Firefox was blocking the request, chromium was sending it to xdg-open, which was doing nothing. Finally managed to solve this using @tdislay 's method above, but only after a bunch of failed attempts.

Version: buttercup-desktop 2.20.2-1 installed via AUR

See https://github.com/buttercup/buttercup-desktop/issues/987#issuecomment-1849089310 for explanation. The .desktop file in the AUR package is incomplete.

[Oxalin]

So, after some investigation: the .desktop file is/was broken in the packages provided under AUR (ArchLinux). Once fixed, it now works properly (package buttercup-desktop is fixed, buttercup-desktop-bin is a mess).

AppImages are working fine, tested under 2.24.4

We can close this issue.