Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot Login Using Bitwarden Mobile Native #4656

Closed
privacytime101 opened this issue Jun 19, 2024 · 11 comments · Fixed by #4386
Closed

Cannot Login Using Bitwarden Mobile Native #4656

privacytime101 opened this issue Jun 19, 2024 · 11 comments · Fixed by #4386

Comments

@privacytime101
Copy link

Subject of the issue

Can’t log into the new public beta of the Bitwarden Mobile native apps. Using the official bitwarden.com instance, the login works. On a Vaultwarden instance, it gives an “an error occurred” alert on all platforms that were tested. v2024.6.1 tested on iOS 18 Developer Beta 1, iOS 17.5.1 Stable, Android stable (unknown version, community-reported).

Deployment environment

  • Vaultwarden version: v1.30.5-55fdee3b
  • Web-vault version: v2024.5.1
  • OS/Arch: linux/x86_64
  • Running within a container: true (Base: Debian)
  • Environment settings overridden: true
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: PostgreSQL
  • Database version: PostgreSQL 15.7 (Debian 15.7-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
  • Install method: Docker image

  • Clients used: Bitwarden Mobile Native iOS & Android v2024.6.1

  • Reverse proxy and version: NGINX 1.18

Steps to reproduce

Open the new Bitwarden native app, set your self-hosted instance, try to log in.

Expected behaviour

The login proceeds as normal (as seen while using the official bitwarden.com instance).

Actual behaviour

“an error occurred” message shows up. The error is not caused by the credentials being incorrect, nor by MFA being enabled.

@BlackDex
Copy link
Collaborator

Already resolved via #4386 , which just needs some extra testing.

@imnotpolar
Copy link

Already resolved via #4386 , which just needs some extra testing.

Any eta on when it'll be merged, or are there many bugs w/ it?

@BlackDex
Copy link
Collaborator

No eta, timelines or release schedules.

And to see if there are many bugs in it we need to review it first 😉

@tessus
Copy link
Contributor

tessus commented Jun 19, 2024

@BlackDex I believe I am still a bit confused when it comes to releases and the master branch (testing). It seems to me that testing is used by people, because releases often do not work with the recent clients. Thus testing (master branch and testing containers) is not really a testing branch but a different prod branch.

Otherwise it would make sense to merge the mentioned PR and let people test. It seems to me that PRs are only merged to master when they are prod ready. Thus it would make sense to create a testing branch from which real testing containers and maybe pre-releases are published.

I am sorry to post in this issue, but I think my comment has merrit, especially when it comes to the camelcase PR.

Maybe you can clarify the release/testing/master meanings, because I seriously have problems to understand them in this project.

@BlackDex
Copy link
Collaborator

Testing is based upon the code located in master. Any PR or push to master will trigger a build and will push new containers tagged with testing.

If we create a tag, which we set to a n.n.n format that will trigger a new stable and versioned latest tagged release.

When we will create a tag is not defined anywhere. It's more a mixture of, should we wait for pr x or y to be finished, or are the merged changes since the previous tagged release long enough in testing for people to tested it and report issues. Or are there any open issues which we want to have addressed before releasing a new tagged version.

@tessus
Copy link
Contributor

tessus commented Jun 19, 2024

That all I understand and knew already. My point is that testing is not really testing, because you only push prod ready PRs to master, which is the branch used for creating the testing containers.
So for me testing is a branch or a container to test code that is not prod ready yet. But this does not exist in this project, otherwise you would have merged several PRs already which you would like people to test.
In this project testing is a container that is the latest prod, but without a specific release tag. That's all. This is not testing in the sense of testing. ;-)
I really do not want to hijack this issue, we can or should move this specific conversation to a discussion.

@BlackDex
Copy link
Collaborator

So, start s discussion then 😉

@seraphblade2010
Copy link

@BlackDex I will hijack this Issue for one simple question:
When are new vaultwarden web releases coming to this project?
Vaultwarden itself is on 2024.6 and this project sits at 2024.1.2.

Maybe im just confused but maybe you can help me understand when new web versions are coming ^^

@BlackDex
Copy link
Collaborator

If you use testing you would have v2024.5.1 right now.
We do not have eta's, schedules for our stable/versioned releases.

@Lovest20018
Copy link

Do you need to log in to the new beta app for Android by 2024.06? Updating to testing 2024.5.1 still prompts an error.

@dfunkt
Copy link
Contributor

dfunkt commented Jun 21, 2024

That's the web-client version, not relevant to the mobile apps.
The new mobile apps are not compatible yet with any vaultwarden version (stable or testing). Only after #4386 gets merged will the testing images be compatible with the new apps. (+ maybe a new stable version could be released for compatibility reasons, who knows)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants