can't log in after install

[harcesz]

Installed listmonk assigned to my main account, cant log in with neither combinations of my login ( short, full with @), set password, account password, admin and either passwords.

[ericgaspar]

Would you mind sharing some logs (webadmin -> services -> listmonk -> Share the logs with YunoPasta) And also what was your answer to the question: Should this app be exposed to anonymous visitors? [yes | no]

[evolverine]

I'm having the same problem. I tried the installation with or without exposure to anonymous visitors, and I still can't log in, no matter the username and password combinations I try. I tried editing the config.toml file and restarting the service, but it doesn't seem to be respecting those values at all. Logs here.

@harcesz did you manage to make it work?

[harcesz]

found another solution to the reason for which I was installing it, but I would check that the user:group is set right on the files; seems to be a problem around a recent version of YNH

but also, @evolverine please share the data @ericgaspar is asking for, it might help solve the issue for others.

[lucyferu]

i was about to open the same issue but it seems like a solution has been found? can it be shared?

in any case, here you can find my logs.

[evolverine]

I would check that the user:group is set right on the files; seems to be a problem around a recent version of YNH

I'm not exactly sure what you mean by this, @harcesz. I checked the file permissions, and they seem very similar to the ones for the wordpress files, for example. Could you point me to a thread / article that can help?

i was about to open the same issue but it seems like a solution has been found?

I have yet to find it...

[evolverine]

A clue is that the config.toml contains strange values compared to the sample from the listmonk repo: instead of actual values, it has values starting and ending with double underscores:

admin_username = "__ADMIN__"
admin_password = "__PASSWORD__"

# Database.
[db]
host = "localhost"
port = 5432
user = "__DB_USER__"
password = "__DB_PWD__"
database = "__DB_NAME__"

If I understand right, the double underscores suggest environment values, but none seem to be defined with these names.

Also, changing these values (including removing the username and password for passwordless authentication) seems to have no effect, even after restarting the listmonk service.

[ericgaspar]

These values should have been replaced during the installation (in this line)...

[ericgaspar]

I am testing the app. After a clean install, the config.toml file is properly configured... Can you uninstall and reinstall the app? Also what is you configuration? (YunoHost version, arch...)

[evolverine]

Yes, I was just looking at that file now. Indeed, it looks like the installation script didn't do its job right. Any ideas as to why? This happened in the same way when I reinstalled it for the second time.

Yunohost version: 4.3.6.2 (upgrading now to 4.3.6.3) Linux: Debian 10

[evolverine]

And I'm installing listmonk on a subdomain, if that's relevant.

[evolverine]

I also see, in the forums, that someone else is having the same issue.

[evolverine]

@ericgaspar any ideas?

[shukon]

Any chance this could get fixed? I'm really stoked to see listmonk on yunohost, but I'm not sure how to fix a package.

[ericgaspar]

@shukon Can you please install from testing. sudo yunohost app install https://github.com/YunoHost-Apps/listmonk_ynh/tree/testing

[ericgaspar]

Should be fixed with #6

[lucyferu]

@shukon Can you please install from testing. sudo yunohost app install https://github.com/YunoHost-Apps/listmonk_ynh/tree/testing

still encountering the same issue. sigh.

[ericgaspar]

Please, provide more details about your issue (different browser used, do you get the authentication window...)

[lucyferu]

using the same browser i always used (brave). i get the confirmation window, i insert the login details, i press enter, the window disappear and then immediately come back asking for the details again. the only difference now is that the page looks like it starts to load (usual circle rolling on screen), but it leads nowhere since it keep asking me for login details.

[ericgaspar]

Do you mind trying other browsers : firefox, chrome?

Edit: I successfully log in with firefox and chromium.

[lucyferu]

just tried firefox and safari and it didn't work.

does it help if i share the logs?

[shukon]

@unicmyce I had to reinstall the whole server for this to work. It didn't work when I simply upgraded and also not when I removed the app and reinstalled. So my guess is, that the fix doesn't work on upgrades and that removing the app does not revert the necessary changes. It's the --auth_header=false in the permissions step. Is it possible, that permissions do not get revoked / reset on app removal and the fix cannot actually be triggered?

(Debian 10 VPS with Hetzner, current Yunohost versions, no other apps)

[lucyferu]

@unicmyce I had to reinstall the whole server for this to work. It didn't work when I simply upgraded and also not when I removed the app and reinstalled. So my guess is, that the fix doesn't work on upgrades and that removing the app does not revert the necessary changes. It's the --auth_header=false in the permissions step. Is it possible, that permissions do not get revoked / reset on app removal and the fix cannot actually be triggered?

(Debian 10 VPS with Hetzner, current Yunohost versions, no other apps)

is there a way to achieve this without having to reinstall the whole server? 🥲

[navanchauhan]

For people with the same issue, I had a password that did not work and would throw me in an endless loop of the login prompt. Changing the password in /var/www/listmonk/config.toml fixed the issue.

My original password was something like Zserhf38 (Obviously not the real password), changing it to something like Fafun293@neujswub fixed the issue for me

[lucyferu]

For people with the same issue, I had a password that did not work and would throw me in an endless loop of the login prompt. Changing the password in /var/www/listmonk/config.toml fixed the issue.

My original password was something like Zserhf38 (Obviously not the real password), changing it to something like Fafun293@neujswub fixed the issue for me

just tried what you suggested and it didn't work for me sadly.

[navanchauhan]

@unicmyce can you try installing the version in the testing branch -> enable public -> open incognito and try login

[lucyferu]

@unicmyce can you try installing the version in the testing branch -> enable public -> open incognito and try login

can't do.

i receive this error.

469 ERROR Could not fetch sources files, is the URL correct?

tried with both installing the testing branch or updating the already installed up to testing.

[navanchauhan]

@unicmyce i deleted the testing branch by mistake when I merged it into the master. Please try again

[lucyferu]

@navanchauhan so, just to double checked i did it right:

installed testing branch as you said, then added "Listmon (admin)" to the visitors [enable public], opened Tor [open incognito], went to the login page and it worked. i finally managed to login.

however, the same doesn't happen when i try to login from a regular brave tab.

do you know why is this happening? and does this mean i can't really use it since people won't be able to access it to subscribe?

[navanchauhan]

You did it right. Although, when I meant incognito I meant just using the private window (not necessarily Tor).

It's just a cache issue on your side (clearing out the cache just for the website should fix it). It won't be an issue for others

[lucyferu]

it did. thanks. 😄

should i keep listmon admin open to visitors or can i remove it from there?

[CodeFreezr]

Same problem here. Endless loop in login with or without incognito. Tryd chrome and firefox. changed also setting in config.toml no luck.

[lucyferu]

@unicmyce i deleted the testing branch by mistake when I merged it into the master. Please try again

@CodeFreezr it worked when i did this, as in installing testing branch and adding listmonk admin to visitors permission. then, i just had to delet the cache (as suggested by @navanchauhan again) to make it work on my main browser without incognito. ah, originally, i didn't go incognito, i used tor.

[Gwylohm]

Hi, I got the same problem. I noticed that when I was logged into my YNH interface with my YNH ID before to access to Listmonk webadmin, the login loop was happening. But when I connect directly to Listmonk, via its direct URL, without having previously connected to YNH, it works perfectly. By the way, I installed the testing branch and added listmonk admin to visitors permission.

[navanchauhan]

Let me look into disconnecting listmonk from YunoHost SSO

[Gwylohm]

Hi @navanchauhan Have you seen if that could change anything? Because I uninstalled Listmonk and reinstalled it again today, and I still see the same connection problems ; it only works in inprivate navigation (without prior connection to YNH SSO). In any case, thank you for your investment.

[navanchauhan]

I have been busy with my midterms, let me try and investigate again over the weekend

On 28-Sep-2022, at 1:57 AM, Gwylohm @.***> wrote:

Hi @navanchauhan Have you seen if that could change anything? Because I uninstalled Listmonk and reinstalled it again today, and I still see the same connection problems ; it only works in inprivate navigation (without prior connection to YNH SSO). In any case, thank you for your investment.

[cruftex]

I stumbled on the same problem. Here is a possible workaround I found:

Remove the admin user and password in /var/www/listmonk/config.toml:

admin_username = ""
admin_password = ""

This disables authentication in Listmonk, however, Yunohost is still enforcing authentication on /admin via SSO. A problem now is that /api is exposed so the SSO authentication needs to be changed that /api authentication is required as well.

Here is what I changed in /etc/ssowat/conf.json:

        "listmonk.admin": {
            ... identical ...
        },
        "listmonk.api": {
            "auth_header": false,
            "label": "Listmonk (api)",
            "public": false,
            "show_tile": false,
            "uris": [
                "listmonk.example.org/api"
            ],
            "users": ["adminuser"]
        },
        "listmonk.main": {
            ... identical ...
        }

Disclaimer: It seems to work, but, SSOwat is totally new for me and a bit "under documented" (which is a bad thing for a security related tool), so please double check before using.

[Gwylohm]

It works perfectly for me, thank you @cruftex ! Nevertheless, when I change, in YNH webadmin, users permissions to Listmonk, it erases this changes in the sso conf.json, so caution.

[Gwylohm]

Hi folks, Has been there some evolution about this log in problem ? Indeed, the solution suggested by cruftex seems to doesn't work anymore, an "AxiosError" occurs when I want to log in. In the same time, there is too frequent changes in the SSOwat conf file occured by YNH, during its updates, to ensure the security of the app because this changes open the Listmonk webadmin interface to everyone whitout password... Thanks in advance for your answers and your time !

[navanchauhan]

I am going to be looking into the issue and pushing a patch by the end of the week. I finally have some time to work on this

[artybdrlt]

Hello guys. Any update on this issue? I'm having it myself and it's quite annoying.

[navanchauhan]

Right now, a quick fix is to add listmonk (admin) to the visitors group in the YunoHost -> WebAdmin -> Users -> Manage Groups and Permissions panel

Then, you can log in to the admin panel in incognito/private mode by going to listmonk_domain.tld/admin

I do recognise that this is not an elegant solution, but I will need to go into listmonk's code and see how they are authenticating. Could be an nginx issue, could be a listmonk issue, could even be a configuration error :(

I did not have much time this semester to work on these packages

[navanchauhan]

@cruftex thank you for proposing this workaround, I will check if I can still somehow enforce a separate admin/password, otherwise I will add your fix to the testing repo

[navanchauhan]

Please try the testing branch to see if it fixes your issue.

The upgrade does the following:

• Bump to latest version of listmonk
• Creates uploads folder
• Updates permissions, /api/public and /health are public, /api and /admin is only useable by the admin user
• Removes app specific username/password. Only the admin user can access the path now

Once I test the app with another server (going from really old version -> migrations + upgrade), I will close this issue.

Feel free to reopen if the issue persists

[stepcellwolf]

Still does not work. Any work around tried everything?

[nykula]

@stepcellwolf The workaround remains:

1. Add Listmonk (admin) to visitors group.

2. In a private firefox window, sign in to listmonk (but not to yunohost, otherwise stuck in a loop) with the username and password from /var/www/listmonk/config.toml.

The condition where I have to do it this way: yunohost main domain is example.org, listmonk is subdomain.example.org.

My guess about the loop is that when you are signed in to YunoHost, on every page load SSOwat clears listmonk's Authorization header unless it's equal to Basic base64(username:password), where the username and password are both those of an existing YunoHost LDAP user.

To support this guess, I create a YunoHost account with random username and password, set them in listmonk's config.toml, restart the listmonk service, sign in to YunoHost main domain with these username and password, go to the listmonk subdomain, enter these username and password into the HTTP auth form, and the loop doesn't happen. Then I sign in to YunoHost using the username and password of another YunoHost user, and get the loop again.

[navanchauhan]

@stepcellwolf what version of listmonk are you running? I have Listmonk running on two different YunoHost instances and it is working fine now

[stepcellwolf]

Hi, I'm using v2.2.0 listmonk. I figure it out by granting permission to listmonk (admin) via Yunohost vistor group and it works now.