Problem Description
I made a non-admin user on my freedombox with the feed-reader role, but when logged into the freedombox with that user, ttrss treats this user as the admin user. I want the admin and normal users to be separate, like the docs say will happen automatically. Am I missing something?
Steps to Reproduce
Install ttrss
Create new non-admin user with the feed-reader role
Logout and login as that new user
Open ttrss
Go to preferences
Add a feed
Back in freedombox, log out and log in as admin
Open ttrss
Expected Results
I expected to see no feeds.
Actual results
I see the feed added by the non-admin user.
Information
FreedomBox version: 24.24
Hardware: Raspberry Pi 3 Model B V1.2
How did you install FreedomBox?: Raspberry Pi Imager
Additionally, the box is not yet set up to be seen from outside the network. Local network only (so far).
What you describe appears contrary to what’s in the documentation…
Any user created through FreedomBox web interface will be able to login and use this app. Each user has their own feeds, state and preferences.
Make another feed-reader user and then see if the second user can see the feeds added by the first user. If that is the case then you’ve identified either a bug or a deficiency in the documentation.
If you want advice, I’d just run with it as it is for the time being. A tt-rss replacement or alternative is in the works, and I’m eager to switch away from it. Meanwhile, I’m just using tt-rss and being happy to have it.
I think this is related to session cookie ttrss_sid. When I log out of FreedomBox as User1, this cookie is not cleared and seems to remain associated with User1. When I then log into FreedomBox as User2 and start ttrss (from Plinth), I see User1’s feeds. But if I delete the ttrss_sid cookie after logging out as User1, then log in as User2, I get a fresh ttrss_sid session cookie and see User2’s feeds.
This is probably only an issue when using multiple user accounts in the same browser session. It wouldn’t be an issue for different users on different machines, or even one user on a single machine using different browsers or different instances of the same browser for different user accounts.
This seems to be the issue, thanks. When I clear the cookie, I can access the other user.
This will probably be an irritant, because I try to separate my admin user from the user that will actually make use of the content (since I intend to make this server accessible when I’m away from home, and that seems good security practise). But if I forget I’m in my admin user before opening ttrss, I’ll have to clear this specific cookie before I log in again as the correct user. Not a big deal, sure, but it would be nice to not need to worry about that. Especially since this is my first home server project and I’m jumping back and forth between accounts to explore the options available to me.
I, too, jump back and forth between accounts to test and explore. I also try to stick to my non-admin account for normal daily use and use my admin account only for admin tasks.
Firefox is my browser, and the solution I’ve adopted is to create a separate Firefox profile for admin use (navigate to about:profiles) that I can start as a separate Firefox instance. I don’t have to manually delete cookies, and because I allow the profiles to retain cookies for my FreedomBox domain, once logged in via Plinth as a given user in a given profile, I stay logged in as that user.
Then I can just jump back and forth between instances to easily switch between admin and non-admin sessions. This setup helps me keep straight in my head what I’m doing as admin vs non-admin and separates local storage into separate buckets so I don’t have to remember or examine every cookie. Most days, since I usually use a non-admin account, I never even start an instance of the admin profile.
I now see that this leftover cookie has already been logged as a bug (issue #1080). Given its low impact, easy workaround, and that ttrss has gotten harder and less appealing to maintain on Debian, I’ll be surprised if someone feels inspired to fix it now. I concur with @joseph : be content to use ttrss as is for now while looking forward to an alternative currently in the works becoming available.