Open lluchs opened 8 years ago
I never used Mono, so I have to dig deeper into it first. I'm not sure whether this could be achieved beacuse some third party libraries may not be Mono compatible. I also highly use .Net 4.5 Async/Await.
Maybe someone can help out?
I believe the issue may be that the CSharpCodeProvider object used in KeePass to compile the plgx files does not reference any dlls by default. Therefore if it is not referenced in the csproj file it can't find the dll to compile and thus the errors you received. Although, I would think the same problem would exist on Windows as well.
I tried adding a reference to System.Threading.Tasks in the project but that caused the compiling to fail because xbuild automatically includes a reference to that dll.
@jdm12989: I saw your fork and your ongoing development in mono/linux support. Many thanks for that.
Are you willing to complete this task and create a pull request for that? Or is your goal to only create your "private" copy (which is also ok for me)?
Yes, all Linux user will be very pleased if you complete and share it!
+1 for Linux support
+1 for Linux support! ...let me know if you need someone to test it...
+1 for Linux support
+1 for Linux support, I'd imagine this would work under Mac OS as well since we're talking mono. If I have time coming up, I'll start looking at making a PR as well.
+1
Please +1
If anyone is familiar with mono, help would be appreciated. I have the plugin running on Linux Mint, but not when it is compiled to a plgx.
I'm not familiar with mono at all, but I'm an adequate search engine user if I could be of use.
Hi @jdm12989,
the upcoming release 1.3.0 will be a huge milestone. In it I have changed some things to be better prepared for mono support. Maybe we can work together on mono support after that?
Regards, Daniel
Hi everyone,
I wanted to use KeeAnywhere on Linux, so although I am a total newbie to the KeePass and C# in general, I tried to use it.
Good news: KeeAnywhere 0.13.0 builds on Mono out of the box ! Bad news: I can't get to be loaded by KeePass 2.34, it keeps telling me that I need a "newer .NET framework", although I am using Mono 4.4.2 which is compatible with .NET 4.5/4.6.
@haudren,
at first: KeeAnywhere compiles on Linux but currently does not work out of the box (because there is some Windows specific code in it). See @jdm12989's fork of KeeAnywhere. I'm trying to pull these changes in the near future.
Comin back to your problem: What kind of "distribution" are you trying? PLGX or DLL? Please check, whether KeePass.exe.config is present. If not, please copy it from the original distribution. It contains a section which makes .Net 4 "available" in this .Net 2 application:
<configuration>
...
<startup>
<supportedRuntime version="v4.0" />
<supportedRuntime version="v2.0.50727" />
</startup>
...
</configuration>
Regards, Daniel
Thanks for your advice ! It doesn't really solve the problem though, but I merged the most recent version of KeeAnywhere with @jdm12989's linux branch, and it seems that now:
However, I can't seem to be able to add an account for sync: there is no "Add..." button. See the screenshot below: I'll try to investigate further later...
It seems the Forms/SettingsForm does not resize it's content correctly. Maybe it has to do with the anchors I set for several controls (like Top, Left, Bottom, Right for the ListView control). Try switching it to something static - maybe then the "hidden" or "dislocated" controls become visible.
Thanks, I moved the controls around and they now appear! But now, whenever I click on "Add... -> Google Drive", the application crashes with:
libgluezilla not found. To have webbrowser support, you need libgluezilla installed
Followed by a NullReferenceException
. This does look like a Ubuntu-specific problem, maybe @jdm12989 can help.
Hello everyone,
On Arhclinux, I have got this error
I have checked the keepass.exe.config, I have the right .Net version. What did you do to pass this check ?
@ronki2304 Just to make clear: my original distribution of KeeAnywhere currently does not support Mono. You need to use a fork of e.g. @jdm12989 and compile it by yourself. But as far as I see he doesn't use the latest code (Version 1.3.1).
Not the most useful update, but I spent some time looking at running KeeAnywhere this evening. The largest issue appears to be embedding the browser (for the various oauth options):
Mono's WinForms.WebBrowser support is very poor; it expects libgluezilla to be available, but Mozilla deprecated that a long time ago. It's no longer available in distro I'm aware of, and trying to build it did not work :(
The most popular alternative is CefSharp, but this sadly doesn't support Mono (https://github.com/cefsharp/CefSharp/issues/1450).
CefGlue also gave up on Mono support (https://bitbucket.org/xilium/xilium.cefglue/issues/108/linux-support).
The remaining choices I'm aware of would be to either interact with the CEF APIs directly (supposedly not that difficult, but a lot messier than the current setup), or try to use chromiumfx which reportedly does still support Mono... in theory (https://bitbucket.org/chromiumfx/chromiumfx/issues/9/mono-support).
Very surprised to find it's so difficult to host a web-browser in mono!
@jdm12989 - a long time ago now, but did you come across this issue in your fork? I was unable to get your fork to build anymore, so wasn't able to determine for myself.
I believe I came up with a more feasible approach for this for Mono (Unix). Instead of trying to embed a browser, the application could instead host a simple web server, then launch the system browser (via System.Diagnostics.Process.Start(url)
), and utilitze the _redirecturl parameter in OAuth2 (https://developers.google.com/identity/protocols/OAuth2InstalledApp#request-parameter-redirect_uri) to deliver the result to the process via the web server. It is a slightly more complicated flow (for the user and for the code), but avoids the need to figure out browser hosting in Mono (Unix).
This should definitely work for Google OAuth2 - whether the other providers have a similar mechanism I don't yet know.
I plan to start looking at this personally over the next few weeks in my spare time; if it turns out to be sane I will ultimately aim to contribute something back - but no promises yet! :)
@stephenmcgruer I have not run into this as I have only worked on getting it running with Google drive which for me at least opens up Chrome vs the embedded browser.
Hi @stephenmcgruer ,
using system's default browser works for some of the providers but not for all. The problems are mainly in issues, how providers handle authorization (callback) URL:
This all leads to the requirement to use an internal browser to have the best user experience. There are some options in which the authorization may take place in default browser and the user must copy and paste authorization token/code to a an input field in KeeAnywhere.
But I'm looking forward for solution :-)
Ah, I was not aware of such requirements from OAuth2 providers, thank you for bringing it to my attention. My knowledge is mainly from the Google OAuth2 implementation, which actually specifies that using a local loopback server is preferred over the deprecated programmatic extraction or copy/paste[0]!
I will have a look through the various provider's docs and see what the situation is for each, then loop back (pun entirely intended) here for further discussion :).
I was successful last night in hacking together a local webserver solution for Google Drive on Linux (Mono). It was remarkably easy - a few small patches for general Mono support, a replacement class for OAuth2Form, and changing the redirect URL to a localhost one.
[0]: https://developers.google.com/identity/protocols/OAuth2InstalledApp#creatingcred
Google has a ready-usable solution with local webserver in it's API. It's well documented in it's .NET samples.
Hah, I should probably have checked for such a thing first :). Are you referring to a single Google API call that handles launching the local webserver/etc - and if so, can you point me at which API call you mean?
The only .NET example I found (https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthDesktopApp/OAuthDesktopApp/MainWindow.xaml.cs) manually uses HttpListener and System.Diagnostics.Process.Start, exactly like my approach did.
See:
Please +1 for mono/linux support
Yeah, missing this too. Would be great :)
+1
@Kyrodan It sounds like CEF is no-go. What if we have a separate Electron app that does the OAuth flow and communicates the access token back to the Mono KeePass process? Packaging and distribution will be annoying, and it does smell a little bit in terms of security, but at least in theory it should work.
@univerio With issue #89 the dependency to WebBrowser-Control should be eliminated and the system's default web browser should be used instead. I had this issue especially for Mono support in mind (and for some other reasons). So I don't think there is a need for an electron-app doing OAuth. What do you think?
@Kyrodan Ah, didn't see that. That sounds perfect. What's the progress on that? Anything the rest of us can do to help? How will you deal with things like SSL on localhost?
@univerio I only have ideas and what you mention is indeed one of the drawbacks: while one provider has excellent support for Desktop Apps, others nearly lack this feature. So currently there is not much progress. But I'm open for ideas, pull request or something like that.
still no solution about that I guess?
@boistordu yes, you are right: nothing new here.
I've noticed that some solutions were possible with so;e providers. Could we maybe start fresh and witl less providers and see what's would be the modification past that point ?
Hello, some news on this topic? Also try to connect with my Ubuntu...
@Sh4d0wF1gh7
Latest commit d24bb2e on 2 Jun 2017
I don't think there is something new.
I changed the header to reflect some common duplicate issues. There is still nothing new from my side. Feel free to send me a pull request.
@Kyrodan any progress on this? TIA
Currently noch Progress in that. Sorry.
Fazle Rabbi notifications@github.com schrieb am Sa., 31. Aug. 2019, 15:13:
@Kyrodan https://github.com/Kyrodan any progress on this? TIA
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Kyrodan/KeeAnywhere/issues/18?email_source=notifications&email_token=AACWW2R7BLGZBWPSVE36C4TQHJU57A5CNFSM4BZ2WWM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TMQ7I#issuecomment-526829693, or mute the thread https://github.com/notifications/unsubscribe-auth/AACWW2UM5ACSLQTQVBOPUZDQHJU57ANCNFSM4BZ2WWMQ .
Hello @Kyrodan , sorry to ask stupid questions... I made the changes as per the "mono" branch. That way I could compile on mono and I got rid of the "newer .NET framework required" error message. However, I'm stuck with the "The following plugin is incompatible..." error. I'm running KeePass 2.42.1, but I also tried 2.40. I tried both the "plgx" and the "dll" format. What am I missing? Thanks!
I believe there are no news about this yet. I found a (very bad) workaround to open gdrive stored keepass database in Linux. I'm using KDE Plasma and kio-gdrive. After setting up Online Accounts to access my Google Drive (1st time only) I created a .desktop file to my bash script which runs "kioclient5 exec gdrive:/account/path/to/my/database.kdbx". KDE will open it in keepass (running with mono). It does work but: 1) every time you open a file it in fact downloads the file locally then open it 2) every time you save a file it gives you the option to upload it back to gdrive 3) every uploaded file is a new file, so you would end-up with the same file multiple times in gdrive (it is easy to spot which one is the latest one, though)
To circumvent 3) I'm preparing my bash to use kioclient move all the files but the latest one to an .old folder in gdrive.
Anyways, I still hope to see someday KeeAnywhere working with mono.
Cheers
I wasn't able to find a maintained solution for in-application web browser support in Mono. A solution that does seem viable is authenticating through an external browser, as supported by google. I've created a PR (https://github.com/Kyrodan/KeeAnywhere/pull/216), which allows for non-windows users to login in this way. It only supports google drive (as it's the only platform I actually use).
For embedding a web browser in Mono, this might be useful.
I'm in progress of abandoning the internal browser and improving linux support.
For further v2.0.0-Beta-Tests please move on to #252.
Somthing that you might be able to do, is use Microsoft webview2 which is powered by the new cross-platform Microsoft Edge.
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Daniel Bölts notifications@github.com Date: 2/12/21 8:05 AM (GMT-06:00) To: Kyrodan/KeeAnywhere KeeAnywhere@noreply.github.com Cc: Wyatt Jackson minecraftchest1@outlook.com, Comment comment@noreply.github.com Subject: Re: [Kyrodan/KeeAnywhere] Mono/.Net Core/Linux Support (#18)
I'm in progress of abandoning the internal browser and improving linux support.
For further v2.0.0-Beta-Tests please move on to #252https://github.com/Kyrodan/KeeAnywhere/issues/252.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Kyrodan/KeeAnywhere/issues/18#issuecomment-778215508, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIAII7267SK22RFS5U2OR3S6UYTHANCNFSM4BZ2WWMQ.
I released v2.0.0 today. During abandoning the WebView I did some changes to improve Mono/Linux-Support. I could not test it by myself but maybe someone from this issue would do and report back?
It would be awesome if Mono could be supported as well. I had to fix an image reference and remove OS and .NET restrictions to get a working .plgx file (see this branch), but the compilation by KeePass fails. I don't really know anything about C# and .NET, so I have no clue how to fix this.
Here's the compiler error given when launching
KeePass.exe --debug
: