Multiuser Installation

[guest_cse]

Hi,

Though I appreciate your concern for multiuser complexity,
I think that we should be able to install TT-RSS on a website which is visited by several users.

One possible work-around can be to prevent marking of articles read if one user views it. So that if other one sees, it still looks unread and is visible.

Can you suggest something. I want to install it on my school alumni website...

TIA,

[fox]

Well, what can I say? If your users are okay with reduced functionality then by all means go ahead.

The actual hack is trivial, see view() function in viewfeed.js. You will need to disable some other things as well (e.g. mark feed as read, etc). You would probably also need to disable user-triggered feed updates.

[guest_cse]

Well, what can I say? If your users are okay with reduced functionality then by all means go ahead.

Well, when an article has been marked read, a user may think that he has read it. Or simply it will not look fresh to him. That is why I thought that even reduced functionality is ok if main feature (syndication) works well.

But, do you have a better idea? Can we save the READ flag depending upon some $USER environment variable. I am not too crappy about permissions but only read/unread is an issue.

I am familiar with PHP. If you can guide me a little on this, I can do it.

[fox]

Well, the right way of doing mutiuser access would require a lot of changes all around, which were more or less discussed here already as far as I remember. It is certainly possible to create some reduced system just to store lastread pointers and such but it won't be exactly easy either.

I dunno what else to tell, really. If you have any questions specific to TT-RSS innards I would be happy to answer.

[guest_cse]

Thanks, I will keep mailing you...

[ck1dog]

I hacked something together using http auth. It's a pain to administrate because you would have to add them to the group that is allowed using htpasswd etc, but it works great. I just added a user_name column to the feeds and entries tables and changed the insert and selects that reference those tables. Like I said, it's a hack but it works. People can even have duplicate feeds and the entries will be completely seperate. I'm testing it right now with 5 or 6 friends who just needed (i.e. I forced them to try) an aggregator. I can post the code if you want, or an account with which to try it.

Love TTRSS by the way!

[fox]

This would be great if you posted the patch somewhere. People keep asking for multiuser mode.

I'm not sure if I would integrate multiuser functionality in this sorta-hackish way, but this could work as a workaround for the time being.

[markc]

This would be great if you posted the patch somewhere. People keep asking for multiuser mode.

I'd also be interested to see this hack. Is it available anywhere ?

Another similar issue is multi hosting of this code so that multiple virtual hosts could use the same single codebase, with each instance, ideally, having it's own set of multiple users. I'd be interested in looking into doing this with tt-rss. In fact, if I decide to use it on my server then I have to get it to work like this.

[fox]

This is mostly irrelevant now, as TT-RSS is now completely multi-user aware. You can checkout the development head version (or download the snapshot) and test away. Well, that, or wait for the next release.

[markc]

This is mostly irrelevant now, as TT-RSS is now completely multi-user aware.

Not quite. The ability to multi-host means using a SINGLE copy of the codebase so that multiple instances can be run on the same server with each separate instance having it's own database and, optionally, it's own images and CSS.

I've just been looking at the 20051123 tarball and it would take about a week to modify it so I am considering doing it. You have done such a good job of writing both a good application and in an efficient manner that I think the effort is going to be worth it.

If I may offer a suggestion, you should perhaps consider developing with error_reporting(E_ALL) as the codebase is missing quite a few isset() tests. Other than that minor point it's really well written.

[fox]

Ah, well. I see the point. The easy way would be to define different configuration parameters in config.php like this:

Code: Select all

if ($_SERVER['SERVER_NAME'] == "vhost1.org") {
   define(DB_NAME, 'vhost1');
   define(ICON_URL, '/vhost1/icons');
   ...whatever...
}

I don't know what else is there to patch, everything should just pick up. You'll also need to point all your vhosts to the same DocumentRoot and, if I'm not missing something obvious, that's basically it.

[fox]

About the isset() stuff - I just thought I could define constants without quotes, okay, fixed it. I already explained what causes other warnings here: http://tt-rss.spb.ru/forum/viewtopic.php?t=40

[markc]

Yes, a vhost aware config.php would do the trick if all vhosts pointed to the same web folder, or were Alias'd or softlinked to do so. In my case I already have separate document roots for every vhost so if I wanted to adapt tt-rss to my (quite common) situation it would involve a fair rewrite of code. I'd usually do something like below so that the actual config file was in the document root of the vhost site so it's owner could modify some vhost specific variables, like db/user/pw...

Code: Select all

define('WEB_ROOT', '/var/www/');

$cfg = WEB_ROOT.$_SERVER['HTTP_HOST'].'/config.php';

if (file_exists($cfg))
    include $cfg;
else
    include 'default_config.php';


I'd also make all img/css/js links point to a $something/site.* so that $something can be set in the vhost config.php OR default to an absolute URL of a default host. All the PHP would then come from an off-web include_path so that the only thing needed in the vhost document root is a simple index.php with nothing else but...

Code: Select all

<?php include 'tt-rss.php'; ?>

As for E_ALL, sure, there are a few of these needed but I personally think it's worth it, ie; in login.php...

Code: Select all

$login = isset($_POST["login"]) ? $_POST["login"] : '';


[fox]

Oh, I really don't know if I would integrate it into upstream. This would add a lot of code for a problem which could be solved with Apache (aliases, etc.) or with some sort of VCS/rsync/script/whatever to update several installations of tt-rss (it's not like we are dealing with a big application here).

Of course, I'd be glad to have a look at the patch. And I'll probably add this config.php trick into wiki just in case.

As for isset() stuff - it just doesn't look natural to me. Code like

Code: Select all

<?
   $var_a = '';
   if (!$var_a) print "var_a is undefined";
?>


prints "var_a is undefined". So, as far as I'm concerned, there is no visible difference between undefined or a blank string in PHP.

[ck1dog]

I added a user_name column to each table, and the requisite changes to sql for each request. The code is at http://www.feedinator.com/ttrss.tar.gz or go to www.feedinator.com and make up an account to try it.

For getting the username, I cheated and used $_SERVER['PHP_AUTH_USER'] with apache authentication.

It has seperate entries for each feed, and each entry for each feed so it is 100% multiuser. I haven't looked at newer versions unfortunately, but I also added the ability to mark read after a certain period of time individual feeds in the prefs page.

There is also the ability to make your feeds public (viewable for others who look at the public feeds) via the prefs page, as well as add other public ones to your feed list from the same view.

Finally I like being able to see the full pages so added a link in the viewentry pane to view the page in the link. It's also ajax, so doesn't pop up unless you want it always to (also settable in the prefs page). Oh, and you can now manually update all your feeds instead of individually more easily.

As far as getting around the http auth irritation, I wrote a perl script to automatically check for existing users and add them to the auth file and groups file for the feeds page. Not super secure or easy to administer outside of vi, but easy enough.

I'm in the middle of cleaning up the hacky code, and adding a few more things like checking to make sure you are authorized to mark feeds read, delete, modify etc. I'll post an update more often, again sorry about the delay.