Bitwarden - Self-hosted password manager

[will]

@iamthefij I just havent been able to get yours going using the steps I posted above

[iamthefij]

@will Which thing is failing? Building still works for me, even if I clear my cache. Make sure you do a git pull though. It looks like your build command is using the single build Dockerfile rather than the multi-phase one.

[will]

@iamthefij How do I use the multi stage dockerfile?

[girish]

It seems people are struggling to build. @iamthefij if you have your docker image public, you can just put it here. People can then install it as:

cloudron install --image <image> # run this in the repo directory

No need to build!

[iamthefij]

@girish good idea. Here's my build: https://hub.docker.com/r/iamthefij/cloudron-app-bitwarden

@will The multi-stage build should be default if you've pulled the latest. Dockerfile should be a symblink to the multi-stage one.

[girish]

thanks @iamthefij

For those looking to install this:

$ git clone ssh://git@git.cloudron.io:6000/iamthefij/bitwardenrs-app.git
$ cd bitwardenrs-app
$ cloudron install --image iamthefij/cloudron-app-bitwarden:0.3.0

Aaaannd it's running:

After installing, both my users got an invite to join bitwarden. Very cool.

[jdaviescoates]

@girish any reason not to have this in the app store as unstable? I'm assuming the only thing keeping for being officially released are tests need to be written etc?

[yusf]

@girish said in Bitwarden - Self-hosted password manager:

After installing, both my users got an invite to join bitwarden

Like, automatically?

[girish]

@jdaviescoates Yes, tests plus making sure we can actually maintain it in the long run (for example, if everything is pinned properly in the docker file, things like that). Usually, @nebulon and also do a round of manual testing and put some basic docs before putting it in unstable.

@yusf yes, both users got the invite automatically.

[jdaviescoates]

@girish said in Bitwarden - Self-hosted password manager:

@yusf yes, both users got the invite automatically.

I'm guessing perhaps @yusf was asking because what if you don't want to invite all users automatically?

[yusf]

@jdaviescoates Namesake reads my mind.

[jdaviescoates]

@yusf heh, I only just realised Yusf is obviously Yussef which of course is the same as Josef

[iamthefij]

When installing, uncheck SSO.

[yusf]

@iamthefij I haven't followed the thread continously but is there a specific reason for emailing all users who are granted access to the app through the SSO?

[iamthefij]

@yusf Yea, the Readme describe the reasoning.

There is no way to actually do true SSO without breaking the model for Bitwarden. The only thing that we can do is automatically invite users to sign up.

The Bitwarden_rs project doesn't have a way to invite without sending an email as when an SMTP server is configured, it will generate unique invite links for each user.

If you disable SSO, you only disable the auto-invite feature. You will then need to invite yourself via the Admin panel (admin token is echoed in the logs and in /app/data/admin_token). You can then invite anyone else you wish manually.

[necrevistonnezr]

Is there a reliable way to move from Bitwarden SQLite (fbartels build) to Bitwarden MySQL (iamthefij build) including all attachments?

[will]

This post is deleted!

[will]

@iamthefij I can't login to the admin page. It keeps saying "invalid token"
I did a fresh boot of the container, copied everything between access token= and HTTP/1.1"
access_token= copied this giberish HTTP/1.1"

Thoughts?

[nebulon]

Just to inform everyone here, today I've created a new gitlab project for this app package repo wise, based on @iamthefij version, however without relying on external dockerimages being mounted during app image building. The repo is at https://git.cloudron.io/cloudron/bitwardenrs

One thing I wanted to ask here is, how to deal with ldap sync. Generally this works currently by a cron job running every now and then, checking availalbe users on ldap and then will invite all users, which are not yet invited to the app instance. This has the current annoying thing, where if an admin wants to first try bitwarden on the Cloudron and does not restrict access during installation, the app will send out invites to all users. Since this is the default flow, I don't want to publish the app package like that. On the other hand I do see value in those invites being sent out at the point where the admin decides this app is good to be used.
To not delay any package release further, we could avoid this topic by packaging it first without ldap, but I wanted to collect some feedback on this here in the thread first. It would be great if you all could share your ideal flow regarding this and maybe explain the use-cases briefly.

Thanks! And even more thanks to @iamthefij for all the work done on the package already!

[will]

@nebulon My view is if it does not have "full" ldap, ldap should be taken out and left up to the admin to manage by hand, such as it is with other apps, like Ghost, or Monica.