Jump to content
Enpass Discussion Forum


  • Posts

  • Joined

  • Last visited

  • Days Won


Unsay last won the day on August 8 2018

Unsay had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Unsay's Achievements


Newbie (1/14)



  1. A similar error has already been reported (here), but this is a defferent problem. Tested on Android 8.0. After selecting OneDrive from the "Sync With" drop down menu, Enpass briefly shows an "Authenticating" pop-up, Firefox is automatically opened and directed the the Microsoft website, and then Enpass shows this error message: The sync with OneDrive was canceled by the user. I can only click "OK". The "Sync With" drop down is reverted to "None". This worked fine in 5.x FYI: My device is rooted and the default browser is Firefox. Chrome is not installed on my device.
  2. On Linux, Enpass configuration information is saved to: /home/<user>/Documents/Enpass This is very "Windowsy". In keeping with the spirit of Linux, it should be saved to: /home/<user>/.enpass
  3. This is the problem! You should be working smarter, not necessarily harder ;-) Place all editions of Enpass for Windows on a single code base, with a swappable UI (QT, UWP, or a headless version without a UI which is what would be used 95% of the time when Enpass acts as the back-end for a browser extension)! If you did that you could: release non-UI features for all editions of Enpass for Windows simultaneously, including FF57 support. Require only two editions of Enpass (legacy QT edition for Windows 7/8.x/ and Enpass Portable and an UWP edition for Windows 10), making it much easier for customers to understand and get the correct version for their environment. Enpass could start up much faster as the headless version wouldn't have to load all the QT bloat. Eliminate the feature gaps between editions, the sole exception being UWP related features. This would be far easier to understand than the seemingly arbitrary differences Enpass editions currently exhibit. Reduce or eliminate the delay between releases of different editions of Enpass for Windows. Remaining delays would only impact UI specific changes.
  4. Yes, I completely agree. I've been complaining about the root cause of this problem too, for over a year now. Every version of Enpass for Windows suffers from it, e.g. the portable version also isn't compatible with FF57, so people who need the combination of portability and FF57 are out of luck too. Need FF57 and Edge... out of luck. Need Windows Hello and any browser plugin at all... out of luck. All of these editions of Enpass for Windows should theoretically be generated from a single, consolidated and shared code base. That would ensure that all non-UI features (like browser plugins, or Windows Hello) would become available for all versions of Enpass for Windows simultaneously. Most of the Enpass for Windows code base should be shared across editions, only swapping out the UI layer for alternative implementations where necessary (like the UWP version). The fact that they aren't doing this is the root cause of this mess, which the Enpass team understands but isn't willing to correct (I'm guessing due to the effort required). This is definitely worthy of being complained about. My previous post was intended to reduce the number of posts in regard to things where the information is available, but people were confused regardless.
  5. All of the questions asked in this thread, and much of the confusion, could be avoided if people would just read! Anyone saying "Help! I'm using the current/latest version of Enpass on Windows and the Firefox 57 plugin doesn't work" needs to stop and inform themselves first! There are multiple editions of Enpass on Windows, all of which have different version numbers. All of them are the current/latest version of Enpass, for their edition. Only one edition is compatible with Firefox 57. Three of them work with Firefox 56 and earlier. Only one of them works with Edge. Frankly, I think the Enpass team is having some difficulty communicating on this topic, but here is the break-down: * The 'Traditional Win32' edition is the only edition that works with Firefox >= 57. ** The 'Windows UWP' edition is the only edition that supports Windows Hello and Cortana. IMHO the table above is what should be on the Enpass download page, under a single heading for Windows. Considering the ludicrous mess they have there now, the confusion isn't surprising. Anyway, according to this blog post: the Windows 10 - Desktop (a.k.a Bridged) edition is what the Enpass team will be focusing on going forward. It will eventually become compatible with Firefox 57 and include all the features that are currently unique to the 'Windows UWP' edition. The 'Traditional Win32' edition won't get that much attention, but it will stick around for people with older versions of Windows. I've not seen anybody mention anything about the portable version, which at this point looks like it has been abandoned. Here are the download links for the various versions of Enpass for Windows: Traditional Win32 (5.6.0) Portable (5.5.6) Windows 10 - Desktop [a.k.a bridged version] (latest version) Windows UWP (latest version)
  6. @bunnyhero @tojtojka As Gajender mentioned in the OP, you must have: "the latest Enpass v5.6 for Windows, Linux or Mac (Website version)". The version you are using is v5.6.2 (Microsoft Store version). That will not work. There are currently four different versions of Enpass for Windows: 1. Win32 version for Windows 7/8/8.1/10 [Website] 2. Win32 version for Windows 7/8/8.1/10 PORTABLE [Website] 3. Win32 version for Windows 10 [Store] (the only version that supports the MS Edge WebExtension) 4. UWP version for Windows 10 [Store] (the only version that supports UWP features like Windows Hello) [Website] = downloadable from the Enpass website [Store] = downloadable via the Microsoft Store Of these, only #1 works with the WebExtension for Firefox 57.x My hope is that one day all the distinct Win32 versions become a single version (even the UWP version should be based on the same core application, and "merely" swap out the QT based UI for a UWP based one). Unfortunately, I'm somewhat disillusioned at this point. Cleaning this up should be a major focus for Enpass. Doing so would provide many benefits beyond alleviating this confusion, but but for some reason it just isn't a priority for them.
  7. Hi @Anshu kumar It's frustrating because it's so entirely unnecessary. It just makes absolutely no sense for both "standard" and "portable" versions of Enpass to exist. The "standard" version for Windows PC reached 5.6. weeks ago. There is no reason that shouldn't automatically yield the "portable" version for Windows PC as well (or visa versa). For Windows, the state of the WebExtension for Firefox on other platforms is simply irrelevant. For each platform, both the "standard" and "portable" versions really should be one and a same, with the only difference being a slightly different configuration made by the "standard" version's installer.. In our software shop we use Firefox developer (not beta or pre-release) version, which was automatically updated to v57 last week. Everyone using Enpass is now forced to switch browsers (and recreate all their browser configurations which for some of us is time consuming). I saw this situation coming from miles away. I've mentioned this problem on your forums multiple times already, the first time over a year ago. It baffles the mind that you guys can't give something like this higher priority. Like most of Enpass' design and architectural shortcomings, you seem to ignore it, despite there being no technical reason both "standard" and "portable" versions can't be in sync. In any development shop where efficiency mattered they would be. You needn't even be very technical to notice something is off. Looking at your website's list of supported platforms is enough: Windows, Windows PC, Linux, OSX, Blackberry, iPhone/iPad, Portable... which one of those is NOT actually a platform? I hope you guys can finally get around to fixing this architectural flaw. That would be at least as important as bringing the portable version up to v5.6.
  8. Seriously, what are you guys thinking? For any well designed piece of software, there is no reason to separate the standard from the portable version. There is no reason for these two distributions to not be the exact same thing. *sigh* Everyone else can do it, why can't you? People using the portable version also use Firefox... now at version 57... which is incompatible. This has been fixed in the standard version 5.6, but the portable version continues to frustratingly lag behind. It remains incompatible. Any chance you'll get around to updating the portable version from 5..5.4 to 5.6? Better yet, get rid of the standard version entirely and allow the portable version to be configured in a way that mimics the so very slight differences to the standard version? It's about time that happened.
  9. Woot! Just tried out Portable 5.5.5 and this has finally been fixed. Thank you! Now we just need to find out why keeping the non-portable version makes sense (hint: it doesn't): ;-)
  10. I just tried out the portable version again. It still uses the nag-dialog which unnecessarily asks us to specify the path to the wallet file every time it is launched. :-( If the most recently used relative path from enpass.exe to the wallet file is still valid, why not skip the nag-dialog entirely and just provide a way to explicitly open it if required? Why not consolidate on using just the portable version and getting rid of the non-portable version entirely?
  11. Or, rather than going only half way, solve the problem entirely. Just update Enpass in the background automatically without requiring any user interaction whatsoever. Allow users to disable automatic updates in the settings, which would prompt users to update, but don't make that the default.
  12. Well, in any case, thanks for the update. Much appreciated Vinod ! I'm glad you're considering your software's startup impact. Thank you. However, I think it's safe to assume that your software architecture is borked if you have UI dependencies in the lowest/core levels of the application. I suspect that's likely due to events that must be received and handled in the UI layer. If so, then you shouldn't be using QT for that, but rather your own event aggregator (see the Prism framework for a C# code example or any other observer or publisher/subscriber pattern). That would be useful on every platform, including those that don't use QT (I'm assuming your mobile apps don't use QT and that you use the same OS independent core on every platform). The core would then communicate only with the cross platform event aggregator. That eliminates QT dependencies from the core. In desktop applications, the event aggregator would then propagate those events to the subscribed QT based event handlers. In mobile applications the aggregator would propagate those events to each mobile OSes native event subscribers. Particularly for a company that builds a single application for so many platforms, it seems like a no-brainer that you'd be very interested in keeping UI dependencies out of the core. Just something to consider... Good luck!
  13. Hey @Vinod Kumar It's been four months, so I'm popping in to check up on this. Do you have any more information on that major refactor you said you had planned for this year, and whether or not, as part of that endeavor, you will split Enpass into a small, efficient, headless (without any dependency on QT) background task and a front-end application? I've noticed the rate of updates being applied to the Windows desktop application has slowed (which I'm almost thankful for), and thought a larger refactoring task may be the cause *hopeful* ;-)
  14. ^ rather than just hiding the Window, it would be better to just not have it exist at all. Even if it is hidden, we'd still be paying for its existence in terms of an additional 10MB of memory being wasted and it slowing down boot times.
  15. Another benefit of having only the portable version, would be that you could dump the installer (less maintenance, fewer things that can go wrong).
  • Create New...