This repository has been archived by the owner on Feb 22, 2023. It is now read-only.
[BUG] Cannot login with latest docker containers #81
Labels
bug
Something isn't working
Comments
|
This does look to be an issue with the latest set of docker images. I disabled two-factor authentication and this issue persists. I'll update the title accordingly. Everything works fine if I downgrade to the versions listed at the bottom of my last comment. With the latest versions from dockerhub (deleted previous images, ensured the latest were pulled from dockerhub) I get the following output from the auth container: |
eric-pierce
changed the title
|
I just wanted to confirm that I have the same exact problems that @eric-pierce reported. And also want to mention for others that end up here that the previous version of the Additionally, I would like to know what were the reasons for dropping the specific version numbers in the image tags. I have been able to go through several successive upgrade cycles using the compose files that provide the specific versions of tags. Anyway, thanks to all that make this amazing project a viable reality. |
|
Any progress on this “bug”? |
It doesn't look like this has been acknowledged by the SN team yet. I'm still using the old versions from the last docker-compose version specific file, but would much prefer to be able to keep the system up to date with the latest containers. |
Same here, still using the previous version specific file. The problem with the latest tag has been around since the beginning when they switch to the new server version. I already mentioned it back in the day but nothing happened… |
|
I'm willing to help , but i can not reproduce this error with a clean clone and the latest image (as of 20220818). Can anyone provide the detail image version ( by |
|
EDIT: just updated the latest containers to latest version - issue persists, details below Thanks for the note @jackyzy823 - here are the details of my containers and logs: Logs from my auth container with the images above: My relevant docker-compose section: |
|
@eric-pierce , I think the main reason is standardnotes is using ioredis v5 now. And According to ioredis' migrationdoc
so in your docker-compose.yml, now you should replace all I haven' tested it, but i think it will help. |
|
@jackyzy823 I just made this update, and was able to log in without issue through both the web and mobile apps - thank you! I also tested re-enabling 2FA, and all works as expected. Really appreciate your troubleshooting here - the standalone configuration doesn't use a redis password so it wasn't apparent that the REDIS_URL syntax was the problem. I'll close this issue |
I don’t use the redis password I use the standardnotes example URL |
I think no. If you still have problem , paste your docker-compose.yml , env files , error logs, and images' version. I will try to help you. |
Tried it (before your reply) this morning and I kept getting error messages and then reverted back to the "old" image tags and everything was working again. With your help I'm willing to try it again! |
|
These are the errors I get when using the Errors: docker-compose file: env file: api-gateway.env: auth.env file: files.env file: |
@BobWs depends on the output of error log , it seems no error at all ? |
That is strange, but it still isn’t working for me when I use the Did you see anything out of the ordinary in my files? docker-compose, env |
|
Well , i set up a test env using your docker-compose.yml and envs ( only remove file-server part) , and using https://app.standardnotes.com as frontend. It just work normally. the docker image info Can you show the http request log (like http status and response) from browser ( using Developer Tools or F12) ? |
|
Just to add potential considerations. I was migrating my ghost blog and there was a database update, in order to get this to work, there had to be a fix with the collation. I noticed you using the latest tags on everything including the mariaDB. Maybe there is something throwing off your DB? Have you tried to include latest in everything except leaving your DB the same version? Anyways, just a thought, it may be irrelevant. |
Yes that is true, but I have updated the database to the latest version, it is still the same version as when I use the version specific images. |
Well that’s the problem I can’t login because the server is still unavailable…the logs keep mentioning that it is starting.. |
You mean the container keep restarting ? |
No the container starts fine (all of them) but I the log I see and the other containers show this in the logs That’s all what is happening, and and the clients (apps) give a error message that the server is offline. So I had to revert back to the version specific tag and everything is fine and working. |
|
Maybe I should try a clean install with a new empty database… |
|
These logs are all ok , mine has these logs too. what do
So you're using client (like desktop /android one) , have you tried to login with web (since it is easy to debug) ? |
Yes clients like desktop and mobile apps. |
It would be fine If you could provide the log about this login request. |
I could but at the moment I reverted everything back to the working version so I have to start again. |
|
@BobWs it sounds like your issue is that the auth container isn't starting as opposed to the redis issue I was facing - I don't see any of your logs from the auth container, which may hold some useful info |
|
Sorry guys for not being able to respond to your suggestions sooner, but I think I found the problem! I did a clean install on another machine and it worked out fine. All containers started normally after the database was ready. Then I activated the Subscription with the following command in the database: And after I restarted the containers it doesn't work anymore and everything hangs again. So I suspect that the problem is caused by the changes in the database for subscription. And since I already had this in my production machine it didn't work. Unfortunately I don't know how to solve this as it probably concerns the database. |
|
Thanks for your information. I repeat your step , however still can not reproduce. The only thing i concern about this SQL is Another thing needs to be concerned is that maybe your client version is too old ? It would be better that you could provide your client info (like android/ios/desktop/web and version) |
|
Thanks for helping! The about the clients I’m using the latest versions available for MacOS desktop and iOS (mobile devices). So all my clients are up to date. Database version is mariadb 10.8 (latest docker tag). |
for electron-based application , you may toggle developer console via |
|
So to test my own theory and to try your suggestions I took the following steps:
Then restarted all containers, it took a long time but finally everything booted up properly and I did the curl test Then I logged in using the desktop app and could create notes, edit etc. Then for SQL I changed the value to your suggestion After this I logged in again using the desktop app and to my surprise it just worked! Restarted all containers just to be sure and then logged back in and everything worked! Also the components under subscription work! So I think your idea to adjust the value has helped. Now I just have to apply it without any problems in my production machine. I have to be careful because I have 5 users there using Standardnotes with a few hundred notes. |
|
I'm glad that it works again. But I still wonder why it happens. Because it doesn't happen on web (Chromium Browser) neither Linux's AppImage Desktop Version. Since I do not have any MacOS/iOS device, If you're willing to help out to find the real cause of this issue, Could you have a look at and screenshot the error output of Developer Console in MacOS client ( instructions above) with you test env and the origin one |
|
I am following this due to my notifications lol. Anyways do you think this would be restriction/limitations from being a MariaDB vs MySQL DB. I feel through my journey in self hosting I would come across issue with a database not taking something due to character or syntax limitations and things of that nature. |
So I guess I have cheered a little too early. After I changed the database to In the end I decided to restore the old specific version because otherwise my users and I could no longer use the notes. |
This is the output at the moment from my MacOS desktop client on the origin (production machine with the specific versions tag) |
I don't know it could be possible. But I must say my docker containers that require a database I use |
|
What |
That is the value I set, in the desktop app the date 2033 was showing. So for now I’m not going to mess things up again I will stay on the “old” version specific tag. |
|
So I couldn't leave it alone and had the figure out what the problem was and decided to give it one more try! The first thing I though was "let's try to remove the memory limit" and guess what...Yes it was the limitation I had added in the docker-compose file. everything started just fine!!...even after a few restarts (just incase;) Thank you all for helping! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Versions
"Latest" tags from docker hub
Describe the bug
Logging in with the latest version of the docker containers from dockerhub (new deployment method used) fails login stagek. Downgrading to the previous hardcoded version resolves the issue.
To Reproduce
Leverage the latest version of the application from dockerhub, try to log in
Expected behavior
Login successful
Logs
[ioredis] Unhandled error event: ReplyError: WRONGPASS invalid username-password pair or user is disabled.
at parseError (/workspace/.yarn/cache/redis-parser-npm-3.0.0-7ebe40abcb-89290ae530.zip/node_modules/redis-parser/lib/parser.js:179:12)
at parseType (/workspace/.yarn/cache/redis-parser-npm-3.0.0-7ebe40abcb-89290ae530.zip/node_modules/redis-parser/lib/parser.js:302:14)
Additional context
When using the latest version of the docker images login is flagged as incorrect. When downgrading to the version of the docker containers used before the recent switchover to the latest tag, login works as expected:
standardnotes/syncing-server-js:1.54.1
standardnotes/auth:1.46.2
standardnotes/api-gateway:1.40.1
The text was updated successfully, but these errors were encountered: